waiting process in procfs read

waiting process in procfs read

[Richard Stover]

I submitted this as a bugzilla kernel bug report but was directed here.
Perhaps someone can help me.

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 int)&dev->read_proc_wait);

           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 %x\n",
               (unsigned int)&dev->read_proc_wait);

       wake_up_interruptible(&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
returns.
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. This code is
very similar to code used elsewhere in the driver where a process waits in an
ioctl call for a particular event to happen. That wait within an ioctl works fine.
The procfs read wait worked in Linux kernels up through RH9, 2.4.20-6 (with
appropriate code modifications for the earlier kernel).

If anybody has any suggestions I would appreciate the help. 


Thanks.

Richard Stover


----------------------------------------------------------------------
Richard Stover                       email: richard@ucolick.org
Detector Development Laboratory      http://www.ccd.ucolick.org
UCO/Lick Observatory                 Voice: 831-459-2139
Natural Sciences Bldg. 2, Room 160
University of California             FAX:   831-459-2298
Santa Cruz, CA 95064  USA            FAX:   831-426-5244 (Alternate)
----------------------------------------------------------------------

Re: waiting process in procfs read

[Nish Aravamudan]

On 8/26/05, Richard Stover <richard@ucolick.org> wrote:
> I submitted this as a bugzilla kernel bug report but was directed here.
> Perhaps someone can help me.
> 
> 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.

<snip>

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

<snip>

>        if (offset == 0) {
> 
>            printk("####%s waiting event %x\n",__FUNCTION__,
>                (unsigned int)&dev->read_proc_wait);
> 
>            wait_event_interruptible(dev->read_proc_wait,(offset != 0));
>            printk("####%s WOKE UP\n",__FUNCTION__);

<snip>

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

Your symptoms indicate to me that the "event" in
wait_event_interruptible() has not been satisifed, and thus the
(potentially) infinite loop in wait_event_interruptible() is
continuing, e.g. event still is 0. A signal (as you've specified
_interruptible()) causes that loop to break out. One option to debug
would be to use wait_event_interruptible_timeout() and then see if it
returns from that (it should in this case after the timeout has
passed) and then print out the value of offset. If it's still 0, then
wait_event_interruptible() is functioning as expected.

Thanks,
Nish

Re: waiting process in procfs read

[Nish Aravamudan]

On 8/26/05, Nish Aravamudan <nish.aravamudan@gmail.com> wrote:
> On 8/26/05, Richard Stover <richard@ucolick.org> wrote:
> > I submitted this as a bugzilla kernel bug report but was directed here.
> > Perhaps someone can help me.
> >
> > 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.
> 
> <snip>
> 
> > THE PROBLEM: In FC3 (2.6.11-13_FC3) the reading process blocks but it never
> > wakes up.
> 
> <snip>
> 
> >        if (offset == 0) {
> >
> >            printk("####%s waiting event %x\n",__FUNCTION__,
> >                (unsigned int)&dev->read_proc_wait);
> >
> >            wait_event_interruptible(dev->read_proc_wait,(offset != 0));
> >            printk("####%s WOKE UP\n",__FUNCTION__);
> 
> <snip>
> 
> > /*      Wake up anyone waiting on reading /proc/readXw                  */
> >        printk(KERN_INFO "#### waking up anyone waiting on read_proc_wait event %x\n",
> >                (unsigned int)&dev->read_proc_wait);
> >
> >        wake_up_interruptible(&dev->read_proc_wait);
> 
> Your symptoms indicate to me that the "event" in
> wait_event_interruptible() has not been satisifed, and thus the
> (potentially) infinite loop in wait_event_interruptible() is
> continuing, e.g. event still is 0. A signal (as you've specified

::sigh::, offset still is 0, not event :)

Thanks,
Nish