[lkml]   [2004]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: poll() in 2.6 and beyond
    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

    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

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

    [unhandled content-type:application/octet-stream]
     \ /
      Last update: 2005-03-22 14:01    [W:0.020 / U:2.940 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site