On 02/15, Al Viro wrote: > > > 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... This is protected by ->siglock, should be safe... > 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... ;-/ I guess yes... send_sigqueue() checks list_empty() too, probably nobody else. > 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? Or the task sends a SI_TIMER info to itself via sys_rt_sigqueueinfo(). Afaics, nothing really bad can happen, I mean the kernel should not crash or something like this. do_schedule_next_timer() can be fooled, but at least lock_timer() can only succeed if this process actually has a timer with the same timer_id. This sigqueue != timer->sigq, but I think this doesn't matter, posix_timer_event() will use timer->sigq anyway. Oleg. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
