linux-kernel - Re: [GIT PULL] (swiotlb) stable/for-linus-5.15

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: <YTGuGGxAoWMB9/Mg@infradead.org>
Date:   Fri, 3 Sep 2021 06:09:44 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Robin Murphy <robin.murphy@....com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Christoph Hellwig <hch@...radead.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Claire Chang <tientzu@...omium.org>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Will Deacon <will@...nel.org>, pasic@...ux.ibm.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] (swiotlb) stable/for-linus-5.15

On Thu, Sep 02, 2021 at 05:42:11PM -0700, Linus Torvalds wrote:
> On Thu, Sep 2, 2021 at 2:55 PM Robin Murphy <robin.murphy@....com> wrote:
> >
> > Not to defend the state things have got into - frankly I've found it
> > increasingly hard to follow for some time now too - but I believe the
> > unwritten story is of the one true dma-direct trying to be all things to
> > all users, and there are several aspects at play here which are mutually
> > exclusive in practice.
> 
> Ugh.
> 
> Some of that "mutual exclusion" seems to be encoded in peoples heads,
> not in the code itself.

Some of it is.  This is mostly because we're still most in stage 1
of the grand plan:

  "consolidate 100% identical concepts various architectures reimplement"

which will slowly give way to actually clean up various mostly the same
concepts.  And the big items here is the various pools.  This simple
coherent pool and the one we use for GFP_ATOMIC alloctions for
not coherent devices would be a very obvious first step.  Swiotlb would
be the next one, but it is much more complicated as swiotlb is messy
and has a rather "special" allocator algorithm.

> 
> > The global pool is essentially for noMMU, so should not be expected to
> > overlap with SWIOTLB at all, much less systems using restricted DMA.
> 
> If I read that right, you're saying that in this case, the possible
> mis-merge doesn't matter?

Currently (and for the foreseeable future) it does not matter.


> Except the dispatch logic ends up being all those different cases that
> have nothing to do with each other, because people have very clearly
> tried to avoid code duplication by just saying "ok, in these two
> entirely unrelated situations, we do the same thing".

Not just that.  There are plenty of cases where architectures need
multiple of these cases depending on runtime checks.

But yes, this funtion turned into a mess, and we can improve both
the overall structure and the omments explaining it a fair bit.