Re: behavior of RDMA poll calls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 10, 2019 at 09:53:17AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 10, 2019 at 12:17:15AM +0000, Hefty, Sean wrote:
> > > > > > An issue showed up when integrating rsockets into Java: the behavior
> > > > > > of the socket poll() call differs from the RDMA poll() operation.
> > > > > > Specifically, socket poll() releases all waiting threads, where the
> > > > > > RDMA stack releases one.  For example, see wake_up_interruptible()
> > > > > > when writing a CQ event here:
> > > > >
> > > > > This is just a bug, it should be fixed.
> > > >
> > > > A bug fix patch would be trivial, but this would change the behavior
> > > > that I think has existed since day 1.  Are people okay with that?
> > >
> > > No app could rely on this difference for correctness
> >
> > To follow up on this...
> >
> > I found documentation that indicated wake_up_interruptible() wakes
> > up all threads, and that appears to be the case.  Thread 1 is simply
> > returning to user space and reading the event before the thread 2
> > can run.  Thread 2 runs, finds the event queue empty, and with no
> > events to report, I suspect that causes poll() to resume.  If I
> > pause thread 1 before reading the event queue, both threads return
> > from the kernel.
>
> Poll is always sort of racy like this.. Running poll on two threads
> for the same event is not well defined.

I can't ever imagine any sane definition in scenario of concurrent polling.

Thanks

>
> Jason

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux