Re: [RFC][PATCH] kmap_atomic_push

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 12 Oct 2009, Andi Kleen wrote:

> Peter Zijlstra <peterz@infradead.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