[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101118110409.f9c8d7d2.randy.dunlap@oracle.com>
Date: Thu, 18 Nov 2010 11:04:09 -0800
From: Randy Dunlap <randy.dunlap@...cle.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
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>
On Thu, 18 Nov 2010 20:02:05 +0100 Ingo Molnar wrote:
>
> * 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.
Ingo, I built it with your posted config file.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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