From: Li Zhijian <lizhijian@fujitsu.com> To: kexec@lists.infradead.org, nvdimm@lists.linux.dev Cc: linux-kernel@vger.kernel.org, dan.j.williams@intel.com, bhe@redhat.com, ruansy.fnst@fujitsu.com, y-goto@fujitsu.com, yangx.jy@fujitsu.com, Li Zhijian <lizhijian@fujitsu.com>, Eric Biederman <ebiederm@xmission.com> Subject: [RFC PATCH v3 3/3] kernel/kexec_file: Mark pmem region with new flag PF_DEV Date: Fri, 2 Jun 2023 18:26:52 +0800 [thread overview] Message-ID: <20230602102656.131654-4-lizhijian@fujitsu.com> (raw) In-Reply-To: <20230602102656.131654-1-lizhijian@fujitsu.com> For pmem, metadata is specific to the namespace rather than the entire pmem region. Therefore, ranges that have not yet created a namespace or are unusable due to alignment reasons will not be associated with metadata. When an application attempts to access regions that do not have corresponding metadata, it will encounter an access error. With this flag, the dumping applications are able to know this access error, and then take special actions correspondingly. This is kexec_file_load() specific, for the traditional kexec_load(), kexec-tools will have a similar change. CC: Eric Biederman <ebiederm@xmission.com> CC: Baoquan He <bhe@redhat.com> CC: kexec@lists.infradead.org Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> --- kernel/kexec_file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index f989f5f1933b..0d5b516b96ee 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -29,6 +29,8 @@ #include <linux/vmalloc.h> #include "kexec_internal.h" +#define PF_DEV (1 << 4) + #ifdef CONFIG_KEXEC_SIG static bool sig_enforce = IS_ENABLED(CONFIG_KEXEC_SIG_FORCE); @@ -1221,6 +1223,12 @@ int crash_exclude_mem_range(struct crash_mem *mem, return 0; } +static bool is_pmem_range(u64 start, u64 size) +{ + return REGION_INTERSECTS == region_intersects(start, size, + IORESOURCE_MEM, IORES_DESC_PERSISTENT_MEMORY); +} + int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map, void **addr, unsigned long *sz) { @@ -1302,6 +1310,8 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map, phdr->p_type = PT_LOAD; phdr->p_flags = PF_R|PF_W|PF_X; + if (is_pmem_range(mstart, mend - mstart)) + phdr->p_flags |= PF_DEV; phdr->p_offset = mstart; phdr->p_paddr = mstart; -- 2.29.2 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Li Zhijian <lizhijian@fujitsu.com> To: kexec@lists.infradead.org, nvdimm@lists.linux.dev Cc: linux-kernel@vger.kernel.org, dan.j.williams@intel.com, bhe@redhat.com, ruansy.fnst@fujitsu.com, y-goto@fujitsu.com, yangx.jy@fujitsu.com, Li Zhijian <lizhijian@fujitsu.com>, Eric Biederman <ebiederm@xmission.com> Subject: [RFC PATCH v3 3/3] kernel/kexec_file: Mark pmem region with new flag PF_DEV Date: Fri, 2 Jun 2023 18:26:52 +0800 [thread overview] Message-ID: <20230602102656.131654-4-lizhijian@fujitsu.com> (raw) In-Reply-To: <20230602102656.131654-1-lizhijian@fujitsu.com> For pmem, metadata is specific to the namespace rather than the entire pmem region. Therefore, ranges that have not yet created a namespace or are unusable due to alignment reasons will not be associated with metadata. When an application attempts to access regions that do not have corresponding metadata, it will encounter an access error. With this flag, the dumping applications are able to know this access error, and then take special actions correspondingly. This is kexec_file_load() specific, for the traditional kexec_load(), kexec-tools will have a similar change. CC: Eric Biederman <ebiederm@xmission.com> CC: Baoquan He <bhe@redhat.com> CC: kexec@lists.infradead.org Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> --- kernel/kexec_file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index f989f5f1933b..0d5b516b96ee 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -29,6 +29,8 @@ #include <linux/vmalloc.h> #include "kexec_internal.h" +#define PF_DEV (1 << 4) + #ifdef CONFIG_KEXEC_SIG static bool sig_enforce = IS_ENABLED(CONFIG_KEXEC_SIG_FORCE); @@ -1221,6 +1223,12 @@ int crash_exclude_mem_range(struct crash_mem *mem, return 0; } +static bool is_pmem_range(u64 start, u64 size) +{ + return REGION_INTERSECTS == region_intersects(start, size, + IORESOURCE_MEM, IORES_DESC_PERSISTENT_MEMORY); +} + int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map, void **addr, unsigned long *sz) { @@ -1302,6 +1310,8 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map, phdr->p_type = PT_LOAD; phdr->p_flags = PF_R|PF_W|PF_X; + if (is_pmem_range(mstart, mend - mstart)) + phdr->p_flags |= PF_DEV; phdr->p_offset = mstart; phdr->p_paddr = mstart; -- 2.29.2
next prev parent reply other threads:[~2023-06-02 10:27 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-02 10:26 [RFC PATCH v3 0/3] pmem memmap dump support Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-02 10:26 ` [RFC PATCH v3 1/3] nvdimm: set force_raw=1 in kdump kernel Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-02 10:26 ` [RFC PATCH v3 2/3] x86/crash: Add pmem region into PT_LOADs of vmcore Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-02 10:26 ` Li Zhijian [this message] 2023-06-02 10:26 ` [RFC PATCH v3 3/3] kernel/kexec_file: Mark pmem region with new flag PF_DEV Li Zhijian 2023-06-02 10:26 ` [RFC PATCH kexec-tools v3 1/1] kexec: Add and mark pmem region into PT_LOADs Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-02 10:26 ` [RFC PATCH makedumpfile v3 1/3] elf_info.c: Introduce is_pmem_pt_load_range Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-02 10:26 ` [RFC PATCH makedumpfile v3 2/3] makedumpfile.c: Exclude all pmem pages Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-02 10:26 ` [RFC PATCH makedumpfile v3 3/3] makedumpfile: get metadata boundaries from pmem's infoblock Li Zhijian 2023-06-02 10:26 ` Li Zhijian 2023-06-04 12:59 ` [RFC PATCH v3 0/3] pmem memmap dump support Baoquan He 2023-06-04 12:59 ` Baoquan He 2023-06-09 1:21 ` Zhijian Li (Fujitsu) 2023-06-09 1:21 ` Zhijian Li (Fujitsu) 2023-06-25 10:27 ` Li, Zhijian 2023-06-25 10:27 ` Li, Zhijian
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=20230602102656.131654-4-lizhijian@fujitsu.com \ --to=lizhijian@fujitsu.com \ --cc=bhe@redhat.com \ --cc=dan.j.williams@intel.com \ --cc=ebiederm@xmission.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=nvdimm@lists.linux.dev \ --cc=ruansy.fnst@fujitsu.com \ --cc=y-goto@fujitsu.com \ --cc=yangx.jy@fujitsu.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: linkBe 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.