Re: [PATCH 1/4] virtio_console: copy pipe buffers in splice_write()

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Nov 11, 2026, at 20:26, Linus Torvalds wrote:
> On Wed, 11 Nov 2026 at 10:53, Christian Brauner <brauner@kernel.org> wrote:
>>
>> If that's the official new stance than I'm very happy.
>
> I definitely want to remove HIGHMEM entirely in the not too distant
> future. And before we remove it, we can most definitely document the
> fact that we will not be worried about insane users.
>
> And things like security issues count as "insane user": if you use
> HIGHMEM outside of controlled embedded setups or museum pieces you get
> to keep both pieces when it breaks.
>
> IOW, it's legacy. We should aim to not introduce *new* bugs to it, but
> if there are pre-existing bugs they very much count as "don't care",
> this will be removed soon.

Agreed. There is also the option of adding Kconfig dependencies to
mark things that are known broken with highmem when we either know
that it is buggy, or we have a good reason to break something that
none of those remaining users should be using.

> I think the only reason it wasn't removed a couple of years ago
> already is basically a few old 32-bit ARM platforms that still used
> it.
>
> Those platforms still exist, and I predict that they'll still exist
> next year, but if those users have to stay at the current LTS kernel,
> that's fine.

I tried to push for what I thought was an aggressive timeline
last year, but that would still keep the Arm bits for a couple more
LTS releases and only gradually reduce the scope of highmem in the
meantime, removing support from architectures, file systems, and
drivers where possible. See https://lwn.net/Articles/1051010/
for a summary of my talk in Tokyo, including the slides and
a link to the video for anyone wanting more details.

I also prepared a number of patches towards this, but have so
far not been great at following up to get them merged, sorry
about that.
I definitely still want to revisit this soon, in particular the
bits about defaulting to VMSPLIT_2G_OPT, and probably my patch
to allow having (limited) discontiguous lowmem on Arm systems
with a large MMIO hole.

Scope-wise I think we absolutely need zsmalloc (zram/zswap)
on arm32 to work with GFP_HIGHUSER, but enough people have told me
that they still expect to need anonymous memory and ext4 page
cache for a while, and probably powerpc32. The majority
of __GFP_HIGHMEM allocations can probably just be converted
to use lowmem, which would eliminate a good chunk of kmap()
calls as well. In my attempts to do that, I came across two
problems I'd have to solve though:

 - Movable allocations (GFP_HIGHUSER_MOVABLE) imply highmem.
   while I think only 64-bit architectures support movable
   pages today, we cannot currently express an allocation
   that should be movable on 64-bit but lowmem on 32-bit.

 - Internal users of tmpfs (in particular DRM/GEM) usually
   don't want highmem or movable pages, but actual tmpfs
   does default to GFP_HIGHUSER_MOVABLE. Separating the two
   is complicated.

I added a few people to Cc here that I believe care about
having several more LTS releases with some highmem support
because of existing customer requirements.

     Arnd