lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.025 / U:0.224 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site