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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
