linux-kernel - Re: epoll with ONESHOT possibly fails to deliver events

lists.openwall.net		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]

Message-Id: <35FB17E6-66E9-4945-AC77-1C66AC18797D@yale.edu>
Date:	Fri, 21 Dec 2012 10:32:45 -0500
From:	Andreas Voellmy <andreas.voellmy@...e.edu>
To:	Eric Wong <normalperson@...t.net>
Cc:	viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Junchang(Jason) Wang" <junchang.wang@...e.edu>
Subject: Re: epoll with ONESHOT possibly fails to deliver events

Hi Eric, 

Thanks again for looking at our bug report. I agree with Jason's comments: the bug occurs independently of the socketCheck function; this function waits long enough for the server to stop serving any more requests and then checks the sockets to find out which ones still have data (and therefore should be served).  But I like your suggestion, so I updated the code to use ioctl rather than recv in socketCheck. As we expected, the bug still occurs. 

Cheers, 
Andi

On Dec 20, 2012, at 5:25 PM, "Junchang(Jason) Wang" <junchang.wang@...e.edu> wrote:

> On Thu, Dec 20, 2012 at 4:32 PM, Eric Wong <normalperson@...t.net> wrote:
>> Andreas Voellmy <andreas.voellmy@...e.edu> wrote:
>>> I wrote a C program that behaves similar to my original program and
>>> triggers the bug. The bug only arises when I use enough cores and
>>> threads (about 16). The program is here:
>>> https://github.com/AndreasVoellmy/epollbug/blob/master/epollbug.c
>> 
>> I finally took a closer look at your code.   I think your socketCheck()
>> thread is draining socket and causing the normal threads to miss
>> events.
>> 
> 
> Hi Wong,
> 
> Thank you so much for responses. But I think you probably
> misunderstood socketCheck() which we use at the end of the program to
> check whether the bug has occurred (by checking whether some data
> remains in the sockets). Please note there's a sleep(10) (line 237) at
> the very beginning of socketCheck(). In other words, we can guarantee
> recv() (line 239) doesn't execute when the normal threads are running.
> 
> We still believe this is a bug in epoll system even though we can't
> prove that so far. Both Andi and I are very interested in this problem
> and helping you experts solve this it. Just let us know if we can
> help.
> 
> 
> Thanks.
> 
>> Use the FIONREAD ioctl() instead to get unread bytes instead of recv().
>> If you want to recv() without draining the socket, you can also use
>> the MSG_PEEK flag.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/