[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-kernel
Subject: Re: [PATCH] Fix queued SIGIO
From: "Andi Kleen" <ak () suse ! de>
Date: 2000-09-18 23:45:20
[Download RAW message or body]
On Mon, Sep 18, 2000 at 08:56:58PM +0200, Jamie Lokier wrote:
[...making SI_FROMUSER exclude SI_ASYNCIO and SI_TIMER...]
I haven't checked, but I suspect that would break the glibc user space
implementations.
Overall the concept of kernel reserved numbers doesn't make too much
sense as a API because there is always a legitimate need to emulate it in
userspace when you have appropiate credentials. It is just a convenient
hack to bypass the credentials checking in signal sending for some cases.
> > It'll break programs that try to send SI_SIGIO (=-5) signals from userspace,
> > but I think that is ok.
>
> Actually rt_sigqueueinfo has this test hard-coded in it:
>
> if (info.si_code >= 0)
> return -EPERM;
>
> with a comment "not even root is allowed to send signals from the
> kernel". Changing SI_FROMUSER won't affect this.
My patch of course changed this line to if (!SI_FROMUSER(&info)),
you probably missed that hunk..
There are two approaches: break the programs that expect to parse
si_code in signals/sigwaitinfo or break the program that use
sigqueueinfo() with arbitary values.
I would have expected that the second one is less painless, but it turned
out someone already took the first approach for SIGIO in 2.4 by turning
si_code into a bastardized si_band (which I don't quite follow, because
si_band already exists)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic