From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755192AbcEXXd0 (ORCPT ); Tue, 24 May 2016 19:33:26 -0400 Received: from mx2.suse.de ([195.135.220.15]:60619 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753725AbcEXXdX (ORCPT ); Tue, 24 May 2016 19:33:23 -0400 Date: Wed, 25 May 2016 01:33:18 +0200 From: "Luis R. Rodriguez" To: Toshi Kani Cc: mingo@kernel.org, bp@suse.de, hpa@zytor.com, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski , Dan Williams , Julia Lawall , Christoph Hellwig , Paul McKenney , Will Deacon , Benjamin Herrenschmidt , linux-arch , mcgrof@kernel.org Subject: Re: [PATCH] x86/mm: Add warning to ioremap() for conflicting cache type Message-ID: <20160524233318.GC11948@wotan.suse.de> References: <1461770757-26817-1-git-send-email-toshi.kani@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461770757-26817-1-git-send-email-toshi.kani@hpe.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 27, 2016 at 09:25:57AM -0600, Toshi Kani wrote: > On x86, ioremap() and remap_pfn_range() fail on conflicting cache > type of an alias mapping request only if the case is not allowed > by the rule set in is_new_memtype_allowed(). While this exemption > is necessary for remap_pfn_range() called for /dev/mem mappings, > it is not necessary for ioremap(). The wording here is a bit unclear. How about: Currently we allow for conflicting cache requests to account for reading out /dev/mem, however /dev/mem uses remap_pfn_range(). An explicit exception is not currently known to exist for conflicting cache type requests for ioremap(), however we are not certain if such conflicting use type currently does exist. > Drivers should never call > ioremap() with a conflicting cache type. This exemption handling > may hide possible bugs in drivers. And this to: Upon review, we've determined that at least device drivers have no business in calling ioremap() with a conflicting cache type. > Add a warning message to ioremap() when a conflicting cache type > is allowed by is_new_memtype_allowed(). This will help us > helps us identify > such usages in drivers. such valid uses in device drivers > > There is no change in the behavior. There are no functional changes introduced by this commit other than the addition of the new warning. > Link: https://lkml.org/lkml/2016/4/16/54 lkml.org references should be avoided, we have no control over that domain. Please instead use: http://lkml.kernel.org/r/20160416092018.GA8453@gmail.com > Signed-off-by: Toshi Kani > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: "H. Peter Anvin" > Cc: Borislav Petkov > Cc: Luis R. Rodriguez > Cc: Andy Lutomirski > Cc: Dan Williams > --- > arch/x86/mm/ioremap.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c > index 0d8d53d..16c5887 100644 > --- a/arch/x86/mm/ioremap.c > +++ b/arch/x86/mm/ioremap.c > @@ -138,14 +138,16 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, > } > > if (pcm != new_pcm) { > - if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) { > - printk(KERN_ERR > - "ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n", > + retval = is_new_memtype_allowed(phys_addr, size, pcm, new_pcm); > + pr_err( > + "ioremap %s for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n", > + retval ? "warning" : "error", > (unsigned long long)phys_addr, > (unsigned long long)(phys_addr + size), > pcm, new_pcm); This doesn't really make it humanly consumable, a pcm_to_str may help, such use already exists but not generalized see pat_get_cache_mode(). > + if (!retval) > goto err_free_memtype; > - } > + > pcm = new_pcm; > } In the future we may be able to proactively hunt for these invalid uses semantically but to do so we need first a demo driver with all known possible bugs we can think of. Luis