[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20091012184028.GA20412@basil.fritz.box>
Date: Mon, 12 Oct 2009 20:40:29 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
"hugh.dickins" <hugh.dickins@...cali.co.uk>,
David Howells <dhowells@...hat.com>,
lkml <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC][PATCH] kmap_atomic_push
On Mon, Oct 12, 2009 at 11:30:07AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 12 Oct 2009, Andi Kleen wrote:
>
> > Peter Zijlstra <peterz@...radead.org> writes:
> > > -
> > > -static inline void debug_kmap_atomic(enum km_type type)
> > > +static inline int kmap_atomic_push_idx(void)
> > > {
> > > + int idx = __get_cpu_var(__kmap_atomic_depth)++;
> >
> > The counter needs to be of local atomic type. Otherwise kmap_atomic cannot
> > be done from interrupts/nmis, which is unfortunately occasionally needed.
>
> I thought so too on lookin gat it initially, but it's not actually true.
>
> It's both IRQ and NMI safe as-is, for a very simple reason: any interrupts
Good point, thanks.
I was thinking of CPU migration in interrupt cases, but even there
it should be ok in mainline.
I suppose it's not true for the preempt-rt folks (who can migrate
CPUs at any time), so it might be still more friendly to handle it for them
though.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
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