linux-kernel - Re: [RFC} arm architecture board/feature deprecation timeline

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]

Message-Id: <35680bf8-d4f0-4b7a-b358-f71eb39e2a94@app.fastmail.com>
Date: Mon, 26 Aug 2024 16:55:23 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Walleij" <linus.walleij@...aro.org>,
 "Vincent Legoll" <vincent.legoll@...il.com>
Cc: "Aaro Koskinen" <aaro.koskinen@....fi>,
 "Alexandre Torgue" <alexandre.torgue@...s.st.com>,
 "Andrew Lunn" <andrew@...n.ch>, "Mark Brown" <broonie@...nel.org>,
 "Dmitry Torokhov" <dmitry.torokhov@...il.com>,
 "Gregory Clement" <gregory.clement@...tlin.com>,
 "Jeremy J. Peper" <jeremy@...emypeper.com>,
 "Janusz Krzysztofik" <jmkrzyszt@...il.com>,
 "Kristoffer Ericson" <kristoffer.ericson@...il.com>,
 "Krzysztof Kozlowski" <krzk@...nel.org>,
 "Linux Kernel ML" <linux-kernel@...r.kernel.org>,
 "Russell King" <linux@...linux.org.uk>, "Nicolas Pitre" <nico@...xnic.net>,
 "Nikita Shubin" <nikita.shubin@...uefel.me>,
 "Ramana Radhakrishnan" <ramanara@...dia.com>,
 "Richard Earnshaw" <richard.earnshaw@....com>,
 "Richard Sandiford" <richard.sandiford@....com>,
 "Robert Jarzmik" <robert.jarzmik@...e.fr>,
 "Sebastian Hesselbarth" <sebastian.hesselbarth@...il.com>,
 "Tony Lindgren" <tony@...mide.com>, linux-mips@...r.kernel.org
Subject: Re: [RFC} arm architecture board/feature deprecation timeline

On Mon, Aug 26, 2024, at 11:05, Linus Walleij wrote:
> On Fri, Aug 23, 2024 at 10:47 PM Vincent Legoll
> <vincent.legoll@...il.com> wrote:
>
>> It looks like the highmem feature is deemed for removal.
>>
>> I am investigating the loss of some available RAM on a GnuBee PC1 board.
>>
>> An highmem-enabled kernel can access a 64MB chunk of RAM that a
>> no-highmem can't. The board has 512 MB.

There have been problems in the past with configurations that have a lot
less highmem than lowmem, since there is codce that assumes that
lowmem is scarce but highmem is not.

This means your configuration may have more RAM available when highmem
is enabled, but still runs into out-of-memory or other problems more
than without highmem.

What you see is certainly unrelated to me mentioning that we may remove
highmem support from the kernel altogether in the future, but it's
possible that OpenWRT turned it off because things work better
without it. 

https://github.com/openwrt/openwrt/issues/13151 may explain
what ios going on here.

>> That's more than 10% on a RAM-poor NAS-oriented board, probably worth
>> the hassle to get it back.
>>
>> I built & flashed a current OpenWRT snapshot, without any modifications,
>> wich gave the following output:
> (...)
>> The lost RAM is back usable.
>>
>> Is there an alternative to CONFIG_HIGHMEM to use that RAM chunk ?
>
> Userspace can still use it right?
>
> The approach we are taking on ARM32 (despite it's.... really hard) is
> to try to create
> separate address spaces for the kernel and userspace so that in kernel context
> the kernel can use 4GB of memory as it wants without the restriction of userpace
> taking up the low addresses.
>
> This looks easy until you run into some kernel assumptions about memory being
> in a linear map at all times. Which I am wrestling with.

MIPS32 is a bit special here since it has segments with a fixed mapped, so
the linear map is always at a fixed virtual address and at most 512MB in
size, where most other architectures can make it e.g. 2GB by changing
CONFIG_VMPSPLIT.

CONFIG_CPU_MIPS32_3_5_EVA should allow doing this on MIPS as well,
but I think the 1004K core in this specific (MT7621) SoC is  little too
old to support that feature.

      Arnda