From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932121AbcCURio (ORCPT ); Mon, 21 Mar 2016 13:38:44 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:40480 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756906AbcCURim (ORCPT ); Mon, 21 Mar 2016 13:38:42 -0400 Date: Mon, 21 Mar 2016 17:38:40 +0000 (GMT) From: "Maciej W. Rozycki" To: Ingo Molnar cc: Toshi Kani , "Luis R. Rodriguez" , Toshi Kani , Paul McKenney , Dave Airlie , Benjamin Herrenschmidt , "linux-kernel@vger.kernel.org" , linux-arch@vger.kernel.org, X86 ML , Daniel Vetter , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Borislav Petkov , Linus Torvalds , Andrew Morton , Andy Lutomirski , Brian Gerst Subject: Re: Overlapping ioremap() calls, set_memory_*() semantics In-Reply-To: <20160309091525.GA11866@gmail.com> Message-ID: References: <20160304094424.GA16228@gmail.com> <1457115514.15454.216.camel@hpe.com> <20160305114012.GA7259@gmail.com> <1457370228.15454.311.camel@hpe.com> <20160308121601.GA6573@gmail.com> <1457483385.15454.519.camel@hpe.com> <20160309091525.GA11866@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 9 Mar 2016, Ingo Molnar wrote: > > > So to go back to the original suggestion from Luis, I've quoted it, but > > > with a s/overlapping/aliased substitution: > > > > > > > I had suggested long ago then that one possible resolution was for us > > > > to add an API that *enables* aliased ioremap() calls, and only use it > > > > on select locations in the kernel. This means we only have to convert a > > > > few users to that call to white list such semantics, and by default > > > > we'd disable aliased calls. To kick things off -- is this strategy > > > > agreeable for all other architectures? > > > > > > I'd say that since the overwhelming majority of ioremap() calls are not > > > aliased, ever, thus making it 'harder' to accidentally alias is probably > > > a good idea. > > > > Did you mean 'aliased' or 'aliased with different cache attribute'?  The former > > check might be too strict. > > I'd say even 'same attribute' aliasing is probably relatively rare. Please note that aliased cached mappings (any kinds of, not necessarily from `ioremap') cause a lot of headache (read: handling trouble) with architectures such as MIPS which support virtually indexed caches which suffer from cache aliasing. There is a risk of data corruption if the same physical memory address space location is accessed through different virtual mappings as not all hardware catches duplicate cache entries created in such a case. We handle it in software for user mappings (although I keep having a feeling something always keeps escaping, due to the vast diversity of cache configurations possible), however I don't think we do for `ioremap', so disallowing aliased `ioremap' mappings by default sounds like a good idea to me. FWIW, Maciej