linux-kernel - Re: [PATCH 2/2] arm64: mm: fix kdump broken with ZONE

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, 7 Jan 2021 18:34:01 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     chenzhou <chenzhou10@...wei.com>
Cc:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>, will@...nel.org,
        ardb@...nel.org, akpm@...ux-foundation.org, rppt@...nel.org,
        song.bao.hua@...ilicon.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, huawei.libin@...wei.com,
        xiexiuqi@...wei.com
Subject: Re: [PATCH 2/2] arm64: mm: fix kdump broken with ZONE_DMA
 reintroduced

On Mon, Dec 28, 2020 at 03:32:35PM +0800, chenzhou wrote:
> On 2020/12/26 18:34, Nicolas Saenz Julienne wrote:
> > On Sat, 2020-12-26 at 11:35 +0800, Chen Zhou wrote:
> >> If the memory reserved for crash dump kernel falled in ZONE_DMA32,
> >> the devices in crash dump kernel need to use ZONE_DMA will alloc fail.
> >>
> >> Fix this by reserving low memory in ZONE_DMA if CONFIG_ZONE_DMA is
> >> enabled, otherwise, reserving in ZONE_DMA32.
> >>
> >> Fixes: bff3b04460a8 ("arm64: mm: reserve CMA and crashkernel in ZONE_DMA32")
> > I'm not so sure this counts as a fix, if someone backports it it'll probably
> > break things as it depends on the series that dynamically sizes DMA zones.
> 
> I write this just because kdump is broken from this commit.

Commit bff3b04460a8 actually fixed a regression introduced by the
limited 30-bit ZONE_DMA, under the assumption that RPi4 is the only
platform that cares about this. I agree a kdump kernel will fail to get
memory in the low zone but it's not clear to me whether the regression
you are seeing happened in 5.11-rc1 or you it's been around since 5.5.

We may have got away before because max_zone_phys() assumed an implicit
DMA offset equal to the start of the DRAM (well, power of two). This
assumption was removed in 5.11 by commit 791ab8b2e3db ("arm64: Ignore
any DMA offsets in the max_zone_phys() calculation").

So your patch or the clean-up I posted only makes sense with the dynamic
ZONE_DMA patches in 5.11-rc1. For any earlier version, I don't have any
suggestion other than not enabling CONFIG_ZONE_DMA in the kdump kernel
(or backporting all of Nicolas' patches).

I'll post my clean-up separately to go into 5.11 but won't have a fixes
tag for bff3b04460a8.

-- 
Catalin