2019-05-19 13:07:45 +01:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2008-07-25 01:48:30 -07:00
|
|
|
config PROC_FS
|
2011-01-20 14:44:16 -08:00
|
|
|
bool "/proc file system support" if EXPERT
|
2008-07-25 01:48:30 -07:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
This is a virtual file system providing information about the status
|
|
|
|
of the system. "Virtual" means that it doesn't take up any space on
|
|
|
|
your hard disk: the files are created on the fly by the kernel when
|
|
|
|
you try to access them. Also, you cannot read the files with older
|
|
|
|
version of the program less: you need to use more or cat.
|
|
|
|
|
|
|
|
It's totally cool; for example, "cat /proc/interrupts" gives
|
|
|
|
information about what the different IRQs are used for at the moment
|
|
|
|
(there is a small number of Interrupt ReQuest lines in your computer
|
|
|
|
that are used by the attached devices to gain the CPU's attention --
|
|
|
|
often a source of trouble if two devices are mistakenly configured
|
|
|
|
to use the same IRQ). The program procinfo to display some
|
|
|
|
information about your system gathered from the /proc file system.
|
|
|
|
|
|
|
|
Before you can use the /proc file system, it has to be mounted,
|
|
|
|
meaning it has to be given a location in the directory hierarchy.
|
|
|
|
That location should be /proc. A command such as "mount -t proc proc
|
|
|
|
/proc" or the equivalent line in /etc/fstab does the job.
|
|
|
|
|
|
|
|
The /proc file system is explained in the file
|
2020-04-14 18:48:37 +02:00
|
|
|
<file:Documentation/filesystems/proc.rst> and on the proc(5) manpage
|
2008-07-25 01:48:30 -07:00
|
|
|
("man 5 proc").
|
|
|
|
|
|
|
|
This option will enlarge your kernel by about 67 KB. Several
|
|
|
|
programs depend on this, so everyone should say Y here.
|
|
|
|
|
|
|
|
config PROC_KCORE
|
|
|
|
bool "/proc/kcore support" if !ARM
|
|
|
|
depends on PROC_FS && MMU
|
2024-01-24 13:12:42 +08:00
|
|
|
select VMCORE_INFO
|
2013-11-12 15:11:16 -08:00
|
|
|
help
|
|
|
|
Provides a virtual ELF core file of the live kernel. This can
|
|
|
|
be read with gdb and other ELF tools. No modifications can be
|
|
|
|
made using this mechanism.
|
2008-07-25 01:48:30 -07:00
|
|
|
|
|
|
|
config PROC_VMCORE
|
2010-10-26 14:21:21 -07:00
|
|
|
bool "/proc/vmcore support"
|
|
|
|
depends on PROC_FS && CRASH_DUMP
|
2008-07-25 01:48:30 -07:00
|
|
|
default y
|
2019-12-04 16:50:11 -08:00
|
|
|
help
|
|
|
|
Exports the dump image of crashed kernel in ELF format.
|
2008-07-25 01:48:30 -07:00
|
|
|
|
2018-05-02 15:17:17 +05:30
|
|
|
config PROC_VMCORE_DEVICE_DUMP
|
|
|
|
bool "Device Hardware/Firmware Log Collection"
|
|
|
|
depends on PROC_VMCORE
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
After kernel panic, device drivers can collect the device
|
|
|
|
specific snapshot of their hardware or firmware before the
|
|
|
|
underlying devices are initialized in crash recovery kernel.
|
|
|
|
Note that the device driver must be present in the crash
|
|
|
|
recovery kernel's initramfs to collect its underlying device
|
|
|
|
snapshot.
|
|
|
|
|
|
|
|
If you say Y here, the collected device dumps will be added
|
2019-07-16 16:26:39 -07:00
|
|
|
as ELF notes to /proc/vmcore. You can still disable device
|
|
|
|
dump using the kernel command line option 'novmcoredd'.
|
2018-05-02 15:17:17 +05:30
|
|
|
|
fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel
s390 allocates+prepares the elfcore hdr in the dump (2nd) kernel, not in
the crashed kernel.
RAM provided by memory devices such as virtio-mem can only be detected
using the device driver; when vmcore_init() is called, these device
drivers are usually not loaded yet, or the devices did not get probed
yet. Consequently, on s390 these RAM ranges will not be included in
the crash dump, which makes the dump partially corrupt and is
unfortunate.
Instead of deferring the vmcore_init() call, to an (unclear?) later point,
let's reuse the vmcore_cb infrastructure to obtain device RAM ranges as
the device drivers probe the device and get access to this information.
Then, we'll add these ranges to the vmcore, adding more PT_LOAD
entries and updating the offsets+vmcore size.
Use a separate Kconfig option to be set by an architecture to include this
code only if the arch really needs it. Further, we'll make the config
depend on the relevant drivers (i.e., virtio_mem) once they implement
support (next). The alternative of having a PROVIDE_PROC_VMCORE_DEVICE_RAM
config option was dropped for now for simplicity.
The current target use case is s390, which only creates an elf64
elfcore, so focusing on elf64 is sufficient.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20241204125444.1734652-9-david@redhat.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-12-04 13:54:39 +01:00
|
|
|
config NEED_PROC_VMCORE_DEVICE_RAM
|
|
|
|
bool
|
|
|
|
|
|
|
|
config PROC_VMCORE_DEVICE_RAM
|
|
|
|
def_bool y
|
|
|
|
depends on PROC_VMCORE && NEED_PROC_VMCORE_DEVICE_RAM
|
2024-12-04 13:54:42 +01:00
|
|
|
depends on VIRTIO_MEM
|
fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel
s390 allocates+prepares the elfcore hdr in the dump (2nd) kernel, not in
the crashed kernel.
RAM provided by memory devices such as virtio-mem can only be detected
using the device driver; when vmcore_init() is called, these device
drivers are usually not loaded yet, or the devices did not get probed
yet. Consequently, on s390 these RAM ranges will not be included in
the crash dump, which makes the dump partially corrupt and is
unfortunate.
Instead of deferring the vmcore_init() call, to an (unclear?) later point,
let's reuse the vmcore_cb infrastructure to obtain device RAM ranges as
the device drivers probe the device and get access to this information.
Then, we'll add these ranges to the vmcore, adding more PT_LOAD
entries and updating the offsets+vmcore size.
Use a separate Kconfig option to be set by an architecture to include this
code only if the arch really needs it. Further, we'll make the config
depend on the relevant drivers (i.e., virtio_mem) once they implement
support (next). The alternative of having a PROVIDE_PROC_VMCORE_DEVICE_RAM
config option was dropped for now for simplicity.
The current target use case is s390, which only creates an elf64
elfcore, so focusing on elf64 is sufficient.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20241204125444.1734652-9-david@redhat.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-12-04 13:54:39 +01:00
|
|
|
help
|
|
|
|
If the elfcore hdr is allocated and prepared by the dump kernel
|
|
|
|
("2nd kernel") instead of the crashed kernel, RAM provided by memory
|
|
|
|
devices such as virtio-mem will not be included in the dump
|
|
|
|
image, because only the device driver can properly detect them.
|
|
|
|
|
|
|
|
With this config enabled, these RAM ranges will be queried from the
|
|
|
|
device drivers once the device gets probed, so they can be included
|
|
|
|
in the crash dump.
|
|
|
|
|
|
|
|
Relevant architectures should select NEED_PROC_VMCORE_DEVICE_RAM.
|
|
|
|
|
2008-07-25 01:48:30 -07:00
|
|
|
config PROC_SYSCTL
|
2011-01-20 14:44:16 -08:00
|
|
|
bool "Sysctl support (/proc/sys)" if EXPERT
|
2008-07-25 01:48:30 -07:00
|
|
|
depends on PROC_FS
|
|
|
|
select SYSCTL
|
|
|
|
default y
|
2020-06-14 01:50:22 +09:00
|
|
|
help
|
2008-07-25 01:48:30 -07:00
|
|
|
The sysctl interface provides a means of dynamically changing
|
|
|
|
certain kernel parameters and variables on the fly without requiring
|
|
|
|
a recompile of the kernel or reboot of the system. The primary
|
|
|
|
interface is through /proc/sys. If you say Y here a tree of
|
|
|
|
modifiable sysctl entries will be generated beneath the
|
2019-12-04 16:50:11 -08:00
|
|
|
/proc/sys directory. They are explained in the files
|
2019-04-22 16:48:00 -03:00
|
|
|
in <file:Documentation/admin-guide/sysctl/>. Note that enabling this
|
2008-07-25 01:48:30 -07:00
|
|
|
option will enlarge the kernel by at least 8 KB.
|
|
|
|
|
|
|
|
As it is generally a good thing, you should say Y here unless
|
|
|
|
building a kernel for install/rescue disks or your system is very
|
|
|
|
limited in memory.
|
2008-10-03 02:01:51 +04:00
|
|
|
|
|
|
|
config PROC_PAGE_MONITOR
|
|
|
|
default y
|
|
|
|
depends on PROC_FS && MMU
|
2011-01-20 14:44:16 -08:00
|
|
|
bool "Enable /proc page monitoring" if EXPERT
|
2008-10-03 02:01:51 +04:00
|
|
|
help
|
|
|
|
Various /proc files exist to monitor process memory utilization:
|
|
|
|
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
|
|
|
|
/proc/kpagecount, and /proc/kpageflags. Disabling these
|
2019-12-04 16:50:11 -08:00
|
|
|
interfaces will reduce the size of the kernel by approximately 4kb.
|
2015-06-25 15:00:57 -07:00
|
|
|
|
|
|
|
config PROC_CHILDREN
|
|
|
|
bool "Include /proc/<pid>/task/<tid>/children file"
|
2022-09-09 14:25:29 +02:00
|
|
|
depends on PROC_FS
|
2015-06-25 15:00:57 -07:00
|
|
|
default n
|
2015-07-17 16:23:23 -07:00
|
|
|
help
|
|
|
|
Provides a fast way to retrieve first level children pids of a task. See
|
2020-04-14 18:48:37 +02:00
|
|
|
<file:Documentation/filesystems/proc.rst> for more information.
|
2015-07-17 16:23:23 -07:00
|
|
|
|
|
|
|
Say Y if you are running any user-space software which takes benefit from
|
|
|
|
this interface. For example, rkt is such a piece of software.
|
2019-06-06 09:22:34 +08:00
|
|
|
|
|
|
|
config PROC_PID_ARCH_STATUS
|
|
|
|
def_bool n
|
|
|
|
depends on PROC_FS
|
2020-01-15 17:28:51 +08:00
|
|
|
|
|
|
|
config PROC_CPU_RESCTRL
|
|
|
|
def_bool n
|
|
|
|
depends on PROC_FS
|