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]
Date: Thu, 07 Mar 2024 14:06:45 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andreas Larsson" <andreas@...sler.com>,
 "Sam Ravnborg" <sam@...nborg.org>, "Maciej W. Rozycki" <macro@...am.me.uk>,
 sparclinux@...r.kernel.org, "Randy Dunlap" <rdunlap@...radead.org>
Cc: "Miquel Raynal" <miquel.raynal@...tlin.com>,
 linux-parport@...ts.infradead.org, "David S . Miller" <davem@...emloft.net>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/7] sparc32: Do not select ZONE_DMA

On Thu, Mar 7, 2024, at 13:42, Andreas Larsson wrote:
> On 2024-03-06 19:19, Arnd Bergmann wrote:
>
>> I still don't know the history behind this choice, but I
>> see this was already configured the same when arch/sparc/
>> was originally merged. You can probably change it to a more
>> sensible 0xc0000000 or 0x80000000 like on other
>> architectures and run without highmem on anything with
>> less than 2GB of total RAM.
>> 
>> How much RAM do Leon machines have typically, or at the
>> maximum?
> The amount of RAM can vary greatly between systems, from less that
> 128 MiB up to 2 GiB. An upcoming design uses the entire 36-bit
> physical address space and have the possibility of having up to 60
> GiB memory.

If the current maximum is 2GiB, that would be easily handled
by making PAGE_OFFSET configurable the same way that x86 or
arm do, where the common CONFIG_VMSPLIT_3G would extend lowmem
from 192MiB to a little under 1GiB, with PAGE_OFFSET 0xc0000000,
and VMSPLIT_2G_OPT allows exactly 2GiB of lowmem, plus a little
under 2GiB of user addressing.

This would also be an improvement over using highmem for
most applications today, and it means you can keep using the
same setup once highmem support gets removed from the kernel.

For a new design, I would strongly advise against advertising
support for more than 2GiB on a 32-bit Linux kernel, as this
is likely to not be supportable in the future. Note that
in the best case today (40 byte struct page), the mem_map[]
array uses 10MiB of lowmem per GiB installed memory, so you
quickly run out of lowmem when you allow more RAM.

     Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ