From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [RFC][PATCH] kmap_atomic_push Date: Mon, 12 Oct 2009 20:40:29 +0200 Message-ID: <20091012184028.GA20412@basil.fritz.box> References: <1255016123.17055.17.camel@laptop> <87ws30fppe.fsf@basil.nowhere.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: Andi Kleen , Peter Zijlstra , Ingo Molnar , Andrew Morton , "hugh.dickins" , David Howells , lkml , linux-arch List-Id: linux-arch.vger.kernel.org On Mon, Oct 12, 2009 at 11:30:07AM -0700, Linus Torvalds wrote: > > > 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 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@linux.intel.com -- Speaking for myself only. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from one.firstfloor.org ([213.235.205.2]:47745 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757612AbZJLSlH (ORCPT ); Mon, 12 Oct 2009 14:41:07 -0400 Date: Mon, 12 Oct 2009 20:40:29 +0200 From: Andi Kleen Subject: Re: [RFC][PATCH] kmap_atomic_push Message-ID: <20091012184028.GA20412@basil.fritz.box> References: <1255016123.17055.17.camel@laptop> <87ws30fppe.fsf@basil.nowhere.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: Andi Kleen , Peter Zijlstra , Ingo Molnar , Andrew Morton , "hugh.dickins" , David Howells , lkml , linux-arch Message-ID: <20091012184029.-fJy9ctcrU372llS0Evstdgo2jkz5v4tc1wW0NxUcqU@z> On Mon, Oct 12, 2009 at 11:30:07AM -0700, Linus Torvalds wrote: > > > 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 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@linux.intel.com -- Speaking for myself only.