From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: kmap_atomic and preemption Date: Wed, 4 May 2016 20:17:55 +0100 Message-ID: <20160504191755.GV19428@n2100.arm.linux.org.uk> References: <5729D0F4.9090907@synopsys.com> <20160504134729.GP3430@twins.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from pandora.arm.linux.org.uk ([78.32.30.218]:41960 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751132AbcEDTUe (ORCPT ); Wed, 4 May 2016 15:20:34 -0400 Content-Disposition: inline In-Reply-To: <20160504134729.GP3430@twins.programming.kicks-ass.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: Vineet Gupta , Nicolas Pitre , Andrew Morton , David Hildenbrand , Thomas Petazzoni , lkml , "linux-mm@kvack.org" , "linux-arch@vger.kernel.org" On Wed, May 04, 2016 at 03:47:29PM +0200, Peter Zijlstra wrote: > Traditionally kmap_atomic() disables preemption; and the reason is that > the returned pointer must stay valid. This had a side effect in that it > also disabled pagefaults. A lowmem page should never change its page_address(), so that much is safe. I think the question is whether there is any driver code which assumes that preemption is unconditionally disabled between a kmap_atomic() has been called. That wouldn't be an unreasonable assumption given the name of the function, so I'd suggest caution with making kmap_atomic() have these kinds of differing behaviours depending on whether we're asking to kmap a high or lowmem page. If we are going to allow this, I think it at least needs to be well documented. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.