linux-kernel - Re: Unexpected cascaded epoll behavior

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: <alpine.DEB.1.10.0901221711500.7789@alien.or.mcafeemobile.com>
Date:	Thu, 22 Jan 2009 17:21:46 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Pavel Pisa <pisa@....felk.cvut.cz>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Unexpected cascaded epoll behavior - my mistake or kernel bug

On Fri, 23 Jan 2009, Pavel Pisa wrote:

> Hello Davide and all others,
> 
> I have got to implementing yet another event library and I experience
> something strange when level triggered epoll_wait() monitors another
> level triggered epoll set. Top level epoll_wait() return information
> about one event pending. The event points correctly to the monitored
> second level epoll fd, but epoll_wait() on this fd with 0 or small timeout
> returns zero/no events and top level epoll reporting is not reset at this
> point so program enters busy loop. If there are events, they are processed
> correctly.

I'm ashamed to say, I know. It has been reported to me about three months 
ago, I coded patches, but I did not have the time to test them carefully.
The problem is that inside the epoll wakeup callback, we don't know which 
even we got (and we can't call ->poll()). So we add the fd to the 
ready-list and we wake up the waiters. The current code simply does return 
EPOLLIN (from epoll's poll()) if the ready-list is not empty. The problem 
is that the even we received in the epoll callback could have been a 
POLLIN when the fd is waiting for POLLOUT. THis situations gets sorted out 
in epoll_wait(), but inside epoll's poll() only a quick test was used 
(ready-list not empty).
The patch was not exactly a one-liner, so I need a few days to double 
check it and test it. I'll try to do it this w/end.

- Davide

--
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/