linux-kernel - Re: [RFC][PATCH] kmap_atomic

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]

Date:	Mon, 12 Oct 2009 11:30:07 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	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, 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 
that happen will always undo whatever changes they did. So even with a 
totally non-atomic "load + increment + store" model, it really doesn't 
matter if you get an interrupt or an NMI anywhere in the sequence, because 
by the time the interrupt returns, it will have undone any changes it did.

So as long as it's per-cpu (which it is) and non-preemptible (which it 
also is, thanks to kmap_atomic() doing the whole "disable_mm_fault()" 
thing or whatever), it's all fine.

Btw, this is not some new thing. It's exactly the same logic we rely on 
for other counts like the preempt-count etc.

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