linux-kernel - Re: Revised signalfd man-page

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]

Date:	Wed, 17 Oct 2007 15:52:28 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
cc:	Michael Kerrisk <mtk-manpages@....net>,
	lkml <linux-kernel@...r.kernel.org>,
	Subrata Modak <subrata@...ux.vnet.ibm.com>,
	geoff@...are.org.uk, Christoph Hellwig <hch@....de>
Subject: Re: Revised signalfd man-page

On Wed, 17 Oct 2007, Michael Kerrisk wrote:

> > With the new code Linus already merged, signalfd does not attach to the 
> > sighand anymore, so the "orphaned sighand" behaviour is no more there.
> > An exec() will carry the fd over, and you will be able to use the fd in 
> > the same way you did before the exec(). If sigpending()/sigwaitinfo() will 
> > show signals available, so it should signalfd.
> 
> So I wrote:
> 
>    execve(2) semantics
>        Just  like  any  other  file  descriptor, a signalfd file
>        descriptor remains open across an  execve(2),  unless  it
>        has  been  marked  for close-on-exec (see fcntl(2)).  Any
>        signals  that  were  available  for  reading  before  the
>        execve(2)  remain  available to the newly loaded program.
>        (This is analogous to traditional signal semantics, where
>        a  blocked  signal that is pending remains pending across
>        an execve(2).)  (This is analogous to traditional  signal
>        semantics, where a blocked signal that is pending remains
>        pending across an execve(2).)
> 
> Okay?

Ok



> > It'll return the signals that would be normally returned to the thread 
> > with the standard signal delivery methods. That is, calling thread private 
> > signals, and calling thread-group shared signals.
> 
> So I wrote:
> 
>    Thread semantics
>        The semantics of signalfd file descriptors  in  a  multi-
>        threaded  program  mirror the standard semantics for sig-
>        nals.  In other words, when a thread reads  from  a  sig-
>        nalfd  file descriptor, it will read the signals that are
>        directed to the thread itself and the  signals  that  are
>        directed  to the process (i.e., the entire thread group).
>        (A thread will not be  able  to  read  signals  that  are
>        directed to other threads in the process.)
> 
> Okay?

Ok, although this looks more specific:

(A thread will not be able to read other threads private signals)



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