From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@kernel.org>, Chao Ye <cye@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
guanghuifeng@linux.alibaba.com, mark.rutland@arm.com,
will@kernel.org, linux-mm@kvack.org, thunder.leizhen@huawei.com,
wangkefeng.wang@huawei.com, kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
Date: Fri, 30 Sep 2022 17:24:48 +0800 [thread overview]
Message-ID: <Yza14IroN9Ke/3uN@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YzaU99WgKFzpSN4P@MiWiFi-R3L-srv>
On 09/30/22 at 03:04pm, Baoquan He wrote:
> Hi Mike,
>
> On 09/21/22 at 10:45am, Mike Rapoport wrote:
> > On Tue, Sep 06, 2022 at 03:05:57PM +0200, Ard Biesheuvel wrote:
> > >
> > > While I appreciate the effort that has gone into solving this problem,
> > > I don't think there is any consensus that an elaborate fix is required
> > > to ensure that the crash kernel can be unmapped from the linear map at
> > > all cost. In fact, I personally think we shouldn't bother, and IIRC,
> > > Will made a remark along the same lines back when the Huawei engineers
> > > were still driving this effort.
> > >
> > > So perhaps we could align on that before doing yet another version of this?
> >
> > I suggest to start with disabling crash kernel protection when its memory
> > reservation is deferred and then Baoquan and kdump folks can take it from
> > here.
>
> Thanks for the attempt, really appreciated. We all tried and all see
> everybody's effort on this issue.
>
> If disabling protection is chosen, I would suggest disable it at all.
> The system w/o having CONFIG_ZONE_DMA|32 is rarely seen, I don't think
> we need do the protection for it specifically to make code inconsistent
> and could confuse people. We can revert below commit and its later
> change do to that.
>
> commit 98d2e1539b84 ("arm64: kdump: protect crash dump kernel memory")
>
> For RPi4, I tried to find one to test and figure out if it can do crash
> dumping with buffer above 1G. However, nobody care about kdump when I
> asked people around who have one at hand for testing, hobby, or
> developping. Since they are not familiar with kdump setting and not so
> eager to get to know, and I don't want to take up too much time, finally
> I just give up.
Finally, I got help from Chao who is team lead of our kernel QE. Chao
has a RPi4 and he tested different cases of kdump, now we can confirm
that on RPi4 the TF card and usb disk are all 30bit DMA addressing
limited. Just FYI. And thanks again to Chao for his help and patience.
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@kernel.org>, Chao Ye <cye@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
guanghuifeng@linux.alibaba.com, mark.rutland@arm.com,
will@kernel.org, linux-mm@kvack.org, thunder.leizhen@huawei.com,
wangkefeng.wang@huawei.com, kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
Date: Fri, 30 Sep 2022 17:24:48 +0800 [thread overview]
Message-ID: <Yza14IroN9Ke/3uN@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YzaU99WgKFzpSN4P@MiWiFi-R3L-srv>
On 09/30/22 at 03:04pm, Baoquan He wrote:
> Hi Mike,
>
> On 09/21/22 at 10:45am, Mike Rapoport wrote:
> > On Tue, Sep 06, 2022 at 03:05:57PM +0200, Ard Biesheuvel wrote:
> > >
> > > While I appreciate the effort that has gone into solving this problem,
> > > I don't think there is any consensus that an elaborate fix is required
> > > to ensure that the crash kernel can be unmapped from the linear map at
> > > all cost. In fact, I personally think we shouldn't bother, and IIRC,
> > > Will made a remark along the same lines back when the Huawei engineers
> > > were still driving this effort.
> > >
> > > So perhaps we could align on that before doing yet another version of this?
> >
> > I suggest to start with disabling crash kernel protection when its memory
> > reservation is deferred and then Baoquan and kdump folks can take it from
> > here.
>
> Thanks for the attempt, really appreciated. We all tried and all see
> everybody's effort on this issue.
>
> If disabling protection is chosen, I would suggest disable it at all.
> The system w/o having CONFIG_ZONE_DMA|32 is rarely seen, I don't think
> we need do the protection for it specifically to make code inconsistent
> and could confuse people. We can revert below commit and its later
> change do to that.
>
> commit 98d2e1539b84 ("arm64: kdump: protect crash dump kernel memory")
>
> For RPi4, I tried to find one to test and figure out if it can do crash
> dumping with buffer above 1G. However, nobody care about kdump when I
> asked people around who have one at hand for testing, hobby, or
> developping. Since they are not familiar with kdump setting and not so
> eager to get to know, and I don't want to take up too much time, finally
> I just give up.
Finally, I got help from Chao who is team lead of our kernel QE. Chao
has a RPi4 and he tested different cases of kdump, now we can confirm
that on RPi4 the TF card and usb disk are all 30bit DMA addressing
limited. Just FYI. And thanks again to Chao for his help and patience.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@kernel.org>, Chao Ye <cye@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
guanghuifeng@linux.alibaba.com, mark.rutland@arm.com,
will@kernel.org, linux-mm@kvack.org, thunder.leizhen@huawei.com,
wangkefeng.wang@huawei.com, kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
Date: Fri, 30 Sep 2022 17:24:48 +0800 [thread overview]
Message-ID: <Yza14IroN9Ke/3uN@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YzaU99WgKFzpSN4P@MiWiFi-R3L-srv>
On 09/30/22 at 03:04pm, Baoquan He wrote:
> Hi Mike,
>
> On 09/21/22 at 10:45am, Mike Rapoport wrote:
> > On Tue, Sep 06, 2022 at 03:05:57PM +0200, Ard Biesheuvel wrote:
> > >
> > > While I appreciate the effort that has gone into solving this problem,
> > > I don't think there is any consensus that an elaborate fix is required
> > > to ensure that the crash kernel can be unmapped from the linear map at
> > > all cost. In fact, I personally think we shouldn't bother, and IIRC,
> > > Will made a remark along the same lines back when the Huawei engineers
> > > were still driving this effort.
> > >
> > > So perhaps we could align on that before doing yet another version of this?
> >
> > I suggest to start with disabling crash kernel protection when its memory
> > reservation is deferred and then Baoquan and kdump folks can take it from
> > here.
>
> Thanks for the attempt, really appreciated. We all tried and all see
> everybody's effort on this issue.
>
> If disabling protection is chosen, I would suggest disable it at all.
> The system w/o having CONFIG_ZONE_DMA|32 is rarely seen, I don't think
> we need do the protection for it specifically to make code inconsistent
> and could confuse people. We can revert below commit and its later
> change do to that.
>
> commit 98d2e1539b84 ("arm64: kdump: protect crash dump kernel memory")
>
> For RPi4, I tried to find one to test and figure out if it can do crash
> dumping with buffer above 1G. However, nobody care about kdump when I
> asked people around who have one at hand for testing, hobby, or
> developping. Since they are not familiar with kdump setting and not so
> eager to get to know, and I don't want to take up too much time, finally
> I just give up.
Finally, I got help from Chao who is team lead of our kernel QE. Chao
has a RPi4 and he tested different cases of kdump, now we can confirm
that on RPi4 the TF card and usb disk are all 30bit DMA addressing
limited. Just FYI. And thanks again to Chao for his help and patience.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-09-30 9:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-28 0:55 [PATCH 0/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end Baoquan He
2022-08-28 0:55 ` Baoquan He
2022-08-28 0:55 ` Baoquan He
2022-08-28 0:55 ` [PATCH 1/2] " Baoquan He
2022-08-28 0:55 ` Baoquan He
2022-08-28 0:55 ` Baoquan He
2022-08-31 1:50 ` Leizhen (ThunderTown)
2022-08-31 1:50 ` Leizhen (ThunderTown)
2022-08-31 1:50 ` Leizhen (ThunderTown)
2022-08-31 7:37 ` Mike Rapoport
2022-08-31 7:37 ` Mike Rapoport
2022-08-31 7:37 ` Mike Rapoport
2022-08-31 14:29 ` Baoquan He
2022-08-31 14:29 ` Baoquan He
2022-08-31 14:29 ` Baoquan He
2022-09-01 7:24 ` Mike Rapoport
2022-09-01 7:24 ` Mike Rapoport
2022-09-01 7:24 ` Mike Rapoport
2022-09-01 12:25 ` Baoquan He
2022-09-01 12:25 ` Baoquan He
2022-09-01 12:25 ` Baoquan He
2022-09-05 10:28 ` Mike Rapoport
2022-09-05 10:28 ` Mike Rapoport
2022-09-05 10:28 ` Mike Rapoport
2022-09-05 12:08 ` Baoquan He
2022-09-05 12:08 ` Baoquan He
2022-09-05 12:08 ` Baoquan He
2022-09-06 13:05 ` Ard Biesheuvel
2022-09-06 13:05 ` Ard Biesheuvel
2022-09-06 13:05 ` Ard Biesheuvel
2022-09-08 13:33 ` Baoquan He
2022-09-08 13:33 ` Baoquan He
2022-09-08 13:33 ` Baoquan He
2022-09-08 22:55 ` Baoquan He
2022-09-08 22:55 ` Baoquan He
2022-09-08 22:55 ` Baoquan He
2022-09-21 7:45 ` Mike Rapoport
2022-09-21 7:45 ` Mike Rapoport
2022-09-21 7:45 ` Mike Rapoport
2022-09-30 7:04 ` Baoquan He
2022-09-30 7:04 ` Baoquan He
2022-09-30 7:04 ` Baoquan He
2022-09-30 9:24 ` Baoquan He [this message]
2022-09-30 9:24 ` Baoquan He
2022-09-30 9:24 ` Baoquan He
2022-08-28 0:55 ` [PATCH 2/2] arm64: remove unneed defer_reserve_crashkernel() and crash_mem_map Baoquan He
2022-08-28 0:55 ` Baoquan He
2022-08-28 0:55 ` Baoquan He
2022-08-31 1:51 ` Leizhen (ThunderTown)
2022-08-31 1:51 ` Leizhen (ThunderTown)
2022-08-31 1:51 ` Leizhen (ThunderTown)
2022-08-28 1:57 ` [PATCH 0/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end Baoquan He
2022-08-28 1:57 ` Baoquan He
2022-08-28 1:57 ` Baoquan He
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=Yza14IroN9Ke/3uN@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cye@redhat.com \
--cc=guanghuifeng@linux.alibaba.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=rppt@kernel.org \
--cc=thunder.leizhen@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
/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.