Messages in this thread |  | | Date | Tue, 19 Sep 2000 01:45:20 +0200 | From | "Andi Kleen" <> | Subject | Re: [PATCH] Fix queued SIGIO |
| |
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/
|  |