linux-kernel - Re: [PATCH 3/4] ARM: drop CONFIG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdb0g4zGQ-xu3yW=rRmz0zOVYnr-c-KaTSr155YvbrAv8A@mail.gmail.com>
Date: Wed, 11 Dec 2024 15:31:26 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Arnd Bergmann <arnd@...nel.org>, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>, linux-mm@...ck.org, 
	linux-rt-devel@...ts.linux.dev, Ard Biesheuvel <ardb@...nel.org>, 
	Clark Williams <clrkwllms@...nel.org>, Jason Baron <jbaron@...mai.com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Matthew Wilcox <willy@...radead.org>, Peter Zijlstra <peterz@...radead.org>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 3/4] ARM: drop CONFIG_HIGHPTE support

On Wed, Dec 11, 2024 at 2:51 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
> On Wed, Dec 11, 2024 at 02:32:51PM +0100, Linus Walleij wrote:
> > On Tue, Dec 10, 2024 at 5:06 PM Arnd Bergmann <arnd@...nel.org> wrote:
> >
> > > From: Arnd Bergmann <arnd@...db.de>
> > >
> > > CONFIG_HIGHPTE was added in linux-2.6.32, a few years before 64-bit
> > > support. At the time it made sense, as the CONFIG_ARM_LPAE option allowed
> > > systems with 16GB of memory that made lowmem a particularly scarce
> > > resource, and the HIGHPTE implementation gave feature parity with 32-bit
> > > x86 and frv machines.
> > >
> > > Since Arm is the last architecture remaining that uses this, and almost
> > > no 32-bit machines support more than 4GB of RAM, the cost of continuing
> > > to maintain HIGHPTE seems unjustified, so remove it here to allow
> > > simplifying the generic page table handling.
> > >
> > > Link: https://lore.kernel.org/lkml/20241204103042.1904639-8-arnd@kernel.org/T/#u
> > > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> >
> > I'm in favor of this if the x86 patch goes in. We need to get rid
> > of highmem anyway and this will need to happen sooner or later
> > either way.
>
> Well... I use highmem routinely.

Oh I don't mean we should get rid of it without any replacement. Certainly
systems with big physical memories need to be usable.

I am pursuing two ideas (inspired by Arnd and MM people):

1. The easy option - "densemem", on systems with a "hole" in the physical
    memory making the 1:1 linear phys-to-virt map run out too soon and
    overconsume virual memory, actually collect the physical memory on low
    virtual addresses by elaborate phys-to-virt virt-to-phys and page
    numbering that isn't 1:1.

2. The hard option - 4G-by-4G splitting, making the kernel and userspace
    virtual memory spaces separate as it is in hardware on S/390, so the
    kernel can use a while 4G of memory for its needs. I banged my head
    against this a fair amount of time, so I might be incompetent to do it,
    but I still try.

Yours,
Linus Walleij