lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Dec 2012 14:39:14 -0500
From:	Andreas Voellmy <>
To:	Eric Wong <>
	" Wang" <>,
Subject: Re: epoll with ONESHOT possibly fails to deliver events

We (i.e. I together with my colleague Jason Wang, cc'ed) installed the latest stable kernel (3.7.1) and verified that the bug still occurs.  The bug occurs when testing the program across a network link and when testing on the loopback interface.  

We also noticed that when testing across the network, the hardware irq affinity settings (in the /proc/irq/ files) affect how frequently the bug occurs. When we use the default irq settings, the bug does not seem to occur, whereas when we use settings suggested by Intel (with script the bug occurs more frequently. 


On Dec 18, 2012, at 12:27 PM, Andreas Voellmy <> wrote:

> BTW, I simplified the test program a bit: I removed the loop that epoll_waits on the eventfd fd and reads from it (I also removed the epoll instance in that loop).  The bug still occurs with this removed. Now the bug is triggered simply by adding the call to eventfd_write after processing each request. 
> I pushed the update to my github project for the test program.
> -Andi
> On Dec 17, 2012, at 9:35 PM, Andreas Voellmy <> wrote:
>> On Dec 17, 2012, at 9:07 PM, Eric Wong <> wrote:
>>> Andreas Voellmy <> wrote:
>>>> There were a couple of errors in the code when I posted my last
>>>> message. I have fixed those. The epoll bug still occurs. 
>>> Sorry I haven't gotten around to this.
>>> Can you reproduce this with fewer cores? (I only have 4 at most).
>> I've been able to reproduce it on as few as 8 cores. I've never seen it occur with fewer than that.
>>> Have you tried the latest stable kernel version?
>> No, I've only tried
>>> Can you reproduce this over TCP loopback, or only across two machines?
>>> If the latter, it could also be a driver or firmware bug...
>> Yes, it also occurs when I run the http request generator on the same machine on the loopback interface.
>> -Andi

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists