nvdimm,pmem: makedumpfile: __vtop4_x86_64: Can't get a valid pte.

[lizhijian at fujitsu.com]

On 28/11/2022 23:03, Eliot Moss wrote:
> On 11/28/2022 9:46 AM, lizhijian at fujitsu.com wrote:
>>
>>
>> On 28/11/2022 20:53, Eliot Moss wrote:
>>> On 11/28/2022 7:04 AM, lizhijian at fujitsu.com wrote:
>>>> Hi folks,
>>>>
>>>> I'm going to make crash coredump support pmem region. So
>>>> I have modified kexec-tools to add pmem region to PT_LOAD of vmcore.
>>>>
>>>> But it failed at makedumpfile, log are as following:
>>>>
>>>> In my environment, i found the last 512 pages in pmem region will cause the error.
>>>
>>> I wonder if an issue I reported is related: when set up to map
>>> 2Mb (huge) pages, the last 2Mb of a large region got mapped as
>>> 4Kb pages, and then later, half of a large region was treated
>>> that way.
>>>
>> Could you share the url/link ? I'd like to take a look
> 
> It was in a previous email to the nvdimm list.  the title was:
> 
> "Possible PMD (huge pages) bug in fs dax"
> 
> And here is the body.  I just sent directly to the list so there
> is no URL (if I should be engaging in a different way, please let me know):

I found it :) at
https://www.mail-archive.com/nvdimm@lists.linux.dev/msg02743.html


> ================================================================================
> Folks - I posted already on nvdimm, but perhaps the topic did not quite grab
> anyone's attention.  I had had some trouble figuring all the details to get
> dax mapping of files from an xfs file system with underlying Optane DC memory
> going, but now have that working reliably.  But there is an odd behavior:
> 
> When first mapping a file, I request mapping a 32 Gb range, aligned on a 1 Gb
> (and thus clearly on a 2 Mb) boundary.
> 
> For each group of 8 Gb, the first 4095 entries map with a 2 Mb huge (PMD)
> page.  The 4096th one does FALLBACK.  I suspect some problem in
> dax.c:grab_mapping_entry or its callees, but am not personally well enough
> versed in either the dax code or the xarray implementation to dig further.
> 
> 
> If you'd like a second puzzle 😄 ... after completing this mapping, another
> thread accesses the whole range sequentially.  This results in NOPAGE fault
> handling for the first 4095+4095 2M regions that previously resulted in
> NOPAGE -- so far so good.  But it gives FALLBACK for the upper 16 Gb (except
> the two PMD regions it alrady gave FALLBACK for).
> 
> 
> I can provide trace output from a run if you'd like and all the ndctl, gdisk
> -l, fdisk -l, and xfs_info details if you like.
> 
> 
> In my application, it would be nice if dax.c could deliver 1 Gb PUD size
> mappings as well, though it would appear that that would require more surgery
> on dax.c.  It would be somewhat analogous to what's already there, of course,
> but I don't mean to minimize the possible trickiness of it.  I realize I
> should submit that request as a separate thread 😄 which I intend to do
> later.
> ================================================================================
> 
> Regards - Eliot Moss