On Sun, 2006-03-12 at 17:00 +0100, Roman Zippel wrote:
> Hi,
>
> On Sun, 12 Mar 2006, Thomas Gleixner wrote:
>
> > 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.
>
> This should not be possible in first place, otherwise it's a bug.
> The original problem was a broken state machine, is that so hard to
> believe? If there is another problem, please provide more details.
Roman,
there was a state machine problem caused by something similar.
But the problem I described now happened with the current patch queue -
without the hrtimer_active() check. I have no direct access to the
machine which lets this surface and I just tried to reconstruct the
scenario from the sparse information which was provided by the customer.
All I can tell, that it is related to something similar and a requeue
happens where none should happen.
I agree, that it should not be handled in the hrtimer code. It has to be
fixed in the posix-timer code.
I make the check a BUG_ON(!hrtimer_active(timer) so it might show up in
-mm again. Ok ?
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]
