From: Andrew Morton <akpm@linux-foundation.org>
To: Baoquan He <bhe@redhat.com>
Cc: nicolas.pitre@linaro.org, brijesh.singh@amd.com,
devicetree@vger.kernel.org, airlied@linux.ie,
linux-pci@vger.kernel.org, richard.weiyang@gmail.com,
jcmvbkbc@gmail.com, baiyaowei@cmss.chinamobile.com,
kys@microsoft.com, frowand.list@gmail.com, tglx@linutronix.de,
lorenzo.pieralisi@arm.com, sthemmin@microsoft.com,
linux-nvdimm@lists.01.org, patrik.r.jakobsson@gmail.com,
andy.shevchenko@gmail.com, linux-input@vger.kernel.org,
gustavo@padovan.org, bp@suse.de, dyoung@redhat.com,
thomas.lendacky@amd.com, haiyangz@microsoft.com,
maarten.lankhorst@linux.intel.com, josh@joshtriplett.org,
jglisse@redhat.com, robh+dt@kernel.org, seanpaul@chromium.org,
bhelgaas@google.com, yinghai@kernel.org,
jonathan.derrick@intel.com, chris@zankel.net, monstr@monstr.eu,
linux-parisc@vger.kernel.org, gregkh@linuxfoundation.org,
dmitry.torokhov@gmail.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
devel@linuxdriverproject.org, fengguang.wu@intel.com,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
Subject: Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
Date: Wed, 18 Jul 2018 15:33:26 -0700 [thread overview]
Message-ID: <20180718153326.b795e9ea7835432a56cd7011@linux-foundation.org> (raw)
In-Reply-To: <20180718024944.577-5-bhe@redhat.com>
On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He <bhe@redhat.com> wrote:
> For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
> is used to load kernel/initrd/purgatory is supposed to be allocated from
> top to down. This is what we have been doing all along in the old kexec
> loading interface and the kexec loading is still default setting in some
> distributions. However, the current kexec_file loading interface doesn't
> do like this. The function arch_kexec_walk_mem() it calls ignores checking
> kexec_buf.top_down, but calls walk_system_ram_res() directly to go through
> all resources of System RAM from bottom to up, to try to find memory region
> which can contain the specific kexec buffer, then call locate_mem_hole_callback()
> to allocate memory in that found memory region from top to down. This brings
> confusion especially when KASLR is widely supported , users have to make clear
> why kexec/kdump kernel loading position is different between these two
> interfaces in order to exclude unnecessary noises. Hence these two interfaces
> need be unified on behaviour.
As far as I can tell, the above is the whole reason for the patchset,
yes? To avoid confusing users.
Is that sufficient? Can we instead simplify their lives by providing
better documentation or informative printks or better Kconfig text,
etc?
And who *are* the people who are performing this configuration? Random
system administrators? Linux distro engineers? If the latter then
they presumably aren't easily confused!
In other words, I'm trying to understand how much benefit this patchset
will provide to our users as a whole.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-07-18 22:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 2:49 [PATCH v7 0/4] resource: Use list_head to link sibling resource Baoquan He
2018-07-18 2:49 ` [PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public Baoquan He
2018-07-18 16:36 ` Andy Shevchenko
2018-07-18 16:37 ` Andy Shevchenko
2018-07-19 15:18 ` Baoquan He
2018-07-18 2:49 ` [PATCH v7 2/4] resource: Use list_head to link sibling resource Baoquan He
2018-07-18 2:49 ` [PATCH v7 3/4] resource: add walk_system_ram_res_rev() Baoquan He
2018-07-18 2:49 ` [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required Baoquan He
2018-07-18 22:33 ` Andrew Morton [this message]
2018-07-19 15:17 ` Baoquan He
2018-07-19 19:44 ` Andrew Morton
2018-07-25 2:21 ` Baoquan He
2018-07-23 14:34 ` Michal Hocko
2018-07-25 6:48 ` Baoquan He
2018-07-26 12:59 ` Michal Hocko
2018-07-26 13:09 ` Baoquan He
2018-07-26 13:12 ` Michal Hocko
2018-07-26 13:14 ` Michal Hocko
2018-07-26 13:37 ` Baoquan He
2018-07-26 14:01 ` Michal Hocko
2018-07-26 15:10 ` 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=20180718153326.b795e9ea7835432a56cd7011@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=airlied@linux.ie \
--cc=andy.shevchenko@gmail.com \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=chris@zankel.net \
--cc=davem@davemloft.net \
--cc=devel@linuxdriverproject.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=fengguang.wu@intel.com \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo@padovan.org \
--cc=haiyangz@microsoft.com \
--cc=jcmvbkbc@gmail.com \
--cc=jglisse@redhat.com \
--cc=jonathan.derrick@intel.com \
--cc=josh@joshtriplett.org \
--cc=kexec@lists.infradead.org \
--cc=kys@microsoft.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=monstr@monstr.eu \
--cc=nicolas.pitre@linaro.org \
--cc=patrik.r.jakobsson@gmail.com \
--cc=richard.weiyang@gmail.com \
--cc=robh+dt@kernel.org \
--cc=seanpaul@chromium.org \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).