linux-kernel - Re: [rt] __reacquire_lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0806121255480.3193@apollo.tec.linutronix.de>
Date:	Thu, 12 Jun 2008 14:06:30 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	junjie cai <junjiec@...il.com>
cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [rt] __reacquire_lock_kernel bug?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/