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: <20070307233833.f1482f86.sfr@canb.auug.org.au>
Date:	Wed, 7 Mar 2007 23:38:33 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 1/4] signalfd v1 - signalfd core ...

On Tue, 6 Mar 2007 23:11:49 -0800 (PST) Davide Libenzi <davidel@...ilserver.org> wrote:
>
> On Wed, 7 Mar 2007, Stephen Rothwell wrote:
>
> > On Tue, 6 Mar 2007 17:36:56 -0800 (PST) Davide Libenzi <davidel@...ilserver.org> wrote:
> > >
> > > The read(2) call will read u32 signal numbers that landed over the
> > > signalfd. It returns the size of the data copied, or zero if the sighand
> > > we are attached to, has been detached.
> >
> > So what about signals that the user asked for a siginfo_t to be returned
> > with?
>
> O-Ren:   "You didn't think it was gonna be that easy, did you?"
> B-Kiddo: "You know, for a second there, yeah, I kinda did."
>
> :)
>
> I could do that, since where I placed the signalfd_notify() I have the
> siginfo. But that is going to make code a little more complex, since the
> simple bitmaks needs to become a queue.

Then, of course, you have to think about how to get the siginfo_t out to
the user process.  Do you just return it from the read after the read
that returns the signal number?  If so, you need to know if the process
did a compat read syscall read or a normal one ...

There may be a better solution.

You probably need the queue anyway because the real time signals are
supposed to queue.

--
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/

Content of type "application/pgp-signature" skipped