PROBLEM: Bug in __pollwait() can cause select() and poll() to hang

Ray Bryant (raybry@sgi.com)
Fri, 27 Jun 2003 13:19:20 -0500


[1.] One line summary of the problem:

In low memory situations, a process that issues a call to select()
or poll() can sleep forever in the kernel.

[2.] Full description of the problem/report:

select() and poll() call a common routine: __pollwait(). On the
first call to __pollwait(), it calls __get_free_page(GFP_KERNEL) to
allocate a table to hold wait queues. In the natural course of things,
this calls into __alloc_pages(). In low memory situations, the process
can then end up in the rebalance code at the bottom of __alloc_pages()
where there is a call to yield(). If the process makes this call, this
is a bad thing [tm], since the process state at that point is
TASK_INTERRUPTIBLE. There is no wait queue yet for the process (that is
done later in __pollwait()) and no schedule timeout event has yet been
created (that is done later in select()) so the process will never
return from the call to yield().

[3.] Keywords (i.e., modules, networking, kernel):

Kernel

[4.] Kernel version (from /proc/version):

This bug appears to be present in every 2.4 kernel from (at least)
2.4.13 thru 2.4.22-pre2. It is not present in 2.5.70, since a different
method of waiting for memory to free up is used there (in
__alloc_pages()).

[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)

N/A.

[6.] A small shell script or example program which triggers the
problem (if possible)

We ecountered this whilst running batch queue tests that are too
complex to include here.

[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

[7.2.] Processor information (from /proc/cpuinfo):

We encountered this on ia64, however, this is in machine
independent code and we believe the bug is present on all 2.4.21
platforms.

[7.3.] Module information (from /proc/modules):

[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)

[7.5.] PCI information ('lspci -vvv' as root)

[7.6.] SCSI information (from /proc/scsi/scsi)

[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):

[X.] Other notes, patches, fixes, workarounds:

The simplest fix (as suggested by Manfred Spraul) is to set
current=>state to TASK_RUNNING just before the call to yield() in
__alloc_pages(). I have tested this sufficiently that I believe
this does not change the user level semantics of select() (my
concern was that if state got set to TASK_RUNNING that the syscall
could return before any fd's are ready or the select() timeout has
expired, but this does not appear to be the case).

Here is a trivial patch against 2.4.22-pre2:

--- linux-2.4.22-pre2.orig/mm/page_alloc.c Thu Nov 28 17:53:15 2002
+++ linux-2.4.22-pre2/mm/page_alloc.c Fri Jun 27 13:47:49 2003
@@ -418,6 +418,7 @@
return NULL;

/* Yield for kswapd, and try again */
+ set_current_state(TASK_RUNNING);
yield();
goto rebalance;
}

-- 
Best Regards,
Ray
-----------------------------------------------
                   Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
Jun 23-Jul 18 I will be at: 970-513-4743
raybry@sgi.com             raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
            so I installed Linux.
-----------------------------------------------

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/