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: <20210107183400.GB26159@gaia>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ