Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760767AbcCELkZ (ORCPT ); Sat, 5 Mar 2016 06:40:25 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38779 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755832AbcCELkR (ORCPT ); Sat, 5 Mar 2016 06:40:17 -0500 Date: Sat, 5 Mar 2016 12:40:12 +0100 From: Ingo Molnar To: Toshi Kani Cc: "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 Message-ID: <20160305114012.GA7259@gmail.com> References: <20160304094424.GA16228@gmail.com> <1457115514.15454.216.camel@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1457115514.15454.216.camel@hpe.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2380 Lines: 55 * Toshi Kani wrote: > > So I'd say that since ioremap() in itself is fragile enough, we should work > > towards eliminating overlapping ranges. > > > > The thing is, the whole vmap_area logic is based around non-overlapping > > ranges, sorted into the vmap_area_root rbtree. > > > > Just check the logic in mm/vmalloc.c::alloc_vmap_area(): it's based on finding > > holes in the kernel-virtual allocations. 'Overlapping ranges' is very much not > > part of that logic, at least to my understanding. > > > > How are overlapping ioremap()s even possible with that logic? The allocator > > searches for holes, not allowing for overlaps. What am I missing? > > > > Could you outline a specific case where it's done intentionally - and the > > purpose behind that intention? > > The term "overlapping" is a bit misleading. [...] A bit? It was totally misleading ... You meant virtual aliases for the same physical address, and those of course are allowed, as long the cache attributes are compatible, that is what the whole memtype infrastructure is about, as you yourself note: > [...] ?This is "alias" mapping -- a physical address range is mapped to multiple > virtual address ranges. ?There is no overlapping in VMA. > > Such alias mappings are used by multiple modules. ?For instance, a PMEM range is > mapped to the kernel and user spaces. ?/dev/mem is another example that creates > a user space mapping to a physical address where other mappings may already > exist. > > Hence, alias mapping itself is a supported use-case. ?However, alias mapping > with different cache types is not as it causes undefined behavior. ?Therefore, > PAT module protects from this case by tracking cache types used for mapping > physical ranges. ?When a different cache type is requested, > is_new_memtype_allowed() checks if the request needs to be failed or can be > changed to the existing type. So where is the problem? The memtype implementation and hence most ioremap() users are supposed to be safe. set_memory_*() APIs are supposed to be safe as well, as they too go via the memtype API. > I agree that the current implementation is fragile, and some interfaces skip > such check at all, ex.?vm_insert_pfn(). Most of those are really just low level interfaces for special cases that skip the memtype infrastructure. Thanks, Ingo