linux-toradex.git/kernel/crash_core.c, branch v5.12-rc5

kdump: append uts_namespace.name offset to VMCOREINFO

2020-12-16T06:46:18+00:00

The offset of the field 'init_uts_ns.name' has changed since commit
9a56493f6942 ("uts: Use generic ns_common::count").

Make the offset of the field 'uts_namespace.name' available in VMCOREINFO
because tools like 'crash-utility' and 'makedumpfile' must be able to read
it from crash dumps.

Link: https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
Link: https://lkml.kernel.org/r/20200930102328.396488-1-egorenar@linux.ibm.com
Signed-off-by: Alexander Egorenkov 
Acked-by: lijiang 
Acked-by: Baoquan He 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: "Eric W . Biederman" 
Cc: Kirill Tkhai 
Cc: Kees Cook 
Cc: Christian Brauner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

crypto: sha - split sha.h into sha1.h and sha2.h

2020-11-20T03:45:33+00:00

Currently  contains declarations for both SHA-1 and SHA-2,
and  contains declarations for SHA-3.

This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure.  So to the extent
possible, SHA-1 shouldn't be grouped together with any of the other SHA
versions, and usage of it should be phased out.

Therefore, split  into two headers  and
, and make everyone explicitly specify whether they want
the declarations for SHA-1, SHA-2, or both.

This avoids making the SHA-1 declarations visible to files that don't
want anything to do with SHA-1.  It also prepares for potentially moving
sha1.h into a new insecure/ or dangerous/ directory.

Signed-off-by: Eric Biggers 
Acked-by: Ard Biesheuvel 
Acked-by: Jason A. Donenfeld 
Signed-off-by: Herbert Xu

kdump: append kernel build-id string to VMCOREINFO

2020-08-12T17:58:01+00:00

Make kernel GNU build-id available in VMCOREINFO.  Having build-id in
VMCOREINFO facilitates presenting appropriate kernel namelist image with
debug information file to kernel crash dump analysis tools.  Currently
VMCOREINFO lacks uniquely identifiable key for crash analysis automation.

Regarding if this patch is necessary or matching of linux_banner and
OSRELEASE in VMCOREINFO employed by crash(8) meets the need -- IMO,
build-id approach more foolproof, in most instances it is a cryptographic
hash generated using internal code/ELF bits unlike kernel version string
upon which linux_banner is based that is external to the code.  I feel
each is intended for a different purpose.  Also OSRELEASE is not suitable
when two different kernel builds from same version with different features
enabled.

Currently for most linux (and non-linux) systems build-id can be extracted
using standard methods for file types such as user mode crash dumps,
shared libraries, loadable kernel modules etc., This is an exception for
linux kernel dump.  Having build-id in VMCOREINFO brings some uniformity
for automation tools.

Tyler said:

: I think this is a nice improvement over today's linux_banner approach for
: correlating vmlinux to a kernel dump.
:
: The elf notes parsing in this patch lines up with what is described in in
: the "Notes (Nhdr)" section of the elf(5) man page.
:
: BUILD_ID_MAX is sufficient to hold a sha1 build-id, which is the default
: build-id type today in GNU ld(2).  It is also sufficient to hold the
: "fast" build-id, which is the default build-id type today in LLVM lld(2).

Signed-off-by: Vijay Balakrishna 
Signed-off-by: Andrew Morton 
Reviewed-by: Tyler Hicks 
Acked-by: Baoquan He 
Cc: Dave Young 
Cc: Vivek Goyal 
Link: http://lkml.kernel.org/r/1591849672-34104-1-git-send-email-vijayb@linux.microsoft.com
Signed-off-by: Linus Torvalds

crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo

2020-07-02T16:56:11+00:00

Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.

This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the existing
calculation method used in the kernel implementation):

  #define SECTIONS_SHIFT    (MAX_PHYSMEM_BITS - SECTION_SIZE_BITS)

Now, regressions have been reported in user-space utilities
like 'makedumpfile' and 'crash' on arm64, with the recently added
kernel support for 52-bit physical address space, as there is
no clear method of determining this value in user-space
(other than reading kernel CONFIG flags).

As per suggestion from makedumpfile maintainer (Kazu), it makes more
sense to append 'MAX_PHYSMEM_BITS' to vmcoreinfo in the core code itself
rather than in arch-specific code, so that the user-space code for other
archs can also benefit from this addition to the vmcoreinfo and use it
as a standard way of determining 'SECTIONS_SHIFT' value in user-land.

A reference 'makedumpfile' implementation which reads the
'MAX_PHYSMEM_BITS' value from vmcoreinfo in a arch-independent fashion
is available here:

While at it also update vmcoreinfo documentation for 'MAX_PHYSMEM_BITS'
variable being added to vmcoreinfo.

'MAX_PHYSMEM_BITS' defines the maximum supported physical address
space memory.

Signed-off-by: Bhupesh Sharma 
Tested-by: John Donnelly 
Acked-by: Dave Young 
Cc: Boris Petkov 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: James Morse 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Cc: Dave Anderson 
Cc: Kazuhito Hagio 
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org
Link: https://lore.kernel.org/r/1589395957-24628-2-git-send-email-bhsharma@redhat.com
Signed-off-by: Catalin Marinas

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 230

2019-06-19T15:09:06+00:00

Based on 2 normalized pattern(s):

  this source code is licensed under the gnu general public license
  version 2 see the file copying for more details

  this source code is licensed under general public license version 2
  see

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 52 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Allison Randal 
Reviewed-by: Alexios Zavras 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190602204653.449021192@linutronix.de
Signed-off-by: Greg Kroah-Hartman

kexec: export PG_offline to VMCOREINFO

2019-03-06T05:07:14+00:00

Right now, pages inflated as part of a balloon driver will be dumped by
dump tools like makedumpfile.  While XEN is able to check in the crash
kernel whether a certain pfn is actuall backed by memory in the
hypervisor (see xen_oldmem_pfn_is_ram) and optimize this case, dumps of
other balloon inflated memory will essentially result in zero pages
getting allocated by the hypervisor and the dump getting filled with
this data.

The allocation and reading of zero pages can directly be avoided if a
dumping tool could know which pages only contain stale information not
to be dumped.

We now have PG_offline which can be (and already is by virtio-balloon)
used for marking pages as logically offline.  Follow up patches will
make use of this flag also in other balloon implementations.

Let's export PG_offline via PAGE_OFFLINE_MAPCOUNT_VALUE, so makedumpfile
can directly skip pages that are logically offline and the content
therefore stale.

Please note that this is also helpful for a problem we were seeing under
Hyper-V: Dumping logically offline memory (pages kept fake offline while
onlining a section via online_page_callback) would under some condicions
result in a kernel panic when dumping them.

Link: http://lkml.kernel.org/r/20181119101616.8901-4-david@redhat.com
Signed-off-by: David Hildenbrand 
Acked-by: Michael S. Tsirkin 
Acked-by: Dave Young 
Cc: "Kirill A. Shutemov" 
Cc: Baoquan He 
Cc: Omar Sandoval 
Cc: Arnd Bergmann 
Cc: Matthew Wilcox 
Cc: Michal Hocko 
Cc: Lianbo Jiang 
Cc: Borislav Petkov 
Cc: Kazuhito Hagio 
Cc: Alexander Duyck 
Cc: Alexey Dobriyan 
Cc: Boris Ostrovsky 
Cc: Christian Hansen 
Cc: David Rientjes 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jonathan Corbet 
Cc: Juergen Gross 
Cc: Julien Freche 
Cc: Kairui Song 
Cc: Konstantin Khlebnikov 
Cc: "K. Y. Srinivasan" 
Cc: Len Brown 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miles Chen 
Cc: Nadav Amit 
Cc: Naoya Horiguchi 
Cc: Pankaj gupta 
Cc: Pavel Machek 
Cc: Pavel Tatashin 
Cc: Rafael J. Wysocki 
Cc: "Rafael J. Wysocki" 
Cc: Stefano Stabellini 
Cc: Stephen Hemminger 
Cc: Stephen Rothwell 
Cc: Vitaly Kuznetsov 
Cc: Vlastimil Babka 
Cc: Xavier Deguillard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel/crash_core.c: print timestamp using time64_t

2018-08-22T17:52:47+00:00

The get_seconds() call returns a 32-bit timestamp on some architectures,
and will overflow in the future.  The newer ktime_get_real_seconds()
always returns a 64-bit timestamp that does not suffer from this problem.

Link: http://lkml.kernel.org/r/20180618150329.941903-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann 
Reviewed-by: Andrew Morton 
Cc: Dave Young 
Cc: Baoquan He 
Cc: "Kirill A. Shutemov" 
Cc: Petr Tesarik 
Cc: Marc-Andr Lureau 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc/kcore: add vmcoreinfo note to /proc/kcore

2018-08-22T17:52:46+00:00

The vmcoreinfo information is useful for runtime debugging tools, not just
for crash dumps.  A lot of this information can be determined by other
means, but this is much more convenient, and it only adds a page at most
to the file.

Link: http://lkml.kernel.org/r/fddbcd08eed76344863303878b12de1c1e2a04b6.1531953780.git.osandov@fb.com
Signed-off-by: Omar Sandoval 
Cc: Alexey Dobriyan 
Cc: Bhupesh Sharma 
Cc: Eric Biederman 
Cc: James Morse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

crash_core: use VMCOREINFO_SYMBOL_ARRAY() for swapper_pg_dir

2018-08-22T17:52:46+00:00

This is preparation for allowing CRASH_CORE to be enabled for any
architecture.

swapper_pg_dir is always either an array or a macro expanding to NULL.
In the latter case, VMCOREINFO_SYMBOL() won't work, as it tries to take
the address of the given symbol:

	#define VMCOREINFO_SYMBOL(name) \
		vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)

Instead, use VMCOREINFO_SYMBOL_ARRAY(), which uses the value:

	#define VMCOREINFO_SYMBOL_ARRAY(name) \
		vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name)

This is the same thing for the array case but isn't an error for the macro
case.

Link: http://lkml.kernel.org/r/c05f9781ec204f40fc96f95086e7b6de6a3eb2c3.1532563124.git.osandov@fb.com
Signed-off-by: Omar Sandoval 
Cc: Alexey Dobriyan 
Cc: Bhupesh Sharma 
Cc: Eric Biederman 
Cc: James Morse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: split page_type out from _mapcount

2018-06-08T00:34:37+00:00

We're already using a union of many fields here, so stop abusing the
_mapcount and make page_type its own field.  That implies renaming some of
the machinery that creates PageBuddy, PageBalloon and PageKmemcg; bring
back the PG_buddy, PG_balloon and PG_kmemcg names.

As suggested by Kirill, make page_type a bitmask.  Because it starts out
life as -1 (thanks to sharing the storage with _mapcount), setting a page
flag means clearing the appropriate bit.  This gives us space for probably
twenty or so extra bits (depending how paranoid we want to be about
_mapcount underflow).

Link: http://lkml.kernel.org/r/20180518194519.3820-3-willy@infradead.org
Signed-off-by: Matthew Wilcox 
Acked-by: Kirill A. Shutemov 
Acked-by: Vlastimil Babka 
Cc: Christoph Lameter 
Cc: Dave Hansen 
Cc: Jérôme Glisse 
Cc: Lai Jiangshan 
Cc: Martin Schwidefsky 
Cc: Pekka Enberg 
Cc: Randy Dunlap 
Cc: Andrey Ryabinin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds