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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101118190205.GB10827@elte.hu>
Date:	Thu, 18 Nov 2010 20:02:05 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [build failure] Re: BKL: remove extraneous #include <smp_lock.h>


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Thu, Nov 18, 2010 at 7:57 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > How painful would it be to move lock_depth into thread_struct? I guess
> > we don't have anything that cares about structure offsets in assembly
> > for that thing.  I should just try.
> 
> Gaah, the only generic field there is the restart_block, so we'd have
> to hide it there, or then add it to each architecture. So scratch
> that.
> 
> I guess this is the simplest approach.
> 
>                          Linus

>  include/linux/hardirq.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> index 714da7e..32f9fd6 100644
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -94,6 +94,7 @@
>  #define in_nmi()	(preempt_count() & NMI_MASK)
>  
>  #if defined(CONFIG_PREEMPT) && defined(CONFIG_BKL)
> +# include <linux/sched.h>
>  # define PREEMPT_INATOMIC_BASE (current->lock_depth >= 0)
>  #else
>  # define PREEMPT_INATOMIC_BASE 0

Hey, i will quote this patch in the future, when you flame me about some ugly 
compatibility hack ;-)

I guess it will all go away with CONFIG_BKL so we dont really care so deeply. I'll 
test it.

Thanks,

	Ingo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ