lkml.org 
[lkml]   [2008]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/3] signals: sigqueue_free: don't free sigqueue if it is queued
    Date
    > Currently sigqueue_free() removes sigqueue from list, but doesn't cancel the
    > pending signal. This is not consistent, the task should either receive the
    > "full" signal along with siginfo_t, or it shouldn't receive the signal at all.

    Agreed.

    > Change sigqueue_free() to clear SIGQUEUE_PREALLOC but leave sigqueue on list
    > if it is queued.
    >
    > This patch doesn't change the behaviour of sys_timer_delete() and friends,
    > just makes it more correct and allows us to introduce other SIGQUEUE_ flags
    > passed to the receiver.

    To clarify, this certainly does change the behavior.
    There are two changes.

    Firstly, a pending timer-firing signal currently gets its siginfo_t
    zeroed out synchronously by timer_delete and now will have its info
    preserved. That change alone is a potential problem for userland, so
    it should not go in without the following changes to prevent userland
    from seeing the signal at all. (Currently userland may see a spurious
    signal, but its si_code and si_value don't indicate a timer firing.
    With the correct info, userland might try to use a pointer from
    si_value that was freed around the time it called timer_delete.)

    Second, a pending timer-firing signal currently stops counting towards
    the RLIMIT_SIGPENDING limit immediately upon a timer_delete call and
    now will keep counting toward that limit until it gets dequeued and
    discarded. This change is not necessarily a problem. (POSIX does not
    specify how we decide when resources are too short to create a new
    timer or queue a signal.) But it deserves mention somewhere.
    Applications can just get fixed to always unblock the signal number or
    flush old signals out with sigwait, if they are averse to timer
    signals with intact siginfo_t arriving after timer_delete.

    For this reason, I don't think this set of changes should be
    considered for any -stable branch.


    Thanks,
    Roland


    \
     
     \ /
      Last update: 2008-05-21 04:23    [W:3.333 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site