Bug 166383 - A process waiting on a procfs read never wakes up.
A process waiting on a procfs read never wakes up.
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-08-19 19:07 EDT by Richard Stover
Modified: 2015-01-04 17:21 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-26 17:30:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard Stover 2005-08-19 19:07:03 EDT
Description of problem:
I have a device driver developed with 2.4 kernels. I've ported
it to the 2.6 kernel (FC3) and it all works fine except for one
aspect of procfs.

My device driver sets up an entry in the /proc tree. A process
can open this entry and read from it. Normally the read blocks
until an event happens elsewhere in the device driver. When the
event happens the blocked process is woken up and the read
returns the information it was waiting for.

THE PROBLEM: In FC3 (2.6.11-13_FC3) the reading process blocks but it never
wakes up.

Here is a code fragment from the driver where the reading
process would block:

/*      Wait until the next image header has been read.         */
/*      But only wait if we are reading from the beginning.     */
       if (offset == 0) {

           printk("####%s waiting event %x\n",__FUNCTION__,(unsigned

           wait_event_interruptible(dev->read_proc_wait,(offset != 0));
           printk("####%s WOKE UP\n",__FUNCTION__);

/*          See if our sleep was interrupted by a signal.       */

           if (signal_pending(current)) {
               *buffer_location = my_buffer;
               printk("####%s returns error due to pending signal\n",__FUNCTION__);
               return -EINTR;

Here is a code fragment that is trying to wake up the blocked process:

/*      Wake up anyone waiting on reading /proc/readXw                  */
       printk(KERN_INFO "#### waking up anyone waiting on read_proc_wait event
               (unsigned int)&dev->read_proc_wait);


I see the blocked process "waiting event..." message and I see the "waking up..."
message. But I never get the "WOKE UP" message and the waiting process never
If I kill the waiting process I do see "WOKE UP" and "returns error due to
pending signal"
messages so I know it has in fact been waiting. The address of dev->read_proc_wait
is the same in both the "waiting event..." and "waking up..." messages.
I've initialize dev->read_proc_wait just like several other event flags in the
same device driver: init_waitqueue_head(&(dev->read_proc_wait));

I can not see any reason why the waiting process wouldn't wake up.

If anybody has any suggestions I would appreciate the help. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. As described above
Actual results:
Process waits.

Expected results:
Process wakes up.

Additional info:
Comment 1 Dave Jones 2005-08-26 03:36:42 EDT
Coding help questions -> linux-kernel@vger.kernel.org
Comment 2 Richard Stover 2005-08-26 12:03:17 EDT
Do you know this is not a bug or are you just dismissing it? It looks like
a bug to me. Can you explain why it is a coding issue and not a bug?
The same device driver uses very similar code within the context of an
ioctl call and that wait works fine. Why should it fail within the context
of a procfs read?

Comment 3 Dave Jones 2005-08-26 17:30:44 EDT
2.6.11-13_FC3 is an ancient kernel, a lot of stuff has changed since then in the
current errata kernels.

If it is still reproducable under the latest errata kernel, this is either a bug
that needs to be brought to the attention of upstream, or its a bug in your code.
either way, linux-kernel is the place for it, not Fedora bugzilla.

Note You need to log in before you can comment on or make changes to this bug.