On Sun, 2006-03-12 at 16:17 +0100, Roman Zippel wrote:
> >
> > 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.
How do you want to prevent that a signal is dequeued on one CPU while
the softirq expires the timer on another CPU ? This can not be
prevented.
Of course we can check hrtimer_active() in posix_timer_fn(), but I have
to check if there is a problem the other way round. I cook up a patch.
tglx
-
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]
