PROBLEM: Bug in __pollwait() can cause select() and poll() to hang in 2.4.21
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 12 lines · Ray Bryant
select()andpoll()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 toyield(). If the process makes this call, this is a bad thing [tm], since the process state at that point isTASK_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 inselect()) so the process will never return from the call toyield().
Nasty bug. How about adding a BUG() for current->state != TASK_RUNNING at the beginning of __alloc_pages unless GFP_ATOMIC is set?
-Andi
Quoted 5 lines · Andi Kleen
Nasty bug. How about adding a
BUG()forcurrent->state!=TASK_RUNNINGat the beginning of__alloc_pagesunlessGFP_ATOMICis set?-Andi
A good idea. There may be other places like this that call into __alloc_pages() with current->state != TASK_RUNNING.
However, this may break otherwise happily running kernels being used in production today that are not in low memory situations. Might it not be better for me to run this in debug mode and see if we can find other places where this is happening? If I don't find any, then we can add the BUG() as a way to avoid future introductions of this problem.
Signature · 9 lines
Best Regards,
Ray
-----------------------------------------------
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[email protected] [email protected]
The box said: "Requires Windows 98 or better",
so I installed Linux.
-----------------------------------------------