Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:

Once testing of the upstream kernel is complete, please mark this bug as

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  eventfd / poll interaction bug

Status in linux package in Ubuntu:

Bug description:
  In 17.10, I'm running into a new problem.  This didn't happen to me on

  I have some code that uses eventfds to signal things, and the code is
  not working -- after writing the eventfd, it does not come back
  readable from another thread using poll().

  Here's a snippet from strace:

  eventfd2(0, 0)                          = 5
  fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
  write(1, "OPEN FD 5\n", 10OPEN FD 5
  )             = 10
  write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
  nanosleep({tv_sec=0, tv_nsec=100000000}, 0x7fffd0cea1a0) = 0
  poll([{fd=5, events=POLLRDNORM}], 1, 100) = 0 (Timeout)

  The write(1,... ) is debugging output.  The nanosleep was intended to
  see if sleeping a bit before polling would help.  Note that the
  write(5, ...) and the poll() come from different threads.

  Note that using two descriptors from a pipe() (which I do for other
  platforms) is fine, so this is some kind of issue specific to eventfd.

  Also, trying to reproduce this with a simpler single threaded program
  did not succeed.  I'm wondering if there is some underlying cache
  synchronization problem?

  I'm testing this in a VMware Fusion virtual machine (Fusion 10.1.1)
  running on 2017 macbook pro (underlying OS is macOS 10.13).

  For now I'm going to switch back to pipes, since eventfd() seems
  unreliable -- if you can spot anything obviously wrong about the
  system call sequence above, I'd love to hear it.

To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to