Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757632AbZJLScH (ORCPT ); Mon, 12 Oct 2009 14:32:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757618AbZJLScG (ORCPT ); Mon, 12 Oct 2009 14:32:06 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:59016 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757615AbZJLScF (ORCPT ); Mon, 12 Oct 2009 14:32:05 -0400 Date: Mon, 12 Oct 2009 11:30:07 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Andi Kleen cc: Peter Zijlstra , Ingo Molnar , Andrew Morton , "hugh.dickins" , David Howells , lkml , linux-arch Subject: Re: [RFC][PATCH] kmap_atomic_push In-Reply-To: <87ws30fppe.fsf@basil.nowhere.org> Message-ID: References: <1255016123.17055.17.camel@laptop> <87ws30fppe.fsf@basil.nowhere.org> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1423 Lines: 35 On Mon, 12 Oct 2009, Andi Kleen wrote: > Peter Zijlstra 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/