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