linux-kernel - Re: [patch 1/4] signalfd v1

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: <a36005b50703152216s6c2fce0ck71d41a124940265f@mail.gmail.com>
Date:	Thu, 15 Mar 2007 21:16:22 -0800
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Davide Libenzi" <davidel@...ilserver.org>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Stephen Rothwell" <sfr@...b.auug.org.au>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [patch 1/4] signalfd v1 - signalfd core ...

On 3/7/07, Davide Libenzi <davidel@...ilserver.org> wrote:
> Let's do this. How about you throw this way one of the case that would
> possibly break, and I test it?

Since you make such claims I assume your signalfd() implementation
considers a signal delivered once it is reported to an epoll() caller.
 Right?

This is not what you really want, at least not in all cases.  A signal
might be something you want to react on right away.  Unless
pthread_kill() is used it is delivered to the _process_ and not a
specific thread.  But this means if epoll() reports two events to one
thread calling epoll() (one of them being a signal) and this thread is
then stuck processing the other request, the signal is not handled
even though there might be a second or third thread available to
receive the signal.  Those threads have the same right to receive the
signal and the current implementation always looks for the
best/fastest way to deliver the signal.

This means to me that reporting the signal in epoll() does _not_ mark
the signal as handled.  Somehow (probably using the signalfd()
descriptor) the thread must explicitly request the signal to be
delivered.  But if you do this the epoll() handling is fantastically
racy if the signal is not blocked.
-
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/