linux-kernel - Re: [PATCH -next] crash: Fix riscv64 crash memory reserve dead loop

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: <ZrtLz8VHzZIULbOT@arm.com>
Date: Tue, 13 Aug 2024 13:04:31 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Petr Tesařík <petr@...arici.cz>
Cc: Baoquan He <bhe@...hat.com>, Jinjie Ruan <ruanjinjie@...wei.com>,
	vgoyal@...hat.com, dyoung@...hat.com, paul.walmsley@...ive.com,
	palmer@...belt.com, aou@...s.berkeley.edu, chenjiahao16@...wei.com,
	akpm@...ux-foundation.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, Will Deacon <will@...nel.org>
Subject: Re: [PATCH -next] crash: Fix riscv64 crash memory reserve dead loop

Hi Petr,

On Tue, Aug 13, 2024 at 10:40:06AM +0200, Petr Tesařík wrote:
> On Tue, 6 Aug 2024 20:34:42 +0100
> Catalin Marinas <catalin.marinas@....com> wrote:
> > I haven't tried but it's possible that this patch also breaks those
> > arm64 platforms with all RAM above 4GB when CRASH_ADDR_LOW_MAX is
> > memblock_end_of_DRAM(). Here all memory would be low and in the absence
> > of no fallback, it fails to allocate.
> 
> I'm afraid you've just opened a Pandora box... ;-)

Not that bad ;) but, yeah, this patch was dropped in favour of this:

https://lore.kernel.org/r/20240812062017.2674441-1-ruanjinjie@huawei.com/

> Another (unrelated) patch series made us aware of a platforms where RAM
> starts at 32G, but IIUC the host bridge maps 32G-33G to bus addresses
> 0-1G, and there is a device on that bus which can produce only 30-bit
> addresses.
> 
> Now, what was the idea behind allocating some crash memory "low"?
> Right, it should allow the crash kernel to access devices with
> addressing constraints. So, on the above-mentioned platform, allocating
> "low" would in fact mean allocating between 32G and 33G (in host address
> domain).

Indeed. If that's not available, the crash kernel won't be able to boot
(unless the corresponding device is removed from DT or ACPI tables).

> Should we rethink the whole concept of high/low?

Yeah, it would be good to revisit those at some point. For the time
being, 'low' in this context on arm64 means ZONE_DMA memory, basically
the common denominator address range that supports all devices on an
SoC. For others like x86_32, this means the memory that the kernel can
actually map (not necessarily device/DMA related).

So, it's not always about the DMA capabilities but also what the crash
kernel can map (so somewhat different from the zone allocator case we've
been discussing in other threads).

-- 
Catalin