Re: [patch 5/8] hrtimer remove state field

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Sun, 12 Mar 2006, Thomas Gleixner wrote:

> > In this case no signal is queued and the timer won't be restarted via 
> > signal delivery.
> 
> Roman,
> 
> Interrupts are enable before fn() is called, so an interrupt can
> actually delay it long enough that userspace on CPU1 can set SIG_IGN
> 
> CPU 0
> spin_unlock_irq(base->lock)	
> 			CPU1
> 			signal is dequeued
> 				timer is requeued
> 			user space code is executed
> 			user space code sets SIG_IGN
> restart = fn();
> 
> Now fn() calls send_sigqeue() which returns 1, resulting in ret =
> HRTIMER_RESTART which leads to requeueing of an enqueued timer.

I'm not quite sure I follow, when the timer is running no signal should be 
queued, so nothing can be dequeued and no new timer can be requeued.
If that somehow is possible (although I don't see how), you'd found a bug 
in the signal/posix timer code, which should not be worked around in the 
hrtimer run queue.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/