linux-kernel - Re: [PATCH v2 08/25] arch: introduce memremap()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150729214358.GK30479@wotan.suse.de>
Date:	Wed, 29 Jul 2015 23:43:58 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Toshi Kani <toshi.kani@...com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	linux-arch@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Russell King <rmk+kernel@....linux.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 08/25] arch: introduce memremap()

On Wed, Jul 29, 2015 at 03:00:38PM -0600, Toshi Kani wrote:
> On Wed, 2015-07-29 at 11:33 -0700, Dan Williams wrote:
> > On Wed, Jul 29, 2015 at 11:27 AM, Luis R. Rodriguez <mcgrof@...e.com> 
> > wrote:
> > > On Wed, Jul 29, 2015 at 08:50:04AM +0200, Christoph Hellwig wrote:
> > > > On Mon, Jul 27, 2015 at 04:26:03PM -0700, Dan Williams wrote:
> > > > > Oh, because all we have at this point is ioremap_cache() which
> > > > > silently falls back.  It's not until the introduction of
> > > > > arch_memremp() where we update the arch code to break that 
> > > > > behavior.
> > > > 
> > > > Ok, makes sense.  Might be worth to document in the changelog.
> > > > 
> > > > > That said, I think it may be beneficial to allow a fallback if the
> > > > > user cares.  So maybe memremap() can call plain ioremap() if
> > > > > MEMREMAP_STRICT is not set and none of the other mapping types are
> > > > > satisfied.
> > > > 
> > > > Is there a real use case for it?  Fallback APIs always seem confusing
> > > > and it might make more sense to do this in the caller(s) that 
> > > > actually
> > > > need it.
> > > 
> > > It seems semantics-wise we are trying to separate these two really, so 
> > > I agree
> > > with this. Having a fallback would onloy make things more complicated 
> > > for any
> > > sanitizer / checker / etc, and I don't think the practical gains of 
> > > having a
> > > fallback outweight the gains of having a clear semantic separation on 
> > > intended
> > > memory type and interactions with it.
> > > 
> > 
> > Yup, consider it dropped.  Drivers that want fallback behavior can do
> > it explicitly.
> 
> I agree in general.  However, for the drivers to be able to fall back
> properly, they will need to know the cache type they can fall back with. 

That would depend on the purpose of the region and the driver developer should
in theory know best. One issue with this of course is that, as we've
discovered, the semantics of on the ioremap*() variant front regarding cache
types is not clearly well defined, or at least it may be only well defined
implicitly on x86 only, so the driver developer can only *hope* for the best
across architectures. Our ambiguity on our semantics on ioremap*() variants
therefore means driver developers can resonably be puzzled by what fallbacks to
use. That also means architectures maintainers should not whip driver developers
for any misuse. Such considerations are why although we're now revisiting
semantics for ioremap*() variants I was in hopes we could be at least somewhat
pedantic about memremap() semantics.

For instance since memremap() only has 2 types right now can a respective
fallback be documented as an alternative to help with this ? Or can we not
generalize this ?  One for MEMREMAP_WB and one for MEMREMAP_WT ?

> ioremap() falls back to the cache type of an existing mapping to avoid
> aliasing.

Does that assume an existing ioremap*() call was used on a bigger range?
Do you know if that happens to only be the case for x86 (I'd think so)
or if its the same for other architectures ?

While at it, Dan, will / should memremap() support overlapping calls ?
What is the expectation on behaviour ?

PS: I did see you reply about this being about lacking an arch implementation
for a memremap() type, not a cache type, but as the driver uses one memremap()
type the goal for a region is just as important as the resulting type.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/