linux-kernel - Re: swiotlb: remove __weak hooks in favour of architecture-specific functions

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]

Date:	Fri, 22 May 2009 15:02:04 +0100
From:	Ian Campbell <Ian.Campbell@...citrix.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
CC:	"mingo@...e.hu" <mingo@...e.hu>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"beckyb@...nel.crashing.org" <beckyb@...nel.crashing.org>,
	"okir@...e.de" <okir@...e.de>, "gregkh@...e.de" <gregkh@...e.de>,
	"xendevel@...ts.xensource.com" <xendevel@...ts.xensource.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: swiotlb: remove __weak hooks in favour of
	architecture-specific functions

On Fri, 2009-05-22 at 07:55 -0400, FUJITA Tomonori wrote:
> On Fri, 22 May 2009 12:43:16 +0100
> Ian Campbell <Ian.Campbell@...citrix.com> wrote:
> 
> > On Fri, 2009-05-22 at 07:13 -0400, FUJITA Tomonori wrote:
> > > On Thu, 21 May 2009 17:15:21 +0100
> > > Ian Campbell <ian.campbell@...rix.com> wrote:
> > > Please go with the following way (that I posted yesterday):
> > > 
> > > http://marc.info/?l=xen-devel&m=124292666214380&w=2
> > > 
> > > 
> > > Export the core feature of swiotlb, managing iotlb buffer and
> > > implement the Xen mapping functions.
> > 
> > I feel that should be a last resort, before we go down that path we
> > should try and find a way for us to use the generic code in a clean way
> > which makes everyone happy.
> >
> > We have had several attempts at this and admittedly have not yet come up
> > with something that satisfies everyone but I don't really think we have
> > gotten to the point of admitting defeat and just duplicating the code.
> 
> There should not be much duplication.
> 
> 
> > I think the proposal to use a dma_map_range-like function which I sent a
> > few minutes ago I think gets us closer to something which satisfies
> > everyone's requirements, including yours for a clean abstraction.
> 
> Seems you don't understand the point; with dom0, we can't cleanly use
> arch/*/include/asm/.

I understand precisely what you are saying, I just fundamentally
disagree with you. It is perfectly possible for an arch/*/include/asm
interface for this stuff to be defined which is completely abstracted
from the POV of the swiotlb code (and any other arch-external code).

> You need to insert Xen's hook like this:

As I said in the email this snippet was contained in:
>       * The Xen specific stuff in arch/x86/include/asm/dma-mapping.h
>         clearly needs to be properly abstracted away (I just stuck it
>         there for testing).

So obviously I am well aware that it is unacceptable as it stands.

I think we can find a way to implement this functionality which is
contained entirely within the arch/x86 code and is also acceptable to
the x86 maintainers. There are plenty of cases where we define similar
interfaces where arch code implements an API with different backends for
different configurations, hardware configurations etc etc.

> See above. POWERPC can use arch/*/include/asm/ cleanly for the
> phys/bus address conversion while dom0 can't. That's what I said again
> and again.

And I dispute this claim, again and again.

Ian.

--
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/