Dan, On 29/04/2023 02:59, Dan Williams wrote: > Li Zhijian wrote: >> Hello folks, >> >> About 2 months ago, we posted our first RFC[3] and received your kindly feedback. Thank you :) >> Now, I'm back with the code. >> >> Currently, this RFC has already implemented to supported case D*. And the case A&B is disabled >> deliberately in makedumpfile. It includes changes in 3 source code as below: > > I think the reason this patchkit is difficult to follow is that it > spends a lot of time describing a chosen solution, but not enough time > describing the problem and the tradeoffs. > > For example why is updating /proc/vmcore with pmem metadata the chosen > solution? Why not leave the kernel out of it and have makedumpfile > tooling aware of how to parse persistent memory namespace info-blocks > and retrieve that dump itself? This is what I proposed here: > > http://lore.kernel.org/r/641484f7ef780_a52e2940@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.notmuch Sorry for the late reply. I'm just back from the vacation. And sorry again for missing your previous *important* information in V1. Your proposal also sounds to me with less kernel changes, but more ndctl coupling with makedumpfile tools. In my current understanding, it will includes following source changes. -----------+-------------------------------------------------------------------+ Source | changes | -----------+-------------------------------------------------------------------+ I. | 1. enter force_raw in kdump kernel automatically(avoid metadata being updated again)| kernel | | | 2. mark the whole pmem's PT_LOAD for kexec_file_load(2) syscall | -----------+-------------------------------------------------------------------+ II. kexec- | 1. mark the whole pmem's PT_LOAD for kexe_load(2) syscall | tool | | -----------+-------------------------------------------------------------------+ III. | 1. parse the infoblock and calculate the boundaries of userdata and metadata | makedump- | 2. skip pmem userdata region | file | 3. exclude pmem metadata region if needed | -----------+-------------------------------------------------------------------+ I will try rewrite it with your proposal ASAP Thanks again Thanks Zhijian > > ...but never got an answer, or I missed the answer. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec