Re: 3.14-rc2 XFS backtrace because irqs_disabled.

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sat, Feb 15, 2014 at 03:36:31PM +0000, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:22:51PM +0000, Al Viro wrote:
> > On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> > 
> > > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> > > 
> > >    Once get_signal_to_deliver() or any other caller drops ->siglock
> > >    another thread can do sys_timer_delete()->sigqueue_free().
> > 
> > How the devil would it find the sucker?  It's off the list already.
> 
> Ouch...  I think I see what you mean.  Let me see if I got it right:
> timer->sigq is *not* freed by collect_signal(); it's done by
> release_posix_timer() instead, under siglock.  Frankly, this
>         /*
>          * If it is queued it will be freed when dequeued,
>          * like the "regular" sigqueue.
>          */
>         if (!list_empty(&q->list))
>                 q = NULL;
> in sigqueue_free() smells like it's asking for races.  Sigh...

So basically we want a different condition for "can we just go ahead and
free that sucker", right?  Instead of "it's on the list, shan't free it"
it ought to be something like "it's on the list or it is referenced by
ksiginfo".  Locking will be interesting, though... ;-/

BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
something blocked, shoves it back with PTRACE_SETSIGINFO and does
PTRACE_CONT with that new signal number?  Would we get two sigqueue instances
with the same ->si_tid, one of them matching the timer->sigq and another
- not?