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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0901261652150.8049@alien.or.mcafeemobile.com>
Date:	Mon, 26 Jan 2009 17:03:17 -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 Tue, 27 Jan 2009, Pavel Pisa wrote:

> Hello Davide,
> 
> thanks much for fast testing and patches. I have run different combination
> of the yours and mine tests on 2.6.28.2 patched by your latest fix
> and all have passed.
> 
> Excuse me for long code. I have not been fast enough to prepare simpler
> test. I have tried to log straces documenting the problem at least.
> There has been another problem with test reduction, that behavior
> has been timing dependant. Your pipe ping pong test works OK
> on unpatched 2.6.28.2 for some reasons for example. The mine code
> changed behavior according to log level and output redirection.
> My updated version of code does not trigger problem as well. Only that
> archived version has been relatively "reliable" in problem exposing.

The epoll pipe ping-pong only fails in the first version patch I sent you. 
It was a bug in the patch. Older kernel, and the ones using the new 
version of the patch are fine, WRT that test.



> 1) is the original problem only exposed by epoll over epoll?
>     If yes, then I expect, that I can use epoll over poll (glib)
>     even on older kernels.

No. Epoll's poll() was broken, that means you could not add the epoll fd 
inside any container (poll and select). Well, you can, but you get 
spurious wakeups.



> 2) If there could be other scenario to invoke event stuck on unpatched
>     kernel, what does exist some operation with epoll  set gets event
>     reports into sync?  I would add it as workaround into library.

Look at how the epoll_test.c program I sent you, does.



> 3) the epoll with level triggered events is most simple as poll replacement,
>      but EPOLLONESHOT and EPOLLET could cause less overhead on
>      the kernel side. Have you some idea about expected throughput
>      change?

It all depends on the application. EPOLLET departs from other event fetch 
machanisms, so if you have a generic library, you may want to be careful 
in its usage.



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