Hi Xunlei,
On Wednesday 22 March 2017 03:04 PM, Xunlei Pang wrote:
On 03/22/2017 at 12:30 PM, Dave Young wrote:
On 03/21/17 at 10:18pm, Eric W. Biederman wrote:
Dave Young <dyo...@redhat.com> writes:
On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
Xunlei Pang <xlp...@redhat.com> writes:
As Eric said,
"what we need to do is move the variable vmcoreinfo_note out
of the kernel's .bss section. And modify the code to regenerate
and keep this information in something like the control page.
Definitely something like this needs a page all to itself, and ideally
far away from any other kernel data structures. I clearly was not
watching closely the data someone decided to keep this silly thing
in the kernel's .bss section."
This patch allocates extra pages for these vmcoreinfo_XXX variables,
one advantage is that it enhances some safety of vmcoreinfo, because
vmcoreinfo now is kept far away from other kernel data structures.
Can you preceed this patch with a patch that removes CRASHTIME from
vmcoreinfo? If someone actually cares we can add a separate note that holds
a 64bit crashtime in the per cpu notes.
I think makedumpfile is using it, but I also vote to remove the
CRASHTIME. It is better not to do this while crashing and a makedumpfile
userspace patch is needed to drop the use of it.
By moving the CRASHTIME info to the cpu note of crashed cpu may be a good
way. In kdump kernel, notes of vmcore elfhdr will be merged into one big note
section, I don't know how makedumpfile or crash handle the big note section?
If they process the note in some order, breakage will definitely happen...
There is also a fadump may be affected.
Would like to keep a tab of such change as fadump builds cpu notes
differently
and such change may have an impact on it considering it depends on the same
tools - crash, makedumpfile..
Thanks
Hari
