[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160416092018.GA8453@gmail.com>
Date: Sat, 16 Apr 2016 11:20:18 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Toshi Kani <toshi.kani@....com>
Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>,
"Maciej W. Rozycki" <macro@...ux-mips.org>,
Julia Lawall <julia.lawall@...6.fr>,
Toshi Kani <toshi.kani@...com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Dave Airlie <airlied@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org, X86 ML <x86@...nel.org>,
Daniel Vetter <daniel.vetter@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Borislav Petkov <bp@...en8.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>,
Brian Gerst <brgerst@...il.com>
Subject: Re: Overlapping ioremap() calls, set_memory_*() semantics
* Toshi Kani <toshi.kani@....com> wrote:
> On x86, ioremap() and remap_pfn_range() already fail on a conflicting cache
> type if it is not allowed by the rule defined in is_new_memtype_allowed().
> This exception handling is necessary for remap_pfn_range() called by
> /dev/mem, but I do not think it's necessary for ioremap(). I think we can
> start from adding a warning message to ioremap().
Agreed, we should warn and map the situation before doing any behavioral change
that isn't a fix.
Thanks,
Ingo
Powered by blists - more mailing lists