| =================================== |
| Documentation for /proc/sys/kernel/ |
| =================================== |
| |
| .. See scripts/check-sysctl-docs to keep this up to date |
| |
| |
| Copyright (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> |
| |
| Copyright (c) 2009, Shen Feng<shen@cn.fujitsu.com> |
| |
| For general info and legal blurb, please look in |
| Documentation/admin-guide/sysctl/index.rst. |
| |
| ------------------------------------------------------------------------------ |
| |
| This file contains documentation for the sysctl files in |
| ``/proc/sys/kernel/``. |
| |
| The files in this directory can be used to tune and monitor |
| miscellaneous and general things in the operation of the Linux |
| kernel. Since some of the files *can* be used to screw up your |
| system, it is advisable to read both documentation and source |
| before actually making adjustments. |
| |
| Currently, these files might (depending on your configuration) |
| show up in ``/proc/sys/kernel``: |
| |
| .. contents:: :local: |
| |
| |
| acct |
| ==== |
| |
| :: |
| |
| highwater lowwater frequency |
| |
| If BSD-style process accounting is enabled these values control |
| its behaviour. If free space on filesystem where the log lives |
| goes below ``lowwater``\ % accounting suspends. If free space gets |
| above ``highwater``\ % accounting resumes. ``frequency`` determines |
| how often do we check the amount of free space (value is in |
| seconds). Default: |
| |
| :: |
| |
| 4 2 30 |
| |
| That is, suspend accounting if free space drops below 2%; resume it |
| if it increases to at least 4%; consider information about amount of |
| free space valid for 30 seconds. |
| |
| |
| acpi_video_flags |
| ================ |
| |
| See Documentation/power/video.rst. This allows the video resume mode to be set, |
| in a similar fashion to the ``acpi_sleep`` kernel parameter, by |
| combining the following values: |
| |
| = ======= |
| 1 s3_bios |
| 2 s3_mode |
| 4 s3_beep |
| = ======= |
| |
| arch |
| ==== |
| |
| The machine hardware name, the same output as ``uname -m`` |
| (e.g. ``x86_64`` or ``aarch64``). |
| |
| auto_msgmni |
| =========== |
| |
| This variable has no effect and may be removed in future kernel |
| releases. Reading it always returns 0. |
| Up to Linux 3.17, it enabled/disabled automatic recomputing of |
| `msgmni`_ |
| upon memory add/remove or upon IPC namespace creation/removal. |
| Echoing "1" into this file enabled msgmni automatic recomputing. |
| Echoing "0" turned it off. The default value was 1. |
| |
| |
| bootloader_type (x86 only) |
| ========================== |
| |
| This gives the bootloader type number as indicated by the bootloader, |
| shifted left by 4, and OR'd with the low four bits of the bootloader |
| version. The reason for this encoding is that this used to match the |
| ``type_of_loader`` field in the kernel header; the encoding is kept for |
| backwards compatibility. That is, if the full bootloader type number |
| is 0x15 and the full version number is 0x234, this file will contain |
| the value 340 = 0x154. |
| |
| See the ``type_of_loader`` and ``ext_loader_type`` fields in |
| Documentation/arch/x86/boot.rst for additional information. |
| |
| |
| bootloader_version (x86 only) |
| ============================= |
| |
| The complete bootloader version number. In the example above, this |
| file will contain the value 564 = 0x234. |
| |
| See the ``type_of_loader`` and ``ext_loader_ver`` fields in |
| Documentation/arch/x86/boot.rst for additional information. |
| |
| |
| bpf_stats_enabled |
| ================= |
| |
| Controls whether the kernel should collect statistics on BPF programs |
| (total time spent running, number of times run...). Enabling |
| statistics causes a slight reduction in performance on each program |
| run. The statistics can be seen using ``bpftool``. |
| |
| = =================================== |
| 0 Don't collect statistics (default). |
| 1 Collect statistics. |
| = =================================== |
| |
| |
| cad_pid |
| ======= |
| |
| This is the pid which will be signalled on reboot (notably, by |
| Ctrl-Alt-Delete). Writing a value to this file which doesn't |
| correspond to a running process will result in ``-ESRCH``. |
| |
| See also `ctrl-alt-del`_. |
| |
| |
| cap_last_cap |
| ============ |
| |
| Highest valid capability of the running kernel. Exports |
| ``CAP_LAST_CAP`` from the kernel. |
| |
| |
| .. _core_pattern: |
| |
| core_pattern |
| ============ |
| |
| ``core_pattern`` is used to specify a core dumpfile pattern name. |
| |
| * max length 127 characters; default value is "core" |
| * ``core_pattern`` is used as a pattern template for the output |
| filename; certain string patterns (beginning with '%') are |
| substituted with their actual values. |
| * backward compatibility with ``core_uses_pid``: |
| |
| If ``core_pattern`` does not include "%p" (default does not) |
| and ``core_uses_pid`` is set, then .PID will be appended to |
| the filename. |
| |
| * corename format specifiers |
| |
| ======== ========================================== |
| %<NUL> '%' is dropped |
| %% output one '%' |
| %p pid |
| %P global pid (init PID namespace) |
| %i tid |
| %I global tid (init PID namespace) |
| %u uid (in initial user namespace) |
| %g gid (in initial user namespace) |
| %d dump mode, matches ``PR_SET_DUMPABLE`` and |
| ``/proc/sys/fs/suid_dumpable`` |
| %s signal number |
| %t UNIX time of dump |
| %h hostname |
| %e executable filename (may be shortened, could be changed by prctl etc) |
| %f executable filename |
| %E executable path |
| %c maximum size of core file by resource limit RLIMIT_CORE |
| %C CPU the task ran on |
| %<OTHER> both are dropped |
| ======== ========================================== |
| |
| * If the first character of the pattern is a '|', the kernel will treat |
| the rest of the pattern as a command to run. The core dump will be |
| written to the standard input of that program instead of to a file. |
| |
| |
| core_pipe_limit |
| =============== |
| |
| This sysctl is only applicable when `core_pattern`_ is configured to |
| pipe core files to a user space helper (when the first character of |
| ``core_pattern`` is a '|', see above). |
| When collecting cores via a pipe to an application, it is occasionally |
| useful for the collecting application to gather data about the |
| crashing process from its ``/proc/pid`` directory. |
| In order to do this safely, the kernel must wait for the collecting |
| process to exit, so as not to remove the crashing processes proc files |
| prematurely. |
| This in turn creates the possibility that a misbehaving userspace |
| collecting process can block the reaping of a crashed process simply |
| by never exiting. |
| This sysctl defends against that. |
| It defines how many concurrent crashing processes may be piped to user |
| space applications in parallel. |
| If this value is exceeded, then those crashing processes above that |
| value are noted via the kernel log and their cores are skipped. |
| 0 is a special value, indicating that unlimited processes may be |
| captured in parallel, but that no waiting will take place (i.e. the |
| collecting process is not guaranteed access to ``/proc/<crashing |
| pid>/``). |
| This value defaults to 0. |
| |
| |
| core_uses_pid |
| ============= |
| |
| The default coredump filename is "core". By setting |
| ``core_uses_pid`` to 1, the coredump filename becomes core.PID. |
| If `core_pattern`_ does not include "%p" (default does not) |
| and ``core_uses_pid`` is set, then .PID will be appended to |
| the filename. |
| |
| |
| ctrl-alt-del |
| ============ |
| |
| When the value in this file is 0, ctrl-alt-del is trapped and |
| sent to the ``init(1)`` program to handle a graceful restart. |
| When, however, the value is > 0, Linux's reaction to a Vulcan |
| Nerve Pinch (tm) will be an immediate reboot, without even |
| syncing its dirty buffers. |
| |
| Note: |
| when a program (like dosemu) has the keyboard in 'raw' |
| mode, the ctrl-alt-del is intercepted by the program before it |
| ever reaches the kernel tty layer, and it's up to the program |
| to decide what to do with it. |
| |
| |
| dmesg_restrict |
| ============== |
| |
| This toggle indicates whether unprivileged users are prevented |
| from using ``dmesg(8)`` to view messages from the kernel's log |
| buffer. |
| When ``dmesg_restrict`` is set to 0 there are no restrictions. |
| When ``dmesg_restrict`` is set to 1, users must have |
| ``CAP_SYSLOG`` to use ``dmesg(8)``. |
| |
| The kernel config option ``CONFIG_SECURITY_DMESG_RESTRICT`` sets the |
| default value of ``dmesg_restrict``. |
| |
| |
| domainname & hostname |
| ===================== |
| |
| These files can be used to set the NIS/YP domainname and the |
| hostname of your box in exactly the same way as the commands |
| domainname and hostname, i.e.:: |
| |
| # echo "darkstar" > /proc/sys/kernel/hostname |
| # echo "mydomain" > /proc/sys/kernel/domainname |
| |
| has the same effect as:: |
| |
| # hostname "darkstar" |
| # domainname "mydomain" |
| |
| Note, however, that the classic darkstar.frop.org has the |
| hostname "darkstar" and DNS (Internet Domain Name Server) |
| domainname "frop.org", not to be confused with the NIS (Network |
| Information Service) or YP (Yellow Pages) domainname. These two |
| domain names are in general different. For a detailed discussion |
| see the ``hostname(1)`` man page. |
| |
| |
| firmware_config |
| =============== |
| |
| See Documentation/driver-api/firmware/fallback-mechanisms.rst. |
| |
| The entries in this directory allow the firmware loader helper |
| fallback to be controlled: |
| |
| * ``force_sysfs_fallback``, when set to 1, forces the use of the |
| fallback; |
| * ``ignore_sysfs_fallback``, when set to 1, ignores any fallback. |
| |
| |
| ftrace_dump_on_oops |
| =================== |
| |
| Determines whether ``ftrace_dump()`` should be called on an oops (or |
| kernel panic). This will output the contents of the ftrace buffers to |
| the console. This is very useful for capturing traces that lead to |
| crashes and outputting them to a serial console. |
| |
| = =================================================== |
| 0 Disabled (default). |
| 1 Dump buffers of all CPUs. |
| 2 Dump the buffer of the CPU that triggered the oops. |
| = =================================================== |
| |
| |
| ftrace_enabled, stack_tracer_enabled |
| ==================================== |
| |
| See Documentation/trace/ftrace.rst. |
| |
| |
| hardlockup_all_cpu_backtrace |
| ============================ |
| |
| This value controls the hard lockup detector behavior when a hard |
| lockup condition is detected as to whether or not to gather further |
| debug information. If enabled, arch-specific all-CPU stack dumping |
| will be initiated. |
| |
| = ============================================ |
| 0 Do nothing. This is the default behavior. |
| 1 On detection capture more debug information. |
| = ============================================ |
| |
| |
| hardlockup_panic |
| ================ |
| |
| This parameter can be used to control whether the kernel panics |
| when a hard lockup is detected. |
| |
| = =========================== |
| 0 Don't panic on hard lockup. |
| 1 Panic on hard lockup. |
| = =========================== |
| |
| See Documentation/admin-guide/lockup-watchdogs.rst for more information. |
| This can also be set using the nmi_watchdog kernel parameter. |
| |
| |
| hotplug |
| ======= |
| |
| Path for the hotplug policy agent. |
| Default value is ``CONFIG_UEVENT_HELPER_PATH``, which in turn defaults |
| to the empty string. |
| |
| This file only exists when ``CONFIG_UEVENT_HELPER`` is enabled. Most |
| modern systems rely exclusively on the netlink-based uevent source and |
| don't need this. |
| |
| |
| hung_task_all_cpu_backtrace |
| =========================== |
| |
| If this option is set, the kernel will send an NMI to all CPUs to dump |
| their backtraces when a hung task is detected. This file shows up if |
| CONFIG_DETECT_HUNG_TASK and CONFIG_SMP are enabled. |
| |
| 0: Won't show all CPUs backtraces when a hung task is detected. |
| This is the default behavior. |
| |
| 1: Will non-maskably interrupt all CPUs and dump their backtraces when |
| a hung task is detected. |
| |
| |
| hung_task_panic |
| =============== |
| |
| Controls the kernel's behavior when a hung task is detected. |
| This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. |
| |
| = ================================================= |
| 0 Continue operation. This is the default behavior. |
| 1 Panic immediately. |
| = ================================================= |
| |
| |
| hung_task_check_count |
| ===================== |
| |
| The upper bound on the number of tasks that are checked. |
| This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. |
| |
| |
| hung_task_timeout_secs |
| ====================== |
| |
| When a task in D state did not get scheduled |
| for more than this value report a warning. |
| This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. |
| |
| 0 means infinite timeout, no checking is done. |
| |
| Possible values to set are in range {0:``LONG_MAX``/``HZ``}. |
| |
| |
| hung_task_check_interval_secs |
| ============================= |
| |
| Hung task check interval. If hung task checking is enabled |
| (see `hung_task_timeout_secs`_), the check is done every |
| ``hung_task_check_interval_secs`` seconds. |
| This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. |
| |
| 0 (default) means use ``hung_task_timeout_secs`` as checking |
| interval. |
| |
| Possible values to set are in range {0:``LONG_MAX``/``HZ``}. |
| |
| |
| hung_task_warnings |
| ================== |
| |
| The maximum number of warnings to report. During a check interval |
| if a hung task is detected, this value is decreased by 1. |
| When this value reaches 0, no more warnings will be reported. |
| This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. |
| |
| -1: report an infinite number of warnings. |
| |
| |
| hyperv_record_panic_msg |
| ======================= |
| |
| Controls whether the panic kmsg data should be reported to Hyper-V. |
| |
| = ========================================================= |
| 0 Do not report panic kmsg data. |
| 1 Report the panic kmsg data. This is the default behavior. |
| = ========================================================= |
| |
| |
| ignore-unaligned-usertrap |
| ========================= |
| |
| On architectures where unaligned accesses cause traps, and where this |
| feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN``; |
| currently, ``arc``, ``ia64`` and ``loongarch``), controls whether all |
| unaligned traps are logged. |
| |
| = ============================================================= |
| 0 Log all unaligned accesses. |
| 1 Only warn the first time a process traps. This is the default |
| setting. |
| = ============================================================= |
| |
| See also `unaligned-trap`_ and `unaligned-dump-stack`_. On ``ia64``, |
| this allows system administrators to override the |
| ``IA64_THREAD_UAC_NOPRINT`` ``prctl`` and avoid logs being flooded. |
| |
| |
| io_uring_disabled |
| ================= |
| |
| Prevents all processes from creating new io_uring instances. Enabling this |
| shrinks the kernel's attack surface. |
| |
| = ====================================================================== |
| 0 All processes can create io_uring instances as normal. This is the |
| default setting. |
| 1 io_uring creation is disabled (io_uring_setup() will fail with |
| -EPERM) for unprivileged processes not in the io_uring_group group. |
| Existing io_uring instances can still be used. See the |
| documentation for io_uring_group for more information. |
| 2 io_uring creation is disabled for all processes. io_uring_setup() |
| always fails with -EPERM. Existing io_uring instances can still be |
| used. |
| = ====================================================================== |
| |
| |
| io_uring_group |
| ============== |
| |
| When io_uring_disabled is set to 1, a process must either be |
| privileged (CAP_SYS_ADMIN) or be in the io_uring_group group in order |
| to create an io_uring instance. If io_uring_group is set to -1 (the |
| default), only processes with the CAP_SYS_ADMIN capability may create |
| io_uring instances. |
| |
| |
| kexec_load_disabled |
| =================== |
| |
| A toggle indicating if the syscalls ``kexec_load`` and |
| ``kexec_file_load`` have been disabled. |
| This value defaults to 0 (false: ``kexec_*load`` enabled), but can be |
| set to 1 (true: ``kexec_*load`` disabled). |
| Once true, kexec can no longer be used, and the toggle cannot be set |
| back to false. |
| This allows a kexec image to be loaded before disabling the syscall, |
| allowing a system to set up (and later use) an image without it being |
| altered. |
| Generally used together with the `modules_disabled`_ sysctl. |
| |
| kexec_load_limit_panic |
| ====================== |
| |
| This parameter specifies a limit to the number of times the syscalls |
| ``kexec_load`` and ``kexec_file_load`` can be called with a crash |
| image. It can only be set with a more restrictive value than the |
| current one. |
| |
| == ====================================================== |
| -1 Unlimited calls to kexec. This is the default setting. |
| N Number of calls left. |
| == ====================================================== |
| |
| kexec_load_limit_reboot |
| ======================= |
| |
| Similar functionality as ``kexec_load_limit_panic``, but for a normal |
| image. |
| |
| kptr_restrict |
| ============= |
| |
| This toggle indicates whether restrictions are placed on |
| exposing kernel addresses via ``/proc`` and other interfaces. |
| |
| When ``kptr_restrict`` is set to 0 (the default) the address is hashed |
| before printing. |
| (This is the equivalent to %p.) |
| |
| When ``kptr_restrict`` is set to 1, kernel pointers printed using the |
| %pK format specifier will be replaced with 0s unless the user has |
| ``CAP_SYSLOG`` and effective user and group ids are equal to the real |
| ids. |
| This is because %pK checks are done at read() time rather than open() |
| time, so if permissions are elevated between the open() and the read() |
| (e.g via a setuid binary) then %pK will not leak kernel pointers to |
| unprivileged users. |
| Note, this is a temporary solution only. |
| The correct long-term solution is to do the permission checks at |
| open() time. |
| Consider removing world read permissions from files that use %pK, and |
| using `dmesg_restrict`_ to protect against uses of %pK in ``dmesg(8)`` |
| if leaking kernel pointer values to unprivileged users is a concern. |
| |
| When ``kptr_restrict`` is set to 2, kernel pointers printed using |
| %pK will be replaced with 0s regardless of privileges. |
| |
| |
| modprobe |
| ======== |
| |
| The full path to the usermode helper for autoloading kernel modules, |
| by default ``CONFIG_MODPROBE_PATH``, which in turn defaults to |
| "/sbin/modprobe". This binary is executed when the kernel requests a |
| module. For example, if userspace passes an unknown filesystem type |
| to mount(), then the kernel will automatically request the |
| corresponding filesystem module by executing this usermode helper. |
| This usermode helper should insert the needed module into the kernel. |
| |
| This sysctl only affects module autoloading. It has no effect on the |
| ability to explicitly insert modules. |
| |
| This sysctl can be used to debug module loading requests:: |
| |
| echo '#! /bin/sh' > /tmp/modprobe |
| echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe |
| echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe |
| chmod a+x /tmp/modprobe |
| echo /tmp/modprobe > /proc/sys/kernel/modprobe |
| |
| Alternatively, if this sysctl is set to the empty string, then module |
| autoloading is completely disabled. The kernel will not try to |
| execute a usermode helper at all, nor will it call the |
| kernel_module_request LSM hook. |
| |
| If CONFIG_STATIC_USERMODEHELPER=y is set in the kernel configuration, |
| then the configured static usermode helper overrides this sysctl, |
| except that the empty string is still accepted to completely disable |
| module autoloading as described above. |
| |
| modules_disabled |
| ================ |
| |
| A toggle value indicating if modules are allowed to be loaded |
| in an otherwise modular kernel. This toggle defaults to off |
| (0), but can be set true (1). Once true, modules can be |
| neither loaded nor unloaded, and the toggle cannot be set back |
| to false. Generally used with the `kexec_load_disabled`_ toggle. |
| |
| |
| .. _msgmni: |
| |
| msgmax, msgmnb, and msgmni |
| ========================== |
| |
| ``msgmax`` is the maximum size of an IPC message, in bytes. 8192 by |
| default (``MSGMAX``). |
| |
| ``msgmnb`` is the maximum size of an IPC queue, in bytes. 16384 by |
| default (``MSGMNB``). |
| |
| ``msgmni`` is the maximum number of IPC queues. 32000 by default |
| (``MSGMNI``). |
| |
| |
| msg_next_id, sem_next_id, and shm_next_id (System V IPC) |
| ======================================================== |
| |
| These three toggles allows to specify desired id for next allocated IPC |
| object: message, semaphore or shared memory respectively. |
| |
| By default they are equal to -1, which means generic allocation logic. |
| Possible values to set are in range {0:``INT_MAX``}. |
| |
| Notes: |
| 1) kernel doesn't guarantee, that new object will have desired id. So, |
| it's up to userspace, how to handle an object with "wrong" id. |
| 2) Toggle with non-default value will be set back to -1 by kernel after |
| successful IPC object allocation. If an IPC object allocation syscall |
| fails, it is undefined if the value remains unmodified or is reset to -1. |
| |
| |
| ngroups_max |
| =========== |
| |
| Maximum number of supplementary groups, _i.e._ the maximum size which |
| ``setgroups`` will accept. Exports ``NGROUPS_MAX`` from the kernel. |
| |
| |
| |
| nmi_watchdog |
| ============ |
| |
| This parameter can be used to control the NMI watchdog |
| (i.e. the hard lockup detector) on x86 systems. |
| |
| = ================================= |
| 0 Disable the hard lockup detector. |
| 1 Enable the hard lockup detector. |
| = ================================= |
| |
| The hard lockup detector monitors each CPU for its ability to respond to |
| timer interrupts. The mechanism utilizes CPU performance counter registers |
| that are programmed to generate Non-Maskable Interrupts (NMIs) periodically |
| while a CPU is busy. Hence, the alternative name 'NMI watchdog'. |
| |
| The NMI watchdog is disabled by default if the kernel is running as a guest |
| in a KVM virtual machine. This default can be overridden by adding:: |
| |
| nmi_watchdog=1 |
| |
| to the guest kernel command line (see |
| Documentation/admin-guide/kernel-parameters.rst). |
| |
| |
| nmi_wd_lpm_factor (PPC only) |
| ============================ |
| |
| Factor to apply to the NMI watchdog timeout (only when ``nmi_watchdog`` is |
| set to 1). This factor represents the percentage added to |
| ``watchdog_thresh`` when calculating the NMI watchdog timeout during an |
| LPM. The soft lockup timeout is not impacted. |
| |
| A value of 0 means no change. The default value is 200 meaning the NMI |
| watchdog is set to 30s (based on ``watchdog_thresh`` equal to 10). |
| |
| |
| numa_balancing |
| ============== |
| |
| Enables/disables and configures automatic page fault based NUMA memory |
| balancing. Memory is moved automatically to nodes that access it often. |
| The value to set can be the result of ORing the following: |
| |
| = ================================= |
| 0 NUMA_BALANCING_DISABLED |
| 1 NUMA_BALANCING_NORMAL |
| 2 NUMA_BALANCING_MEMORY_TIERING |
| = ================================= |
| |
| Or NUMA_BALANCING_NORMAL to optimize page placement among different |
| NUMA nodes to reduce remote accessing. On NUMA machines, there is a |
| performance penalty if remote memory is accessed by a CPU. When this |
| feature is enabled the kernel samples what task thread is accessing |
| memory by periodically unmapping pages and later trapping a page |
| fault. At the time of the page fault, it is determined if the data |
| being accessed should be migrated to a local memory node. |
| |
| The unmapping of pages and trapping faults incur additional overhead that |
| ideally is offset by improved memory locality but there is no universal |
| guarantee. If the target workload is already bound to NUMA nodes then this |
| feature should be disabled. |
| |
| Or NUMA_BALANCING_MEMORY_TIERING to optimize page placement among |
| different types of memory (represented as different NUMA nodes) to |
| place the hot pages in the fast memory. This is implemented based on |
| unmapping and page fault too. |
| |
| numa_balancing_promote_rate_limit_MBps |
| ====================================== |
| |
| Too high promotion/demotion throughput between different memory types |
| may hurt application latency. This can be used to rate limit the |
| promotion throughput. The per-node max promotion throughput in MB/s |
| will be limited to be no more than the set value. |
| |
| A rule of thumb is to set this to less than 1/10 of the PMEM node |
| write bandwidth. |
| |
| oops_all_cpu_backtrace |
| ====================== |
| |
| If this option is set, the kernel will send an NMI to all CPUs to dump |
| their backtraces when an oops event occurs. It should be used as a last |
| resort in case a panic cannot be triggered (to protect VMs running, for |
| example) or kdump can't be collected. This file shows up if CONFIG_SMP |
| is enabled. |
| |
| 0: Won't show all CPUs backtraces when an oops is detected. |
| This is the default behavior. |
| |
| 1: Will non-maskably interrupt all CPUs and dump their backtraces when |
| an oops event is detected. |
| |
| |
| oops_limit |
| ========== |
| |
| Number of kernel oopses after which the kernel should panic when |
| ``panic_on_oops`` is not set. Setting this to 0 disables checking |
| the count. Setting this to 1 has the same effect as setting |
| ``panic_on_oops=1``. The default value is 10000. |
| |
| |
| osrelease, ostype & version |
| =========================== |
| |
| :: |
| |
| # cat osrelease |
| 2.1.88 |
| # cat ostype |
| Linux |
| # cat version |
| #5 Wed Feb 25 21:49:24 MET 1998 |
| |
| The files ``osrelease`` and ``ostype`` should be clear enough. |
| ``version`` |
| needs a little more clarification however. The '#5' means that |
| this is the fifth kernel built from this source base and the |
| date behind it indicates the time the kernel was built. |
| The only way to tune these values is to rebuild the kernel :-) |
| |
| |
| overflowgid & overflowuid |
| ========================= |
| |
| if your architecture did not always support 32-bit UIDs (i.e. arm, |
| i386, m68k, sh, and sparc32), a fixed UID and GID will be returned to |
| applications that use the old 16-bit UID/GID system calls, if the |
| actual UID or GID would exceed 65535. |
| |
| These sysctls allow you to change the value of the fixed UID and GID. |
| The default is 65534. |
| |
| |
| panic |
| ===== |
| |
| The value in this file determines the behaviour of the kernel on a |
| panic: |
| |
| * if zero, the kernel will loop forever; |
| * if negative, the kernel will reboot immediately; |
| * if positive, the kernel will reboot after the corresponding number |
| of seconds. |
| |
| When you use the software watchdog, the recommended setting is 60. |
| |
| |
| panic_on_io_nmi |
| =============== |
| |
| Controls the kernel's behavior when a CPU receives an NMI caused by |
| an IO error. |
| |
| = ================================================================== |
| 0 Try to continue operation (default). |
| 1 Panic immediately. The IO error triggered an NMI. This indicates a |
| serious system condition which could result in IO data corruption. |
| Rather than continuing, panicking might be a better choice. Some |
| servers issue this sort of NMI when the dump button is pushed, |
| and you can use this option to take a crash dump. |
| = ================================================================== |
| |
| |
| panic_on_oops |
| ============= |
| |
| Controls the kernel's behaviour when an oops or BUG is encountered. |
| |
| = =================================================================== |
| 0 Try to continue operation. |
| 1 Panic immediately. If the `panic` sysctl is also non-zero then the |
| machine will be rebooted. |
| = =================================================================== |
| |
| |
| panic_on_stackoverflow |
| ====================== |
| |
| Controls the kernel's behavior when detecting the overflows of |
| kernel, IRQ and exception stacks except a user stack. |
| This file shows up if ``CONFIG_DEBUG_STACKOVERFLOW`` is enabled. |
| |
| = ========================== |
| 0 Try to continue operation. |
| 1 Panic immediately. |
| = ========================== |
| |
| |
| panic_on_unrecovered_nmi |
| ======================== |
| |
| The default Linux behaviour on an NMI of either memory or unknown is |
| to continue operation. For many environments such as scientific |
| computing it is preferable that the box is taken out and the error |
| dealt with than an uncorrected parity/ECC error get propagated. |
| |
| A small number of systems do generate NMIs for bizarre random reasons |
| such as power management so the default is off. That sysctl works like |
| the existing panic controls already in that directory. |
| |
| |
| panic_on_warn |
| ============= |
| |
| Calls panic() in the WARN() path when set to 1. This is useful to avoid |
| a kernel rebuild when attempting to kdump at the location of a WARN(). |
| |
| = ================================================ |
| 0 Only WARN(), default behaviour. |
| 1 Call panic() after printing out WARN() location. |
| = ================================================ |
| |
| |
| panic_print |
| =========== |
| |
| Bitmask for printing system info when panic happens. User can chose |
| combination of the following bits: |
| |
| ===== ============================================ |
| bit 0 print all tasks info |
| bit 1 print system memory info |
| bit 2 print timer info |
| bit 3 print locks info if ``CONFIG_LOCKDEP`` is on |
| bit 4 print ftrace buffer |
| bit 5 print all printk messages in buffer |
| bit 6 print all CPUs backtrace (if available in the arch) |
| ===== ============================================ |
| |
| So for example to print tasks and memory info on panic, user can:: |
| |
| echo 3 > /proc/sys/kernel/panic_print |
| |
| |
| panic_on_rcu_stall |
| ================== |
| |
| When set to 1, calls panic() after RCU stall detection messages. This |
| is useful to define the root cause of RCU stalls using a vmcore. |
| |
| = ============================================================ |
| 0 Do not panic() when RCU stall takes place, default behavior. |
| 1 panic() after printing RCU stall messages. |
| = ============================================================ |
| |
| max_rcu_stall_to_panic |
| ====================== |
| |
| When ``panic_on_rcu_stall`` is set to 1, this value determines the |
| number of times that RCU can stall before panic() is called. |
| |
| When ``panic_on_rcu_stall`` is set to 0, this value is has no effect. |
| |
| perf_cpu_time_max_percent |
| ========================= |
| |
| Hints to the kernel how much CPU time it should be allowed to |
| use to handle perf sampling events. If the perf subsystem |
| is informed that its samples are exceeding this limit, it |
| will drop its sampling frequency to attempt to reduce its CPU |
| usage. |
| |
| Some perf sampling happens in NMIs. If these samples |
| unexpectedly take too long to execute, the NMIs can become |
| stacked up next to each other so much that nothing else is |
| allowed to execute. |
| |
| ===== ======================================================== |
| 0 Disable the mechanism. Do not monitor or correct perf's |
| sampling rate no matter how CPU time it takes. |
| |
| 1-100 Attempt to throttle perf's sample rate to this |
| percentage of CPU. Note: the kernel calculates an |
| "expected" length of each sample event. 100 here means |
| 100% of that expected length. Even if this is set to |
| 100, you may still see sample throttling if this |
| length is exceeded. Set to 0 if you truly do not care |
| how much CPU is consumed. |
| ===== ======================================================== |
| |
| |
| perf_event_paranoid |
| =================== |
| |
| Controls use of the performance events system by unprivileged |
| users (without CAP_PERFMON). The default value is 2. |
| |
| For backward compatibility reasons access to system performance |
| monitoring and observability remains open for CAP_SYS_ADMIN |
| privileged processes but CAP_SYS_ADMIN usage for secure system |
| performance monitoring and observability operations is discouraged |
| with respect to CAP_PERFMON use cases. |
| |
| === ================================================================== |
| -1 Allow use of (almost) all events by all users. |
| |
| Ignore mlock limit after perf_event_mlock_kb without |
| ``CAP_IPC_LOCK``. |
| |
| >=0 Disallow ftrace function tracepoint by users without |
| ``CAP_PERFMON``. |
| |
| Disallow raw tracepoint access by users without ``CAP_PERFMON``. |
| |
| >=1 Disallow CPU event access by users without ``CAP_PERFMON``. |
| |
| >=2 Disallow kernel profiling by users without ``CAP_PERFMON``. |
| === ================================================================== |
| |
| |
| perf_event_max_stack |
| ==================== |
| |
| Controls maximum number of stack frames to copy for (``attr.sample_type & |
| PERF_SAMPLE_CALLCHAIN``) configured events, for instance, when using |
| '``perf record -g``' or '``perf trace --call-graph fp``'. |
| |
| This can only be done when no events are in use that have callchains |
| enabled, otherwise writing to this file will return ``-EBUSY``. |
| |
| The default value is 127. |
| |
| |
| perf_event_mlock_kb |
| =================== |
| |
| Control size of per-cpu ring buffer not counted against mlock limit. |
| |
| The default value is 512 + 1 page |
| |
| |
| perf_event_max_contexts_per_stack |
| ================================= |
| |
| Controls maximum number of stack frame context entries for |
| (``attr.sample_type & PERF_SAMPLE_CALLCHAIN``) configured events, for |
| instance, when using '``perf record -g``' or '``perf trace --call-graph fp``'. |
| |
| This can only be done when no events are in use that have callchains |
| enabled, otherwise writing to this file will return ``-EBUSY``. |
| |
| The default value is 8. |
| |
| |
| perf_user_access (arm64 and riscv only) |
| ======================================= |
| |
| Controls user space access for reading perf event counters. |
| |
| arm64 |
| ===== |
| |
| The default value is 0 (access disabled). |
| |
| When set to 1, user space can read performance monitor counter registers |
| directly. |
| |
| See Documentation/arch/arm64/perf.rst for more information. |
| |
| riscv |
| ===== |
| |
| When set to 0, user space access is disabled. |
| |
| The default value is 1, user space can read performance monitor counter |
| registers through perf, any direct access without perf intervention will trigger |
| an illegal instruction. |
| |
| When set to 2, which enables legacy mode (user space has direct access to cycle |
| and insret CSRs only). Note that this legacy value is deprecated and will be |
| removed once all user space applications are fixed. |
| |
| Note that the time CSR is always directly accessible to all modes. |
| |
| pid_max |
| ======= |
| |
| PID allocation wrap value. When the kernel's next PID value |
| reaches this value, it wraps back to a minimum PID value. |
| PIDs of value ``pid_max`` or larger are not allocated. |
| |
| |
| ns_last_pid |
| =========== |
| |
| The last pid allocated in the current (the one task using this sysctl |
| lives in) pid namespace. When selecting a pid for a next task on fork |
| kernel tries to allocate a number starting from this one. |
| |
| |
| powersave-nap (PPC only) |
| ======================== |
| |
| If set, Linux-PPC will use the 'nap' mode of powersaving, |
| otherwise the 'doze' mode will be used. |
| |
| |
| ============================================================== |
| |
| printk |
| ====== |
| |
| The four values in printk denote: ``console_loglevel``, |
| ``default_message_loglevel``, ``minimum_console_loglevel`` and |
| ``default_console_loglevel`` respectively. |
| |
| These values influence printk() behavior when printing or |
| logging error messages. See '``man 2 syslog``' for more info on |
| the different loglevels. |
| |
| ======================== ===================================== |
| console_loglevel messages with a higher priority than |
| this will be printed to the console |
| default_message_loglevel messages without an explicit priority |
| will be printed with this priority |
| minimum_console_loglevel minimum (highest) value to which |
| console_loglevel can be set |
| default_console_loglevel default value for console_loglevel |
| ======================== ===================================== |
| |
| |
| printk_delay |
| ============ |
| |
| Delay each printk message in ``printk_delay`` milliseconds |
| |
| Value from 0 - 10000 is allowed. |
| |
| |
| printk_ratelimit |
| ================ |
| |
| Some warning messages are rate limited. ``printk_ratelimit`` specifies |
| the minimum length of time between these messages (in seconds). |
| The default value is 5 seconds. |
| |
| A value of 0 will disable rate limiting. |
| |
| |
| printk_ratelimit_burst |
| ====================== |
| |
| While long term we enforce one message per `printk_ratelimit`_ |
| seconds, we do allow a burst of messages to pass through. |
| ``printk_ratelimit_burst`` specifies the number of messages we can |
| send before ratelimiting kicks in. |
| |
| The default value is 10 messages. |
| |
| |
| printk_devkmsg |
| ============== |
| |
| Control the logging to ``/dev/kmsg`` from userspace: |
| |
| ========= ============================================= |
| ratelimit default, ratelimited |
| on unlimited logging to /dev/kmsg from userspace |
| off logging to /dev/kmsg disabled |
| ========= ============================================= |
| |
| The kernel command line parameter ``printk.devkmsg=`` overrides this and is |
| a one-time setting until next reboot: once set, it cannot be changed by |
| this sysctl interface anymore. |
| |
| ============================================================== |
| |
| |
| pty |
| === |
| |
| See Documentation/filesystems/devpts.rst. |
| |
| |
| random |
| ====== |
| |
| This is a directory, with the following entries: |
| |
| * ``boot_id``: a UUID generated the first time this is retrieved, and |
| unvarying after that; |
| |
| * ``uuid``: a UUID generated every time this is retrieved (this can |
| thus be used to generate UUIDs at will); |
| |
| * ``entropy_avail``: the pool's entropy count, in bits; |
| |
| * ``poolsize``: the entropy pool size, in bits; |
| |
| * ``urandom_min_reseed_secs``: obsolete (used to determine the minimum |
| number of seconds between urandom pool reseeding). This file is |
| writable for compatibility purposes, but writing to it has no effect |
| on any RNG behavior; |
| |
| * ``write_wakeup_threshold``: when the entropy count drops below this |
| (as a number of bits), processes waiting to write to ``/dev/random`` |
| are woken up. This file is writable for compatibility purposes, but |
| writing to it has no effect on any RNG behavior. |
| |
| |
| randomize_va_space |
| ================== |
| |
| This option can be used to select the type of process address |
| space randomization that is used in the system, for architectures |
| that support this feature. |
| |
| == =========================================================================== |
| 0 Turn the process address space randomization off. This is the |
| default for architectures that do not support this feature anyways, |
| and kernels that are booted with the "norandmaps" parameter. |
| |
| 1 Make the addresses of mmap base, stack and VDSO page randomized. |
| This, among other things, implies that shared libraries will be |
| loaded to random addresses. Also for PIE-linked binaries, the |
| location of code start is randomized. This is the default if the |
| ``CONFIG_COMPAT_BRK`` option is enabled. |
| |
| 2 Additionally enable heap randomization. This is the default if |
| ``CONFIG_COMPAT_BRK`` is disabled. |
| |
| There are a few legacy applications out there (such as some ancient |
| versions of libc.so.5 from 1996) that assume that brk area starts |
| just after the end of the code+bss. These applications break when |
| start of the brk area is randomized. There are however no known |
| non-legacy applications that would be broken this way, so for most |
| systems it is safe to choose full randomization. |
| |
| Systems with ancient and/or broken binaries should be configured |
| with ``CONFIG_COMPAT_BRK`` enabled, which excludes the heap from process |
| address space randomization. |
| == =========================================================================== |
| |
| |
| real-root-dev |
| ============= |
| |
| See Documentation/admin-guide/initrd.rst. |
| |
| |
| reboot-cmd (SPARC only) |
| ======================= |
| |
| ??? This seems to be a way to give an argument to the Sparc |
| ROM/Flash boot loader. Maybe to tell it what to do after |
| rebooting. ??? |
| |
| |
| sched_energy_aware |
| ================== |
| |
| Enables/disables Energy Aware Scheduling (EAS). EAS starts |
| automatically on platforms where it can run (that is, |
| platforms with asymmetric CPU topologies and having an Energy |
| Model available). If your platform happens to meet the |
| requirements for EAS but you do not want to use it, change |
| this value to 0. |
| |
| task_delayacct |
| =============== |
| |
| Enables/disables task delay accounting (see |
| Documentation/accounting/delay-accounting.rst. Enabling this feature incurs |
| a small amount of overhead in the scheduler but is useful for debugging |
| and performance tuning. It is required by some tools such as iotop. |
| |
| sched_schedstats |
| ================ |
| |
| Enables/disables scheduler statistics. Enabling this feature |
| incurs a small amount of overhead in the scheduler but is |
| useful for debugging and performance tuning. |
| |
| sched_util_clamp_min |
| ==================== |
| |
| Max allowed *minimum* utilization. |
| |
| Default value is 1024, which is the maximum possible value. |
| |
| It means that any requested uclamp.min value cannot be greater than |
| sched_util_clamp_min, i.e., it is restricted to the range |
| [0:sched_util_clamp_min]. |
| |
| sched_util_clamp_max |
| ==================== |
| |
| Max allowed *maximum* utilization. |
| |
| Default value is 1024, which is the maximum possible value. |
| |
| It means that any requested uclamp.max value cannot be greater than |
| sched_util_clamp_max, i.e., it is restricted to the range |
| [0:sched_util_clamp_max]. |
| |
| sched_util_clamp_min_rt_default |
| =============================== |
| |
| By default Linux is tuned for performance. Which means that RT tasks always run |
| at the highest frequency and most capable (highest capacity) CPU (in |
| heterogeneous systems). |
| |
| Uclamp achieves this by setting the requested uclamp.min of all RT tasks to |
| 1024 by default, which effectively boosts the tasks to run at the highest |
| frequency and biases them to run on the biggest CPU. |
| |
| This knob allows admins to change the default behavior when uclamp is being |
| used. In battery powered devices particularly, running at the maximum |
| capacity and frequency will increase energy consumption and shorten the battery |
| life. |
| |
| This knob is only effective for RT tasks which the user hasn't modified their |
| requested uclamp.min value via sched_setattr() syscall. |
| |
| This knob will not escape the range constraint imposed by sched_util_clamp_min |
| defined above. |
| |
| For example if |
| |
| sched_util_clamp_min_rt_default = 800 |
| sched_util_clamp_min = 600 |
| |
| Then the boost will be clamped to 600 because 800 is outside of the permissible |
| range of [0:600]. This could happen for instance if a powersave mode will |
| restrict all boosts temporarily by modifying sched_util_clamp_min. As soon as |
| this restriction is lifted, the requested sched_util_clamp_min_rt_default |
| will take effect. |
| |
| seccomp |
| ======= |
| |
| See Documentation/userspace-api/seccomp_filter.rst. |
| |
| |
| sg-big-buff |
| =========== |
| |
| This file shows the size of the generic SCSI (sg) buffer. |
| You can't tune it just yet, but you could change it on |
| compile time by editing ``include/scsi/sg.h`` and changing |
| the value of ``SG_BIG_BUFF``. |
| |
| There shouldn't be any reason to change this value. If |
| you can come up with one, you probably know what you |
| are doing anyway :) |
| |
| |
| shmall |
| ====== |
| |
| This parameter sets the total amount of shared memory pages that |
| can be used system wide. Hence, ``shmall`` should always be at least |
| ``ceil(shmmax/PAGE_SIZE)``. |
| |
| If you are not sure what the default ``PAGE_SIZE`` is on your Linux |
| system, you can run the following command:: |
| |
| # getconf PAGE_SIZE |
| |
| |
| shmmax |
| ====== |
| |
| This value can be used to query and set the run time limit |
| on the maximum shared memory segment size that can be created. |
| Shared memory segments up to 1Gb are now supported in the |
| kernel. This value defaults to ``SHMMAX``. |
| |
| |
| shmmni |
| ====== |
| |
| This value determines the maximum number of shared memory segments. |
| 4096 by default (``SHMMNI``). |
| |
| |
| shm_rmid_forced |
| =============== |
| |
| Linux lets you set resource limits, including how much memory one |
| process can consume, via ``setrlimit(2)``. Unfortunately, shared memory |
| segments are allowed to exist without association with any process, and |
| thus might not be counted against any resource limits. If enabled, |
| shared memory segments are automatically destroyed when their attach |
| count becomes zero after a detach or a process termination. It will |
| also destroy segments that were created, but never attached to, on exit |
| from the process. The only use left for ``IPC_RMID`` is to immediately |
| destroy an unattached segment. Of course, this breaks the way things are |
| defined, so some applications might stop working. Note that this |
| feature will do you no good unless you also configure your resource |
| limits (in particular, ``RLIMIT_AS`` and ``RLIMIT_NPROC``). Most systems don't |
| need this. |
| |
| Note that if you change this from 0 to 1, already created segments |
| without users and with a dead originative process will be destroyed. |
| |
| |
| sysctl_writes_strict |
| ==================== |
| |
| Control how file position affects the behavior of updating sysctl values |
| via the ``/proc/sys`` interface: |
| |
| == ====================================================================== |
| -1 Legacy per-write sysctl value handling, with no printk warnings. |
| Each write syscall must fully contain the sysctl value to be |
| written, and multiple writes on the same sysctl file descriptor |
| will rewrite the sysctl value, regardless of file position. |
| 0 Same behavior as above, but warn about processes that perform writes |
| to a sysctl file descriptor when the file position is not 0. |
| 1 (default) Respect file position when writing sysctl strings. Multiple |
| writes will append to the sysctl value buffer. Anything past the max |
| length of the sysctl value buffer will be ignored. Writes to numeric |
| sysctl entries must always be at file position 0 and the value must |
| be fully contained in the buffer sent in the write syscall. |
| == ====================================================================== |
| |
| |
| softlockup_all_cpu_backtrace |
| ============================ |
| |
| This value controls the soft lockup detector thread's behavior |
| when a soft lockup condition is detected as to whether or not |
| to gather further debug information. If enabled, each cpu will |
| be issued an NMI and instructed to capture stack trace. |
| |
| This feature is only applicable for architectures which support |
| NMI. |
| |
| = ============================================ |
| 0 Do nothing. This is the default behavior. |
| 1 On detection capture more debug information. |
| = ============================================ |
| |
| |
| softlockup_panic |
| ================= |
| |
| This parameter can be used to control whether the kernel panics |
| when a soft lockup is detected. |
| |
| = ============================================ |
| 0 Don't panic on soft lockup. |
| 1 Panic on soft lockup. |
| = ============================================ |
| |
| This can also be set using the softlockup_panic kernel parameter. |
| |
| |
| soft_watchdog |
| ============= |
| |
| This parameter can be used to control the soft lockup detector. |
| |
| = ================================= |
| 0 Disable the soft lockup detector. |
| 1 Enable the soft lockup detector. |
| = ================================= |
| |
| The soft lockup detector monitors CPUs for threads that are hogging the CPUs |
| without rescheduling voluntarily, and thus prevent the 'migration/N' threads |
| from running, causing the watchdog work fail to execute. The mechanism depends |
| on the CPUs ability to respond to timer interrupts which are needed for the |
| watchdog work to be queued by the watchdog timer function, otherwise the NMI |
| watchdog — if enabled — can detect a hard lockup condition. |
| |
| |
| split_lock_mitigate (x86 only) |
| ============================== |
| |
| On x86, each "split lock" imposes a system-wide performance penalty. On larger |
| systems, large numbers of split locks from unprivileged users can result in |
| denials of service to well-behaved and potentially more important users. |
| |
| The kernel mitigates these bad users by detecting split locks and imposing |
| penalties: forcing them to wait and only allowing one core to execute split |
| locks at a time. |
| |
| These mitigations can make those bad applications unbearably slow. Setting |
| split_lock_mitigate=0 may restore some application performance, but will also |
| increase system exposure to denial of service attacks from split lock users. |
| |
| = =================================================================== |
| 0 Disable the mitigation mode - just warns the split lock on kernel log |
| and exposes the system to denials of service from the split lockers. |
| 1 Enable the mitigation mode (this is the default) - penalizes the split |
| lockers with intentional performance degradation. |
| = =================================================================== |
| |
| |
| stack_erasing |
| ============= |
| |
| This parameter can be used to control kernel stack erasing at the end |
| of syscalls for kernels built with ``CONFIG_GCC_PLUGIN_STACKLEAK``. |
| |
| That erasing reduces the information which kernel stack leak bugs |
| can reveal and blocks some uninitialized stack variable attacks. |
| The tradeoff is the performance impact: on a single CPU system kernel |
| compilation sees a 1% slowdown, other systems and workloads may vary. |
| |
| = ==================================================================== |
| 0 Kernel stack erasing is disabled, STACKLEAK_METRICS are not updated. |
| 1 Kernel stack erasing is enabled (default), it is performed before |
| returning to the userspace at the end of syscalls. |
| = ==================================================================== |
| |
| |
| stop-a (SPARC only) |
| =================== |
| |
| Controls Stop-A: |
| |
| = ==================================== |
| 0 Stop-A has no effect. |
| 1 Stop-A breaks to the PROM (default). |
| = ==================================== |
| |
| Stop-A is always enabled on a panic, so that the user can return to |
| the boot PROM. |
| |
| |
| sysrq |
| ===== |
| |
| See Documentation/admin-guide/sysrq.rst. |
| |
| |
| tainted |
| ======= |
| |
| Non-zero if the kernel has been tainted. Numeric values, which can be |
| ORed together. The letters are seen in "Tainted" line of Oops reports. |
| |
| ====== ===== ============================================================== |
| 1 `(P)` proprietary module was loaded |
| 2 `(F)` module was force loaded |
| 4 `(S)` kernel running on an out of specification system |
| 8 `(R)` module was force unloaded |
| 16 `(M)` processor reported a Machine Check Exception (MCE) |
| 32 `(B)` bad page referenced or some unexpected page flags |
| 64 `(U)` taint requested by userspace application |
| 128 `(D)` kernel died recently, i.e. there was an OOPS or BUG |
| 256 `(A)` an ACPI table was overridden by user |
| 512 `(W)` kernel issued warning |
| 1024 `(C)` staging driver was loaded |
| 2048 `(I)` workaround for bug in platform firmware applied |
| 4096 `(O)` externally-built ("out-of-tree") module was loaded |
| 8192 `(E)` unsigned module was loaded |
| 16384 `(L)` soft lockup occurred |
| 32768 `(K)` kernel has been live patched |
| 65536 `(X)` Auxiliary taint, defined and used by for distros |
| 131072 `(T)` The kernel was built with the struct randomization plugin |
| ====== ===== ============================================================== |
| |
| See Documentation/admin-guide/tainted-kernels.rst for more information. |
| |
| Note: |
| writes to this sysctl interface will fail with ``EINVAL`` if the kernel is |
| booted with the command line option ``panic_on_taint=<bitmask>,nousertaint`` |
| and any of the ORed together values being written to ``tainted`` match with |
| the bitmask declared on panic_on_taint. |
| See Documentation/admin-guide/kernel-parameters.rst for more details on |
| that particular kernel command line option and its optional |
| ``nousertaint`` switch. |
| |
| threads-max |
| =========== |
| |
| This value controls the maximum number of threads that can be created |
| using ``fork()``. |
| |
| During initialization the kernel sets this value such that even if the |
| maximum number of threads is created, the thread structures occupy only |
| a part (1/8th) of the available RAM pages. |
| |
| The minimum value that can be written to ``threads-max`` is 1. |
| |
| The maximum value that can be written to ``threads-max`` is given by the |
| constant ``FUTEX_TID_MASK`` (0x3fffffff). |
| |
| If a value outside of this range is written to ``threads-max`` an |
| ``EINVAL`` error occurs. |
| |
| |
| traceoff_on_warning |
| =================== |
| |
| When set, disables tracing (see Documentation/trace/ftrace.rst) when a |
| ``WARN()`` is hit. |
| |
| |
| tracepoint_printk |
| ================= |
| |
| When tracepoints are sent to printk() (enabled by the ``tp_printk`` |
| boot parameter), this entry provides runtime control:: |
| |
| echo 0 > /proc/sys/kernel/tracepoint_printk |
| |
| will stop tracepoints from being sent to printk(), and:: |
| |
| echo 1 > /proc/sys/kernel/tracepoint_printk |
| |
| will send them to printk() again. |
| |
| This only works if the kernel was booted with ``tp_printk`` enabled. |
| |
| See Documentation/admin-guide/kernel-parameters.rst and |
| Documentation/trace/boottime-trace.rst. |
| |
| |
| .. _unaligned-dump-stack: |
| |
| unaligned-dump-stack (ia64) |
| =========================== |
| |
| When logging unaligned accesses, controls whether the stack is |
| dumped. |
| |
| = =================================================== |
| 0 Do not dump the stack. This is the default setting. |
| 1 Dump the stack. |
| = =================================================== |
| |
| See also `ignore-unaligned-usertrap`_. |
| |
| |
| unaligned-trap |
| ============== |
| |
| On architectures where unaligned accesses cause traps, and where this |
| feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_ALLOW``; currently, |
| ``arc``, ``parisc`` and ``loongarch``), controls whether unaligned traps |
| are caught and emulated (instead of failing). |
| |
| = ======================================================== |
| 0 Do not emulate unaligned accesses. |
| 1 Emulate unaligned accesses. This is the default setting. |
| = ======================================================== |
| |
| See also `ignore-unaligned-usertrap`_. |
| |
| |
| unknown_nmi_panic |
| ================= |
| |
| The value in this file affects behavior of handling NMI. When the |
| value is non-zero, unknown NMI is trapped and then panic occurs. At |
| that time, kernel debugging information is displayed on console. |
| |
| NMI switch that most IA32 servers have fires unknown NMI up, for |
| example. If a system hangs up, try pressing the NMI switch. |
| |
| |
| unprivileged_bpf_disabled |
| ========================= |
| |
| Writing 1 to this entry will disable unprivileged calls to ``bpf()``; |
| once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` or ``CAP_BPF`` |
| will return ``-EPERM``. Once set to 1, this can't be cleared from the |
| running kernel anymore. |
| |
| Writing 2 to this entry will also disable unprivileged calls to ``bpf()``, |
| however, an admin can still change this setting later on, if needed, by |
| writing 0 or 1 to this entry. |
| |
| If ``BPF_UNPRIV_DEFAULT_OFF`` is enabled in the kernel config, then this |
| entry will default to 2 instead of 0. |
| |
| = ============================================================= |
| 0 Unprivileged calls to ``bpf()`` are enabled |
| 1 Unprivileged calls to ``bpf()`` are disabled without recovery |
| 2 Unprivileged calls to ``bpf()`` are disabled |
| = ============================================================= |
| |
| |
| warn_limit |
| ========== |
| |
| Number of kernel warnings after which the kernel should panic when |
| ``panic_on_warn`` is not set. Setting this to 0 disables checking |
| the warning count. Setting this to 1 has the same effect as setting |
| ``panic_on_warn=1``. The default value is 0. |
| |
| |
| watchdog |
| ======== |
| |
| This parameter can be used to disable or enable the soft lockup detector |
| *and* the NMI watchdog (i.e. the hard lockup detector) at the same time. |
| |
| = ============================== |
| 0 Disable both lockup detectors. |
| 1 Enable both lockup detectors. |
| = ============================== |
| |
| The soft lockup detector and the NMI watchdog can also be disabled or |
| enabled individually, using the ``soft_watchdog`` and ``nmi_watchdog`` |
| parameters. |
| If the ``watchdog`` parameter is read, for example by executing:: |
| |
| cat /proc/sys/kernel/watchdog |
| |
| the output of this command (0 or 1) shows the logical OR of |
| ``soft_watchdog`` and ``nmi_watchdog``. |
| |
| |
| watchdog_cpumask |
| ================ |
| |
| This value can be used to control on which cpus the watchdog may run. |
| The default cpumask is all possible cores, but if ``NO_HZ_FULL`` is |
| enabled in the kernel config, and cores are specified with the |
| ``nohz_full=`` boot argument, those cores are excluded by default. |
| Offline cores can be included in this mask, and if the core is later |
| brought online, the watchdog will be started based on the mask value. |
| |
| Typically this value would only be touched in the ``nohz_full`` case |
| to re-enable cores that by default were not running the watchdog, |
| if a kernel lockup was suspected on those cores. |
| |
| The argument value is the standard cpulist format for cpumasks, |
| so for example to enable the watchdog on cores 0, 2, 3, and 4 you |
| might say:: |
| |
| echo 0,2-4 > /proc/sys/kernel/watchdog_cpumask |
| |
| |
| watchdog_thresh |
| =============== |
| |
| This value can be used to control the frequency of hrtimer and NMI |
| events and the soft and hard lockup thresholds. The default threshold |
| is 10 seconds. |
| |
| The softlockup threshold is (``2 * watchdog_thresh``). Setting this |
| tunable to zero will disable lockup detection altogether. |