@@ -25,6 +25,8 @@ do { \
} while(0)
#endif
+#define PF_DEV (1 << 4)
+
/* Prepares the crash memory headers and stores in supplied buffer. */
int FUNC(struct kexec_info *info,
struct crash_elf_info *elf_info,
@@ -199,7 +201,7 @@ int FUNC(struct kexec_info *info,
* A seprate program header for Backup Region*/
for (i = 0; i < ranges; i++, range++) {
unsigned long long mstart, mend;
- if (range->type != RANGE_RAM)
+ if (range->type != RANGE_RAM && range->type != RANGE_PMEM)
continue;
mstart = range->start;
mend = range->end;
@@ -209,6 +211,8 @@ int FUNC(struct kexec_info *info,
bufp += sizeof(PHDR);
phdr->p_type = PT_LOAD;
phdr->p_flags = PF_R|PF_W|PF_X;
+ if (range->type == RANGE_PMEM)
+ phdr->p_flags |= PF_DEV;
phdr->p_offset = mstart;
if (mstart == info->backup_src_start
It does: 1. Add pmem region into PT_LOADs of vmcore so that pmem region is dumpable Only the region described by PT_LOADs of /proc/vmcore are dumpable/readble by dumping applications. Previously, on x86/x86_64 only system ram resources will be injected into PT_LOADs. So in order to make the entire pmem resource is dumpable/readable, we need to add pmem region into the PT_LOADs of /proc/vmcore. 2. Mark pmem region's p_flags as PF_DEV so that we are able to ignore the specific pages 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. CC: Baoquan He <bhe@redhat.com> CC: Vivek Goyal <vgoyal@redhat.com> CC: Dave Young <dyoung@redhat.com> CC: kexec@lists.infradead.org Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> --- kexec/crashdump-elf.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)