On Thu, May 25, 2023 at 03:46:12PM +0800, Kent Gibson wrote: > On Thu, May 25, 2023 at 03:09:26PM +0800, Kent Gibson wrote: > > On Thu, May 25, 2023 at 11:09:52AM +0800, Kent Gibson wrote: > > > Hi Bart, > > > > > I can also confirm that receiving the event using a blocking read() on the > > fd still works, it is a poll() on the fd followed by a read() that fails. > > > > Hmmm, so it occurred to me that gpionotify does the poll()/read(), so it > should exhibit the bug. But no, it doesn't. > > So it could be my code doing something boneheaded?? > Or there is some other variable at play. > I'll try to write a test for it with libgpiod and see I can reproduce > it. But I might put it on the back burner - this one isn't terribly > high priority. > Bisect result: [bdbbae241a04f387ba910b8609f95fad5f1470c7] gpiolib: protect the GPIO device against being dropped while in use by user-space So, the semaphores patch. The Rust test gets the timings right to hit a race/order of events issue? Cheers, Kent.