Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqueue if it is queued

[Roland McGrath]

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/