linux-kernel - Re: [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map

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] [day] [month] [year] [list]

Message-ID: <20160420212347.GR1990@wotan.suse.de>
Date:	Wed, 20 Apr 2016 23:23:47 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	intel-gfx@...ts.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
	Mika Kuoppala <mika.kuoppala@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@...el.com>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	David Airlie <airlied@...ux.ie>,
	Yishai Hadas <yishaih@...lanox.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	David Hildenbrand <dahi@...ux.vnet.ibm.com>,
	dri-devel@...ts.freedesktop.org, netdev@...r.kernel.org,
	linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/19] io-mapping: Specify mapping size for
 io_mapping_map_wc()

On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> > > 
> > > Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@...el.com>
> > > Cc: Daniel Vetter <daniel.vetter@...el.com>
> > > Cc: Jani Nikula <jani.nikula@...ux.intel.com>
> > > Cc: David Airlie <airlied@...ux.ie>
> > > Cc: Yishai Hadas <yishaih@...lanox.com>
> > > Cc: Dan Williams <dan.j.williams@...el.com>
> > > Cc: Ingo Molnar <mingo@...nel.org>
> > > Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>
> > > Cc: David Hildenbrand <dahi@...ux.vnet.ibm.com>
> > > Cc: Luis R. Rodriguez <mcgrof@...nel.org>
> > > Cc: intel-gfx@...ts.freedesktop.org
> > > Cc: dri-devel@...ts.freedesktop.org
> > > Cc: netdev@...r.kernel.org
> > > Cc: linux-rdma@...r.kernel.org
> > > Cc: linux-kernel@...r.kernel.org
> > 
> > We have 2 callers today, in the future, can you envision
> > this API getting more options? If so, in order to avoid the
> > pain of collateral evolutions I can suggest a descriptor
> > being passed with the required settings / options. This lets
> > you evolve the API without needing to go in and modify
> > old users. If you choose not to that's fine too, just
> > figured I'd chime in with that as I've seen the pain
> > with other APIs, and I'm putting an end to the needless
> > set of collateral evolutions this way.
> 
> Do you have a good example in mind? I've one more patch to try and take
> advantage of the io-mapping (that may or not be such a good idea in
> practice) but I may as well see if I can make io_mapping more useful
> when I do.

Sure, here's my current version of the revamp of the firmware API
to a more flexible API, which lets us compartamentalize the
usermode helper, and through the new API avoids the issues with further
future collateral evolutions. It is still being baked, I'm fine tuning
the SmPL to folks automatically do conversion if they want:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160417-sysdata-api-v1

It also has a test driver (which I'd also recommend if you can pull off).
It would be kind of hard to do something like a lib/io-mapping_test.c
given there is no real device to ioremap -- _but_ perhaps regular
RAM can be used for fake a device MMIO. I am not sure if its even
possible... but if so it would not only be useful for something
like your API but also for testing ioremap() and friends, and
any possible aliasing bombs we may want to vet for. It also hints
how we may in the future be able to automatically write test drivers
for APIs for us through inference, but that needs a lot of more love
to make it tangible.

  Luis