From: Catalin Marinas <catalin.marinas@arm.com>
To: chenzhou <chenzhou10@huawei.com>
Cc: song.bao.hua@hisilicon.com, xiexiuqi@huawei.com,
linux-kernel@vger.kernel.org, rppt@kernel.org,
huawei.libin@huawei.com, akpm@linux-foundation.org,
will@kernel.org, ardb@kernel.org,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64: mm: fix kdump broken with ZONE_DMA reintroduced
Date: Thu, 7 Jan 2021 18:34:01 +0000 [thread overview]
Message-ID: <20210107183400.GB26159@gaia> (raw)
In-Reply-To: <deeb19d6-29e2-f76e-9e28-6ad77c7cb1fa@huawei.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: chenzhou <chenzhou10@huawei.com>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
will@kernel.org, ardb@kernel.org, akpm@linux-foundation.org,
rppt@kernel.org, song.bao.hua@hisilicon.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, huawei.libin@huawei.com,
xiexiuqi@huawei.com
Subject: Re: [PATCH 2/2] arm64: mm: fix kdump broken with ZONE_DMA reintroduced
Date: Thu, 7 Jan 2021 18:34:01 +0000 [thread overview]
Message-ID: <20210107183400.GB26159@gaia> (raw)
In-Reply-To: <deeb19d6-29e2-f76e-9e28-6ad77c7cb1fa@huawei.com>
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
next prev parent reply other threads:[~2021-01-07 18:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-26 3:35 [PATCH 0/2] arm64: mm: fix kdump broken with ZONE_DMA reintroduced Chen Zhou
2020-12-26 3:35 ` Chen Zhou
2020-12-26 3:35 ` [PATCH 1/2] arm64: mm: update the comments about ZONE_DMA Chen Zhou
2020-12-26 3:35 ` Chen Zhou
2020-12-26 10:35 ` Nicolas Saenz Julienne
2020-12-26 10:35 ` Nicolas Saenz Julienne
2020-12-26 3:35 ` [PATCH 2/2] arm64: mm: fix kdump broken with ZONE_DMA reintroduced Chen Zhou
2020-12-26 3:35 ` Chen Zhou
2020-12-26 10:34 ` Nicolas Saenz Julienne
2020-12-26 10:34 ` Nicolas Saenz Julienne
2020-12-28 7:32 ` chenzhou
2020-12-28 7:32 ` chenzhou
2021-01-07 18:34 ` Catalin Marinas [this message]
2021-01-07 18:34 ` Catalin Marinas
2021-01-07 14:25 ` Catalin Marinas
2021-01-07 14:25 ` Catalin Marinas
2021-01-08 1:09 ` chenzhou
2021-01-08 1:09 ` chenzhou
2021-01-20 12:40 ` [PATCH 0/2] " Will Deacon
2021-01-20 12:40 ` Will Deacon
2021-01-20 13:07 ` Catalin Marinas
2021-01-20 13:07 ` Catalin Marinas
2021-01-21 2:37 ` chenzhou
2021-01-21 2:37 ` chenzhou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210107183400.GB26159@gaia \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=chenzhou10@huawei.com \
--cc=huawei.libin@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nsaenzjulienne@suse.de \
--cc=rppt@kernel.org \
--cc=song.bao.hua@hisilicon.com \
--cc=will@kernel.org \
--cc=xiexiuqi@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.