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.
It seems that preemption happened in __reacquire_kernel_lock()

that kernel_lock in released twice.
 int __lockfunc __reacquire_kernel_lock(void)

 {

       _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

       task->lock_depth = -1;
       down(&kernel_sem);
       task->lock_depth = saved_lock_depth;
       local_irq_disable();
       return 0;

 }
OOPS message:

---------------------------------------------------------------------------------------------------------------------------------------------------

 [<c0024a50>] (dump_stack+0x0/0x24) from [<c002cf44>] (__schedule_bug

+0x48/0x54)

[<c002cefc>] (__schedule_bug+0x0/0x54) from [<c01991dc>] (__schedule

+0x9c/0x510)

 r6:000003ff r5:f70d0100 r4:c0199868

[<c0199140>] (__schedule+0x0/0x510) from [<c0199868>]

(preempt_schedule_irq+0x48/0x70)

[<c0199820>] (preempt_schedule_irq+0x0/0x70) from [<c0020a08>]

(svc_preempt+0x8/0x20)

 r4:ffffffff

[<c019ba20>] (__lock_text_start+0x0/0x2c) from [<c01995cc>] (__schedule

+0x48c/0x510)

[<c0199140>] (__schedule+0x0/0x510) from [<c01997e0>] (schedule

+0xc8/0x108)

[<c0199718>] (schedule+0x0/0x108) from [<c00ce488>] (nfs_wait_schedule

+0x34/0x40)

 r4:00000000

[<c00ce454>] (nfs_wait...
[ message continues ]

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:
When you use rt you won't be in that code path. -rt uses the
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

--