在 2019年01月15日 04:49, Dave Anderson 写道:
>
>
> - Original Message -
>> On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
>>> No. It needs *both* the vmlinux file and the vmcore file in order to read
>>> kernel
>>> virtual memory, so just having a kernel virtual address is
On Mon, Jan 14, 2019 at 03:49:14PM -0500, Dave Anderson wrote:
> Yeah, I've been watching the thread, and the document looks fine to me.
> It's just that when I saw the discussion of this one being removed that
> I felt the need to respond... ;-)
Good. :-)
Ok, I've amended the
在 2019年01月14日 17:15, Borislav Petkov 写道:
> On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
>> I noticed that the checkpatch was coded in Perl. But i am not familiar with
>> the Perl program language, that would be beyond my ability to do this, i have
>> to learn the Perl program language
- Original Message -
> On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> > No. It needs *both* the vmlinux file and the vmcore file in order to read
> > kernel
> > virtual memory, so just having a kernel virtual address is insufficient.
> >
> > So it's a chicken-and-egg
On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> No. It needs *both* the vmlinux file and the vmcore file in order to read
> kernel
> virtual memory, so just having a kernel virtual address is insufficient.
>
> So it's a chicken-and-egg situation. This particular --osrelease
- Original Message -
> On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> > That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> > pulls out the OSRELEASE string from it, so that a user can determine what
> > vmlinux file should be used with that
On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> pulls out the OSRELEASE string from it, so that a user can determine what
> vmlinux file should be used with that vmcore for normal crash analysis.
And
- Original Message -
> On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> > There's no reading of the dumpfile's memory involved, and that being the
> > case,
> > the vmlinux file is not utilized. That's the whole point of the crash
> > option, i.e.,
> > taking a vmcore
On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> There's no reading of the dumpfile's memory involved, and that being the case,
> the vmlinux file is not utilized. That's the whole point of the crash
> option, i.e.,
> taking a vmcore file, and trying to determine what kernel
- Original Message -
> On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> > Preferably it would be left as-is. The crash utility has a "crash
> > --osrelease vmcore"
> > option that only looks at the dumpfile header, and just dump the string.
> > With respect
> > to
On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> Preferably it would be left as-is. The crash utility has a "crash
> --osrelease vmcore"
> option that only looks at the dumpfile header, and just dump the string.
> With respect
> to compressed kdumps, crash could alternatively
- Original Message -
> On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> > As for makedumpfile, it will be not impossible to remove the
> > init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> > Because historically OSRELEASE has been a kind of a mandatory
On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> As for makedumpfile, it will be not impossible to remove the
> init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> Because historically OSRELEASE has been a kind of a mandatory entry
> in vmcoreinfo from the beginning
On 1/11/2019 7:33 AM, Borislav Petkov wrote:
> On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
>> +init_uts_ns.name.release
>> +
>> +
>> +The version of the Linux kernel. Used to find the corresponding source
>> +code from which the kernel has been built.
>> +
On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
> I noticed that the checkpatch was coded in Perl. But i am not familiar with
> the Perl program language, that would be beyond my ability to do this, i have
> to learn the Perl program language step by step. :-)
You could give it a try -
On Mon, Jan 14, 2019 at 09:52:14AM +0800, lijiang wrote:
> I would like to remove this variable and post again.
No, you should remove the vmcoreinfo export too:
kernel/crash_core.c:398:VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
after making sure userspace is not using it and *then*
在 2019年01月11日 22:56, Borislav Petkov 写道:
> On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
>> This document lists some variables that export to vmcoreinfo, and briefly
>> describles what these variables indicate. It should be instructive for
>> many people who do not know the
在 2019年01月11日 20:33, Borislav Petkov 写道:
> On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
>> +init_uts_ns.name.release
>> +
>> +
>> +The version of the Linux kernel. Used to find the corresponding source
>> +code from which the kernel has been built.
>> +
>
On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people who do not know the vmcoreinfo.
>
> Suggested-by: Borislav Petkov
>
On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
> +init_uts_ns.name.release
> +
> +
> +The version of the Linux kernel. Used to find the corresponding source
> +code from which the kernel has been built.
> +
...
> +
> +init_uts_ns
> +---
> +
> +This
This document lists some variables that export to vmcoreinfo, and briefly
describles what these variables indicate. It should be instructive for
many people who do not know the vmcoreinfo.
Suggested-by: Borislav Petkov
Signed-off-by: Lianbo Jiang
---
Documentation/kdump/vmcoreinfo.txt | 500
21 matches
Mail list logo
