Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 14 Jan 2019 14:36:47 -0500 (EST)
From:   Dave Anderson <anderson@redhat.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Kazuhito Hagio <k-hagio@ab.jp.nec.com>,
        Lianbo Jiang <lijiang@redhat.com>,
        linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
        tglx@linutronix.de, mingo@redhat.com, x86@kernel.org,
        akpm@linux-foundation.org, bhe@redhat.com, dyoung@redhat.com,
        linux-doc@vger.kernel.org
Message-ID: <134663991.69764038.1547494607008.JavaMail.zimbra@redhat.com>
In-Reply-To: <20190114192144.GQ2773@zn.tnic>
References: <20190110121944.6050-1-lijiang@redhat.com> <20190110121944.6050-2-lijiang@redhat.com> <20190111123300.GE4729@zn.tnic> <4AE2DC15AC0B8543882A74EA0D43DBEC035661E8@BPXM09GP.gisp.nec.co.jp> <20190114180142.GO2773@zn.tnic> <2126185079.69727846.1547492312033.JavaMail.zimbra@redhat.com> <20190114192144.GQ2773@zn.tnic>
Subject: Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: kdump: add the vmcoreinfo documentation
Thread-Index: br070a/lHN4Qz+xrY/Hw7icxEWLpbQ==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


----- 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 compressed kdumps, crash could alternatively look at the utsname data
> > that is stored
> > in the diskdump_header.utsname field, but with ELF vmcores, there is no
> > such back-up.
> 
> Well, there is:
> 
> 00000000  4f 53 52 45 4c 45 41 53  45 3d 35 2e 30 2e 30 2d |OSRELEASE=5.0.0-|
> 00000010  72 63 32 2b 0a 50 41 47  45 53 49 5a 45 3d 34 30 |rc2+.PAGESIZE=40|
> 00000020  39 36 0a 53 59 4d 42 4f  4c 28 6d 65 6d 5f 73 65 |96.SYMBOL(mem_se|
> 00000030  63 74 69 6f 6e 29 3d 66  66 66 66 66 66 66 66 38 |ction)=ffffffff8|
> 00000040  34 35 31 61 31 61 38 0a  53 59 4d 42 4f 4c 28 69 |451a1a8.SYMBOL(i|
> 00000050  6e 69 74 5f 75 74 73 5f  6e 73 29 3d 66 66 66 66 |nit_uts_ns)=ffff|
>                                                                          ^^^^
> 00000060  66 66 66 66 38 32 30 31  33 35 34 30 0a 53 59 4d  |ffff82013540
>                                                              ^^^^^^^^^^^^
> 
> This address has it.

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 should be used with it:

  $ man crash
  ...
       --osrelease dumpfile
              Display the OSRELEASE vmcoreinfo string from a kdump dumpfile header.
  ...


> 
> > What's the problem with leaving it alone?
> 
> The problem is that I'd like to get all those vmcoreinfo exports under
> control and to not have people frivolously export whatever they feel
> like, for obvious reasons, and to get rid of the duplicate/unused pieces
> being part of vmcoreinfo.

Well, I just don't agree that the OSRELEASE item is "frivolous".  It's been in place,
and depended upon, for many years.

Dave