Re: poll() in 2.6 and beyond

["Richard B. Johnson" <root@chaos.analogic.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2366 bytes --]

On Tue, 2 Mar 2004, Bill Davidsen wrote:

> Roland Dreier wrote:
>
> > I don't know why I continue this, but.... can you point out the line
> > in the kernel 2.4 source for __pollwait() where it sleeps?
> >
> > Or think about it.  Suppose a user called poll() with two fds, each of
> > which belonged to a different driver.  Suppose each driver slept in
> > its poll method.  If the first driver never became ready (and stayed
> > asleep), how would poll() return to user space if the second driver
> > became ready?
> >
> > What actually happens is that each driver registers with the kernel
> > the wait queues that it will wake up when it becomes ready.  But the
> > core kernel is responsible for sleeping, outside of the driver code.
>
> Could you maybe go back to the initial report, which is that after
> poll() gets wrong status? It's nice to argue about where the process
> waits, but the issue is if it gets the same status with 2.4 and 2.6, and
> if not which one should be fixed.
>
> Richard: can you show this with a small demo program? I assume you
> didn't find this just by reading code ;-)

Yes. The code I attached earlier shows that the poll() in a driver
gets called (correctly), then it calls poll_wait(). Unfortunately
the call to poll_wait() returns immediately so that the return
value from the driver's poll() is whatever it was before some
event occurred that the driver was going to signal with
wake_up_interruptible().

The attached code clearly demonstrates this. It doesn't even contain
any code to execute wake_up_interruptible(). When an event occurs
in the driver that would have set the poll_flag to POLLIN, and
executed wake_up_interruptible, the old status, the stuff that
was returned when poll_wait() returned immediately instead of
waiting for the wake up, gets returned to the user-mode program.

Now, if the user-mode program calls poll() again, which is likely,
it gets the status that was returned from the previous event so
it "seems" to work. However, it is always one event behind so
you need two events to recognize the first one.

I attached the module and demo program again. It clearly shows
that poll_wait() gets called and then immediately returns without
waiting...

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 1453 bytes --]