Re: [rt] __reacquire_lock_kernel bug?

[Thomas Gleixner]

On Thu, 12 Jun 2008, junjie cai wrote:
> Hi, List
> 
> We get a BUG_ON during some tests on a 2.6.22.19-rt9,
> the message is pasted at the end of this mail.

There is no BUG_ON in the code path where your stack trace comes from.
Unfortunately you omitted the interesting part of the message, which
is printed _before_ the stack trace:

"BUG: scheduling while atomic: .....
 
> It seems that preemption happened in __reacquire_kernel_lock()
> that kernel_lock in released twice.

Sorry, I do not understand what you mean.
 
>  int __lockfunc __reacquire_kernel_lock(void)
>  {
>        local_irq_enable();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> preempted here

When you use rt you won't be in that code path. -rt uses the
preemptible BKL implementation.

>        _raw_spin_lock(&kernel_flag);
>        local_irq_disable();
>        preempt_disable();
> }
> 
> After checking the 2.6.25.4-rt6, I think that same problem exist.
> Isn't that lock_depth should be set to -1 before local_irq_enable() ?
> 
>  int __lockfunc __reacquire_kernel_lock(void)
>  {
>        struct task_struct *task = current;
>        int saved_lock_depth = task->lock_depth;
> 
>        local_irq_enable();
>        BUG_ON(saved_lock_depth < 0);
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>preempted here

That's ok, when we the task is preempted here. lock_depth needs to be
set to -1 before we call down() and it is restored
afterwards. preempt_schedule_irq() handles the BKL in the right way.

Thanks,

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