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

[Christoph Hellwig]

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@xxxxxxx> 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.