linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,  Will Deacon <will@kernel.org>,
	Marc Zyngier <maz@kernel.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	 Ard Biesheuvel <ardb@kernel.org>, Christoph Hellwig <hch@lst.de>,
	 Isaac Manjarres <isaacmanjarres@google.com>,
	Saravana Kannan <saravanak@google.com>,
	linux-mm@kvack.org,  linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] treewide: Add the __GFP_PACKED flag to several non-DMA kmalloc() allocations
Date: Wed, 26 Oct 2022 10:46:46 -0700	[thread overview]
Message-ID: <CAHk-=whyZ8NduHPYUGz6PdpVSo3fPtUB6rPu1-wG3u2G8wvCcQ@mail.gmail.com> (raw)
In-Reply-To: <Y1kCimyUN1EiVFah@arm.com>

On Wed, Oct 26, 2022 at 2:49 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Linus originally suggested GFP_NODMA. We could go with that (and a
> corresponding KMALLOC_NODMA_MINALIGN).

If we do negative a "mark this for smaller allocations because it
cannot do DMA", then yes, I would still prefer GFP_NODMA to make it
explicit that it's about DMA.

But if we're marking allocations, I'd still prefer a "positive"
marking over a negative one, so it would still be much preferable to
just have GFP_DMA and various explicit DMA allocators.

One argument for doing it that way - aside from just the "let's use
positive markers, not negative ones" - is that then the pain of
discovery ends up being solidly on the broken cases, not on sane
architectures with sane platforms.

Seriously, non-cache coherent DMA in 2022 is a sign of an incompetent
platform architect or hardware designer, and at some point I think
that should just be called out for the incredible garbage it is.

It was always garbage, but at least it was excusable garbage back in
the days. And we have a long history of marking DMA allocations
specially, thanks to the original 16MB DMA limit of the ISA PC/AT
platform. That was garbage too, but hey, people acknowledged that, and
it got fixed.

I think we should just stop bending over backwards over this, and say
"if your DMA isn't coherent, it's on your driver to mark its
allocations".

Yes, yes, I realize that there are a billion devices. But not only is
the whole "a billion flies can't be wrong" still wrong, but most of
those billion devices often look remarkably similar, so it's not a
billion drivers. It's a few drivers, and a few driver subsystems, and
it sounds like Greg would prefer the "explicit dma allocations" at
least for USB.

And yes, there are also a few oddball people who love and stick to
their old broken hardware, in some kind of strange Stockholm syndrome
thing from fond memories of when they grew up with broken hardware and
they love the "quirks" of it.

That hardware may then be one of the one-off strange cases, but those
people with their masochistic tendencies can take the pain of "oh, now
I need to mark my broken driver with dma_alloc()". They'll probably
even enjoy it, the poor sods.

                     Linus


  parent reply	other threads:[~2022-10-26 17:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 20:52 [PATCH v2 0/2] mm: Allow kmalloc() allocations below ARCH_KMALLOC_MINALIGN Catalin Marinas
2022-10-25 20:52 ` [PATCH v2 1/2] mm: slab: Introduce __GFP_PACKED for smaller kmalloc() alignments Catalin Marinas
2022-10-26  6:39   ` Greg Kroah-Hartman
2022-10-26  8:39     ` Catalin Marinas
2022-10-26  9:49       ` Greg Kroah-Hartman
2022-10-26  9:58         ` Catalin Marinas
2022-10-27 12:11   ` Hyeonggon Yoo
2022-10-28  7:32     ` Catalin Marinas
2022-10-25 20:52 ` [PATCH v2 2/2] treewide: Add the __GFP_PACKED flag to several non-DMA kmalloc() allocations Catalin Marinas
2022-10-26  6:50   ` Greg Kroah-Hartman
2022-10-26  9:48     ` Catalin Marinas
2022-10-26 12:59       ` Greg Kroah-Hartman
2022-10-26 17:09         ` Catalin Marinas
2022-10-26 17:21           ` Greg Kroah-Hartman
2022-10-26 17:46       ` Linus Torvalds [this message]
2022-10-27 22:29         ` Catalin Marinas
2022-10-28  9:37           ` Greg Kroah-Hartman
2022-10-28  9:37             ` Greg Kroah-Hartman
2022-10-30  8:47               ` Christoph Hellwig
2022-10-30  9:02                 ` Greg Kroah-Hartman
2022-10-30  9:13                   ` Christoph Hellwig
2022-10-30 16:43                     ` Catalin Marinas
2022-11-01 10:59                       ` Christoph Hellwig
2022-11-01 17:19                         ` Catalin Marinas
2022-11-01 17:24                           ` Christoph Hellwig
2022-11-01 17:32                             ` Catalin Marinas
2022-11-01 17:39                               ` Christoph Hellwig
2022-11-01 19:10                                 ` Isaac Manjarres
2022-11-02 11:05                                   ` Catalin Marinas
2022-11-02 20:50                                     ` Isaac Manjarres
2022-11-01 18:14                           ` Robin Murphy
2022-11-02 13:10                             ` Catalin Marinas
2022-10-30  8:46           ` Christoph Hellwig
2022-10-30  8:44         ` Christoph Hellwig
2022-11-03 16:15       ` Vlastimil Babka
2022-11-03 18:03         ` Catalin Marinas
2022-10-26  6:54 ` [PATCH v2 0/2] mm: Allow kmalloc() allocations below ARCH_KMALLOC_MINALIGN Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=whyZ8NduHPYUGz6PdpVSo3fPtUB6rPu1-wG3u2G8wvCcQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=isaacmanjarres@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=maz@kernel.org \
    --cc=saravanak@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox