iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'torvalds/master' into perf/core

Browse Source 
To pick up fixes and check what UAPI headers need to be synched.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
Arnaldo Carvalho de Melo 2020-12-17 14:37:24 -03:00
commit 281a94b0f2
9617 changed files with 738019 additions and 186696 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.mailmap
View File

@ -122,6 +122,8 @@ Henk Vergonet <Henk.Vergonet@gmail.com>
Henrik Kretzschmar <henne@nachtwindheim.de>
Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
Jacob Shin <Jacob.Shin@amd.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
@ -322,6 +324,8 @@ TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Uwe Kleine-König <ukleinek@strlen.de>
Uwe Kleine-König <ukl@pengutronix.de>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
@ -341,3 +345,4 @@ Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
Yusuke Goda <goda.yusuke@renesas.com>
Zhu Yanjun <zyjzyj2000@gmail.com> <yanjunz@nvidia.com>

14
CREDITS
View File

@ -740,6 +740,11 @@ S: (ask for current address)
S: Portland, Oregon
S: USA
N: Jason Cooper
D: ARM/Marvell SOC co-maintainer
D: irqchip co-maintainer
D: MVEBU PCI DRIVER co-maintainer
N: Robin Cornelius
E: robincornelius@users.sourceforge.net
D: Ralink rt2x00 WLAN driver
@ -2505,15 +2510,6 @@ W: http://www.rdrop.com/users/paulmck/
D: RCU and variants
D: rcutorture module
N: Mike McLagan
E: mike.mclagan@linux.org
W: http://www.invlogic.com/~mmclagan
D: DLCI/FRAD drivers for Sangoma SDLAs
S: Innovative Logic Corp
S: Post Office Box 1068
S: Laurel, Maryland 20732
S: USA
N: Bradley McLean
E: brad@bradpc.gaylord.com
D: Device driver hacker

32
Documentation/ABI/obsolete/sysfs-class-net-batman-adv
View File

@ -1,32 +0,0 @@
This ABI is deprecated and will be removed after 2021. It is
replaced with the batadv generic netlink family.
What: /sys/class/net/<iface>/batman-adv/elp_interval
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the interval in milliseconds in which batman
emits probing packets for neighbor sensing (ELP).
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates the status of <iface> as it is seen by batman.
What: /sys/class/net/<iface>/batman-adv/mesh_iface
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>
currently is associated with.
What: /sys/class/net/<iface>/batman-adv/throughput_override
Date: Feb 2014
Contact: Antonio Quartulli <a@unstable.cc>
description:
Defines the throughput value to be used by B.A.T.M.A.N. V
when estimating the link throughput using this interface.
If the value is set to 0 then batman-adv will try to
estimate the throughput by itself.

110
Documentation/ABI/obsolete/sysfs-class-net-mesh
View File

@ -1,110 +0,0 @@
This ABI is deprecated and will be removed after 2021. It is
replaced with the batadv generic netlink family.
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates whether the batman protocol messages of the
mesh <mesh_iface> shall be aggregated or not.
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <a@unstable.cc>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped. <vlan_subdir> is empty when referring
to the untagged lan.
What: /sys/class/net/<mesh_iface>/mesh/bonding
Date: June 2010
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the data traffic going through the
mesh will be sent using multiple interfaces at the
same time (if available).
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
Date: November 2011
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the bridge loop avoidance feature
is enabled. This feature detects and avoids loops
between the mesh and devices bridged with the soft
interface <mesh_iface>.
What: /sys/class/net/<mesh_iface>/mesh/fragmentation
Date: October 2010
Contact: Andreas Langer <an.langer@gmx.de>
Description:
Indicates whether the data traffic going through the
mesh will be fragmented or silently discarded if the
packet size exceeds the outgoing interface MTU.
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
Date: October 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the bandwidth which is propagated by this
node if gw_mode was set to 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
Date: October 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the state of the gateway features. Can be
either 'off', 'client' or 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
Date: October 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the selection criteria this node will use
to choose a gateway if gw_mode was set to 'client'.
What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
Date: Oct 2010
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
What: /sys/class/net/<mesh_iface>/mesh/isolation_mark
Date: Nov 2013
Contact: Antonio Quartulli <a@unstable.cc>
Description:
Defines the isolation mark (and its bitmask) which
is used to classify clients as "isolated" by the
Extended Isolation feature.
What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Indicates whether multicast optimizations are enabled
or disabled. If set to zero then all nodes in the
mesh are going to use classic flooding for any
multicast packet with no optimizations.
What: /sys/class/net/<mesh_iface>/mesh/network_coding
Date: Nov 2012
Contact: Martin Hundeboll <martin@hundeboll.net>
Description:
Controls whether Network Coding (using some magic
to send fewer wifi packets but still the same
content) is enabled or not.
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the interval in milliseconds in which batman
sends its protocol messages.
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
Date: Dec 2011
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the routing procotol this mesh instance
uses to find the optimal paths through the mesh.

2
Documentation/ABI/testing/configfs-usb-gadget-ecm
View File

@ -7,7 +7,7 @@ Description:
ifname
- network device interface name associated with
this function instance
qmult
qmult
- queue length multiplier for high and
super speed
host_addr

20
Documentation/ABI/testing/procfs-attr-current Normal file
View File

@ -0,0 +1,20 @@
What: /proc/*/attr/current
Contact: linux-security-module@vger.kernel.org,
selinux@vger.kernel.org,
apparmor@lists.ubuntu.com
Description: The current security information used by a Linux
security module (LSM) that is active on the system.
The details of permissions required to read from
this interface and hence obtain the security state
of the task identified is LSM dependent.
A process cannot write to this interface unless it
refers to itself.
The other details of permissions required to write to
this interface and hence change the security state of
the task identified are LSM dependent.
The format of the data used by this interface is LSM
dependent.
SELinux, Smack and AppArmor provide this interface.
Users: SELinux user-space
Smack user-space
AppArmor user-space

20
Documentation/ABI/testing/procfs-attr-exec Normal file
View File

@ -0,0 +1,20 @@
What: /proc/*/attr/exec
Contact: linux-security-module@vger.kernel.org,
selinux@vger.kernel.org,
apparmor@lists.ubuntu.com
Description: The security information to be used on the process
by a Linux security module (LSM) active on the system
after a subsequent exec() call.
The details of permissions required to read from
this interface and hence obtain the security state
of the task identified is LSM dependent.
A process cannot write to this interface unless it
refers to itself.
The other details of permissions required to write to
this interface and hence change the security state of
the task identified are LSM dependent.
The format of the data used by this interface is LSM
dependent.
SELinux and AppArmor provide this interface.
Users: SELinux user-space
AppArmor user-space

19
Documentation/ABI/testing/procfs-attr-prev Normal file
View File

@ -0,0 +1,19 @@
What: /proc/*/attr/prev
Contact: linux-security-module@vger.kernel.org,
selinux@vger.kernel.org,
apparmor@lists.ubuntu.com
Description: The security information used on the process by
a Linux security module (LSM) active on the system
prior to the most recent exec() call.
The details of permissions required to read from
this interface is LSM dependent.
A process cannot write to this interface unless it
refers to itself.
The other details of permissions required to write to
this interface are LSM dependent.
The format of the data used by this interface is LSM
dependent.
SELinux and AppArmor provide this interface.
Users: SELinux user-space
AppArmor user-space

10
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -1743,6 +1743,16 @@ Description:
Raw counter device counters direction for channel Y.
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_label
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_label
KernelVersion: 5.8
Contact: linux-iio@vger.kernel.org
Description:
Optional symbolic label to a device channel.
If a label is defined for this channel add that to the channel
specific attributes. This is useful for userspace to be able to
better identify an individual channel.
What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org

78
Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 Normal file
View File

@ -0,0 +1,78 @@
What: /sys/bus/iio/devices/iio:deviceX/in_voltage0_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 USBID ADC which connected to connector ID pin.
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_voltage1_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 VBUS ADC with lower accuracy(+-75mA)
higher measure range(1~22mV)
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_voltage2_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 VBUS ADC with higher accuracy(+-30mA)
lower measure range(1~9.76V)
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_voltage3_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 VSYS ADC
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_voltage4_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 VBAT ADC
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_current5_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 IBUS ADC
Calculating with scale and offset returns voltage in uA
What: /sys/bus/iio/devices/iio:deviceX/in_current6_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 IBAT ADC
Calculating with scale and offset returns voltage in uA
What: /sys/bus/iio/devices/iio:deviceX/in_current7_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 CHG_VDDP ADC
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_temp8_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 IC junction temperature
Calculating with scale and offset returns temperature in degree
What: /sys/bus/iio/devices/iio:deviceX/in_voltage9_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 VREF_TS ADC
Calculating with scale and offset returns voltage in uV
What: /sys/bus/iio/devices/iio:deviceX/in_voltage10_raw
KernelVersion: 5.8.0
Contact: gene_chen@richtek.com
Description:
Indicated MT6360 TS ADC
Calculating with scale and offset returns voltage in uV

9
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -366,3 +366,12 @@ Contact: Heiner Kallweit <hkallweit1@gmail.com>
Description: If ASPM is supported for an endpoint, these files can be
used to disable or enable the individual power management
states. Write y/1/on to enable, n/0/off to disable.
What: /sys/bus/pci/devices/.../power_state
Date: November 2020
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
This file contains the current PCI power state of the device.
The value comes from the PCI kernel device state and can be one
of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold".
The file is read only.

28
Documentation/ABI/testing/sysfs-bus-thunderbolt
View File

@ -1,3 +1,31 @@
What: /sys/bus/thunderbolt/devices/<xdomain>/rx_speed
Date: Feb 2021
KernelVersion: 5.11
Contact: Isaac Hazan <isaac.hazan@intel.com>
Description: This attribute reports the XDomain RX speed per lane.
All RX lanes run at the same speed.
What: /sys/bus/thunderbolt/devices/<xdomain>/rx_lanes
Date: Feb 2021
KernelVersion: 5.11
Contact: Isaac Hazan <isaac.hazan@intel.com>
Description: This attribute reports the number of RX lanes the XDomain
is using simultaneously through its upstream port.
What: /sys/bus/thunderbolt/devices/<xdomain>/tx_speed
Date: Feb 2021
KernelVersion: 5.11
Contact: Isaac Hazan <isaac.hazan@intel.com>
Description: This attribute reports the XDomain TX speed per lane.
All TX lanes run at the same speed.
What: /sys/bus/thunderbolt/devices/<xdomain>/tx_lanes
Date: Feb 2021
KernelVersion: 5.11
Contact: Isaac Hazan <isaac.hazan@intel.com>
Description: This attribute reports number of TX lanes the XDomain
is using simultaneously through its upstream port.
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
Date: Jun 2018
KernelVersion: 4.17

54
Documentation/ABI/testing/sysfs-class-devfreq
View File

@ -37,20 +37,6 @@ Description:
The /sys/class/devfreq/.../target_freq shows the next governor
predicted target frequency of the corresponding devfreq object.
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../polling_interval shows and sets
the requested polling interval of the corresponding devfreq
object. The values are represented in ms. If the value is
less than 1 jiffy, it is considered to be 0, which means
no polling. This value is meaningless if the governor is
not polling; thus. If the governor is not using
devfreq-provided central polling
(/sys/class/devfreq/.../central_polling is 0), this value
may be useless.
What: /sys/class/devfreq/.../trans_stat
Date: October 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
@ -66,14 +52,6 @@ Description:
echo 0 > /sys/class/devfreq/.../trans_stat
What: /sys/class/devfreq/.../userspace/set_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../userspace/set_freq shows and
sets the requested frequency for the devfreq object if
userspace governor is in effect.
What: /sys/class/devfreq/.../available_frequencies
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
@ -110,6 +88,35 @@ Description:
The max_freq overrides min_freq because max_freq may be
used to throttle devices to avoid overheating.
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../polling_interval shows and sets
the requested polling interval of the corresponding devfreq
object. The values are represented in ms. If the value is
less than 1 jiffy, it is considered to be 0, which means
no polling. This value is meaningless if the governor is
not polling; thus. If the governor is not using
devfreq-provided central polling
(/sys/class/devfreq/.../central_polling is 0), this value
may be useless.
A list of governors that support the node:
- simple_ondmenad
- tegra_actmon
What: /sys/class/devfreq/.../userspace/set_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../userspace/set_freq shows and
sets the requested frequency for the devfreq object if
userspace governor is in effect.
A list of governors that support the node:
- userspace
What: /sys/class/devfreq/.../timer
Date: July 2020
Contact: Chanwoo Choi <cw00.choi@samsung.com>
@ -122,3 +129,6 @@ Description:
echo deferrable > /sys/class/devfreq/.../timer
echo delayed > /sys/class/devfreq/.../timer
A list of governors that support the node:
- simple_ondemand

23
Documentation/ABI/testing/sysfs-class-fc_host Normal file
View File

@ -0,0 +1,23 @@
What: /sys/class/fc_host/hostX/statistics/fpin_cn_yyy
Date: July 2020
Contact: Shyam Sundar <ssundar@marvell.com>
Description:
These files contain the number of congestion notification
events recorded by the F_Port, reported using fabric
performance impact notification (FPIN) event.
What: /sys/class/fc_host/hostX/statistics/fpin_li_yyy
Date: July 2020
Contact: Shyam Sundar <ssundar@marvell.com>
Description:
These files contain the number of link integrity error
events recorded by the F_Port/Nx_Port, reported using fabric
performance impact notification (FPIN) event.
What: /sys/class/fc_host/hostX/statistics/fpin_dn_yyy
Date: July 2020
Contact: Shyam Sundar <ssundar@marvell.com>
Description:
These files contain the number of delivery related errors
recorded by the F_Port/Nx_Port, reported using fabric
performance impact notification (FPIN) event.

23
Documentation/ABI/testing/sysfs-class-fc_remote_ports Normal file
View File

@ -0,0 +1,23 @@
What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_cn_yyy
Date: July 2020
Contact: Shyam Sundar <ssundar@marvell.com>
Description:
These files contain the number of congestion notification
events recorded by the F_Port/Nx_Port, reported using fabric
performance impact notification (FPIN) event.
What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_li_yyy
Date: July 2020
Contact: Shyam Sundar <ssundar@marvell.com>
Description:
These files contain the number of link integrity error
events recorded by the F_Port/Nx_Port, reported using fabric
performance impact notification (FPIN) event.
What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_dn_yyy
Date: July 2020
Contact: Shyam Sundar <ssundar@marvell.com>
Description:
These files contain the number of delivery related errors
recorded by the F_Port/Nx_Port, reported using fabric
performance impact notification (FPIN) event.

258
Documentation/ABI/testing/sysfs-class-firmware-attributes Normal file
View File

@ -0,0 +1,258 @@
What: /sys/class/firmware-attributes/*/attributes/*/
Date: February 2021
KernelVersion: 5.11
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
Mario Limonciello <mario.limonciello@dell.com>,
Prasanth KSR <prasanth.ksr@dell.com>
Description:
A sysfs interface for systems management software to enable
configuration capability on supported systems. This directory
exposes interfaces for interacting with configuration options.
Unless otherwise specified in an attribute description all attributes are optional
and will accept UTF-8 input.
type:
A file that can be read to obtain the type of attribute.
This attribute is mandatory.
The following are known types:
- enumeration: a set of pre-defined valid values
- integer: a range of numerical values
- string
All attribute types support the following values:
current_value:
A file that can be read to obtain the current
value of the <attr>.
This file can also be written to in order to update the value of a
<attr>
This attribute is mandatory.
default_value:
A file that can be read to obtain the default
value of the <attr>
display_name:
A file that can be read to obtain a user friendly
description of the at <attr>
display_name_language_code:
A file that can be read to obtain
the IETF language tag corresponding to the
"display_name" of the <attr>
"enumeration"-type specific properties:
possible_values:
A file that can be read to obtain the possible
values of the <attr>. Values are separated using
semi-colon (``;``).
"integer"-type specific properties:
min_value:
A file that can be read to obtain the lower
bound value of the <attr>
max_value:
A file that can be read to obtain the upper
bound value of the <attr>
scalar_increment:
A file that can be read to obtain the scalar value used for
increments of current_value this attribute accepts.
"string"-type specific properties:
max_length:
A file that can be read to obtain the maximum
length value of the <attr>
min_length:
A file that can be read to obtain the minimum
length value of the <attr>
Dell specific class extensions
------------------------------
On Dell systems the following additional attributes are available:
dell_modifier:
A file that can be read to obtain attribute-level
dependency rule. It says an attribute X will become read-only or
suppressed, if/if-not attribute Y is configured.
modifier rules can be in following format::
[ReadOnlyIf:<attribute>=<value>]
[ReadOnlyIfNot:<attribute>=<value>]
[SuppressIf:<attribute>=<value>]
[SuppressIfNot:<attribute>=<value>]
For example::
AutoOnFri/dell_modifier has value,
[SuppressIfNot:AutoOn=SelectDays]
This means AutoOnFri will be suppressed in BIOS setup if AutoOn
attribute is not "SelectDays" and its value will not be effective
through sysfs until this rule is met.
Enumeration attributes also support the following:
dell_value_modifier:
A file that can be read to obtain value-level dependency.
This file is similar to dell_modifier but here, an
attribute's current value will be forcefully changed based
dependent attributes value.
dell_value_modifier rules can be in following format::
<value>[ForceIf:<attribute>=<value>]
<value>[ForceIfNot:<attribute>=<value>]
For example:
LegacyOrom/dell_value_modifier has value:
Disabled[ForceIf:SecureBoot=Enabled]
This means LegacyOrom's current value will be forced to
"Disabled" in BIOS setup if SecureBoot is Enabled and its
value will not be effective through sysfs until this rule is
met.
What: /sys/class/firmware-attributes/*/authentication/
Date: February 2021
KernelVersion: 5.11
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
Mario Limonciello <mario.limonciello@dell.com>,
Prasanth KSR <prasanth.ksr@dell.com>
Description:
Devices support various authentication mechanisms which can be exposed
as a separate configuration object.
For example a "BIOS Admin" password and "System" Password can be set,
reset or cleared using these attributes.
- An "Admin" password is used for preventing modification to the BIOS
settings.
- A "System" password is required to boot a machine.
Change in any of these two authentication methods will also generate an
uevent KOBJ_CHANGE.
is_enabled:
A file that can be read to obtain a 0/1 flag to see if
<attr> authentication is enabled.
This attribute is mandatory.
role:
The type of authentication used.
This attribute is mandatory.
Known types:
bios-admin:
Representing BIOS administrator password
power-on:
Representing a password required to use
the system
mechanism:
The means of authentication. This attribute is mandatory.
Only supported type currently is "password".
max_password_length:
A file that can be read to obtain the
maximum length of the Password
min_password_length:
A file that can be read to obtain the
minimum length of the Password
current_password:
A write only value used for privileged access such as
setting attributes when a system or admin password is set
or resetting to a new password
This attribute is mandatory when mechanism == "password".
new_password:
A write only value that when used in tandem with
current_password will reset a system or admin password.
Note, password management is session specific. If Admin password is set,
same password must be written into current_password file (required for
password-validation) and must be cleared once the session is over.
For example::
echo "password" > current_password
echo "disabled" > TouchScreen/current_value
echo "" > current_password
Drivers may emit a CHANGE uevent when a password is set or unset
userspace may check it again.
On Dell systems, if Admin password is set, then all BIOS attributes
require password validation.
What: /sys/class/firmware-attributes/*/attributes/pending_reboot
Date: February 2021
KernelVersion: 5.11
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
Mario Limonciello <mario.limonciello@dell.com>,
Prasanth KSR <prasanth.ksr@dell.com>
Description:
A read-only attribute reads 1 if a reboot is necessary to apply
pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is
generated when it changes to 1.
== =========================================
0 All BIOS attributes setting are current
1 A reboot is necessary to get pending BIOS
attribute changes applied
== =========================================
Note, userspace applications need to follow below steps for efficient
BIOS management,
1. Check if admin password is set. If yes, follow session method for
password management as briefed under authentication section above.
2. Before setting any attribute, check if it has any modifiers
or value_modifiers. If yes, incorporate them and then modify
attribute.
Drivers may emit a CHANGE uevent when this value changes and userspace
may check it again.
What: /sys/class/firmware-attributes/*/attributes/reset_bios
Date: February 2021
KernelVersion: 5.11
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
Mario Limonciello <mario.limonciello@dell.com>,
Prasanth KSR <prasanth.ksr@dell.com>
Description:
This attribute can be used to reset the BIOS Configuration.
Specifically, it tells which type of reset BIOS configuration is being
requested on the host.
Reading from it returns a list of supported options encoded as:
- 'builtinsafe' (Built in safe configuration profile)
- 'lastknowngood' (Last known good saved configuration profile)
- 'factory' (Default factory settings configuration profile)
- 'custom' (Custom saved configuration profile)
The currently selected option is printed in square brackets as
shown below::
# echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios
# cat /sys/class/firmware-attributes/*/device/attributes/reset_bios
# builtinsafe lastknowngood [factory] custom
Note that any changes to this attribute requires a reboot
for changes to take effect.

119
Documentation/ABI/testing/sysfs-class-intel_pmt Normal file
View File

@ -0,0 +1,119 @@
What: /sys/class/intel_pmt/
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
The intel_pmt/ class directory contains information for
devices that expose hardware telemetry using Intel Platform
Monitoring Technology (PMT)
What: /sys/class/intel_pmt/telem<x>
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
The telem<x> directory contains files describing an instance of
a PMT telemetry device that exposes hardware telemetry. Each
telem<x> directory has an associated telem file. This file
may be opened and mapped or read to access the telemetry space
of the device. The register layout of the telemetry space is
determined from an XML file that matches the PCI device id and
GUID for the device.
What: /sys/class/intel_pmt/telem<x>/telem
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
(RO) The telemetry data for this telemetry device. This file
may be mapped or read to obtain the data.
What: /sys/class/intel_pmt/telem<x>/guid
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
(RO) The GUID for this telemetry device. The GUID identifies
the version of the XML file for the parent device that is to
be used to get the register layout.
What: /sys/class/intel_pmt/telem<x>/size
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
(RO) The size of telemetry region in bytes that corresponds to
the mapping size for the telem file.
What: /sys/class/intel_pmt/telem<x>/offset
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
(RO) The offset of telemetry region in bytes that corresponds to
the mapping for the telem file.
What: /sys/class/intel_pmt/crashlog<x>
Date: October 2020
KernelVersion: 5.10
Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Description:
The crashlog<x> directory contains files for configuring an
instance of a PMT crashlog device that can perform crash data
recording. Each crashlog<x> device has an associated crashlog
file. This file can be opened and mapped or read to access the
resulting crashlog buffer. The register layout for the buffer
can be determined from an XML file of specified GUID for the
parent device.
What: /sys/class/intel_pmt/crashlog<x>/crashlog
Date: October 2020
KernelVersion: 5.10
Contact: David Box <david.e.box@linux.intel.com>
Description:
(RO) The crashlog buffer for this crashlog device. This file
may be mapped or read to obtain the data.
What: /sys/class/intel_pmt/crashlog<x>/guid
Date: October 2020
KernelVersion: 5.10
Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Description:
(RO) The GUID for this crashlog device. The GUID identifies the
version of the XML file for the parent device that should be
used to determine the register layout.
What: /sys/class/intel_pmt/crashlog<x>/size
Date: October 2020
KernelVersion: 5.10
Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Description:
(RO) The length of the result buffer in bytes that corresponds
to the size for the crashlog buffer.
What: /sys/class/intel_pmt/crashlog<x>/offset
Date: October 2020
KernelVersion: 5.10
Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Description:
(RO) The offset of the buffer in bytes that corresponds
to the mapping for the crashlog device.
What: /sys/class/intel_pmt/crashlog<x>/enable
Date: October 2020
KernelVersion: 5.10
Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Description:
(RW) Boolean value controlling if the crashlog functionality
is enabled for the crashlog device.
What: /sys/class/intel_pmt/crashlog<x>/trigger
Date: October 2020
KernelVersion: 5.10
Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Description:
(RW) Boolean value controlling the triggering of the crashlog
device node. When read it provides data on if the crashlog has
been triggered. When written to it can be used to either clear
the current trigger by writing false, or to trigger a new
event if the trigger is not currently set.

8
Documentation/ABI/testing/sysfs-class-rnbd-client
View File

@ -66,7 +66,7 @@ Description: Expected format is the following::
The rnbd_server prepends the <device_path> received from client
with <dev_search_path> and tries to open the
<dev_search_path>/<device_path> block device. On success,
a /dev/rnbd<N> device file, a /sys/block/rnbd_client/rnbd<N>/
a /dev/rnbd<N> device file, a /sys/block/rnbd<N>/
directory and an entry in /sys/class/rnbd-client/ctl/devices
will be created.
@ -95,12 +95,12 @@ Description: Expected format is the following::
---------------------------------
After mapping, the device file can be found by:
o The symlink /sys/class/rnbd-client/ctl/devices/<device_id>
o The symlink /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>
points to /sys/block/<dev-name>. The last part of the symlink destination
is the same as the device name. By extracting the last part of the
path the path to the device /dev/<dev-name> can be build.
* /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>/dev)
* /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>/dev)
How to find the <device_id> of the device is described on the next
section.
@ -110,7 +110,7 @@ Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: For each device mapped on the client a new symbolic link is created as
/sys/class/rnbd-client/ctl/devices/<device_id>, which points
/sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>, which points
to the block device created by rnbd (/sys/block/rnbd<N>/).
The <device_id> of each device is created as follows:

8
Documentation/ABI/testing/sysfs-class-rnbd-server
View File

@ -48,3 +48,11 @@ Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the device access mode: ro, rw or migration.
What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/force_close
Date: Nov 2020
KernelVersion: 5.10
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Write "1" to the file to close the device on server side. Please
note that the client side device will not be closed, read or
write to the device will get -ENOTCONN.

142
Documentation/ABI/testing/sysfs-class-typec
View File

@ -139,6 +139,49 @@ Description:
Shows if the partner supports USB Power Delivery communication:
Valid values: yes, no
What: /sys/class/typec/<port>-partner/number_of_alternate_modes
Date: November 2020
Contact: Prashant Malani <pmalani@chromium.org>
Description:
Shows the number of alternate modes which are advertised by the partner
during Power Delivery discovery. This file remains hidden until a value
greater than or equal to 0 is set by Type C port driver.
What: /sys/class/typec/<port>-partner/type
Date: December 2020
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description: USB Power Delivery Specification defines a set of product types
for the partner devices. This file will show the product type of
the partner if it is known. Dual-role capable partners will have
both UFP and DFP product types defined, but only one that
matches the current role will be active at the time. If the
product type of the partner is not visible to the device driver,
this file will not exist.
When the partner product type is detected, or changed with role
swap, uvevent is also raised that contains PRODUCT_TYPE=<product
type> (for example PRODUCT_TYPE=hub).
Valid values:
UFP / device role
====================== ==========================
undefined -
hub PDUSB Hub
peripheral PDUSB Peripheral
psd Power Bank
ama Alternate Mode Adapter
====================== ==========================
DFP / host role
====================== ==========================
undefined -
hub PDUSB Hub
host PDUSB Host
power_brick Power Brick
amc Alternate Mode Controller
====================== ==========================
What: /sys/class/typec/<port>-partner>/identity/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
@ -151,31 +194,6 @@ Description:
directory exists, it will have an attribute file for every VDO
in Discover Identity command result.
What: /sys/class/typec/<port>-partner/identity/id_header
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
ID Header VDO part of Discover Identity command result. The
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-partner/identity/cert_stat
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Cert Stat VDO part of Discover Identity command result. The
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-partner/identity/product
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Product VDO part of Discover Identity command result. The value
will show 0 until Discover Identity command result becomes
available. The value can be polled.
USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
Note: Electronically Marked Cables will have a device also for one cable plug
@ -187,9 +205,21 @@ described in USB Type-C and USB Power Delivery specifications.
What: /sys/class/typec/<port>-cable/type
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the cable is active.
Valid values: active, passive
Description: USB Power Delivery Specification defines a set of product types
for the cables. This file will show the product type of the
cable if it is known. If the product type of the cable is not
visible to the device driver, this file will not exist.
When the cable product type is detected, uvevent is also raised
with PRODUCT_TYPE showing the product type of the cable.
Valid values:
====================== ==========================
undefined -
active Active Cable
passive Passive Cable
====================== ==========================
What: /sys/class/typec/<port>-cable/plug_type
Date: April 2017
@ -202,17 +232,37 @@ Description:
- type-c
- captive
What: /sys/class/typec/<port>-cable/identity/
What: /sys/class/typec/<port>-<plug>/number_of_alternate_modes
Date: November 2020
Contact: Prashant Malani <pmalani@chromium.org>
Description:
Shows the number of alternate modes which are advertised by the plug
associated with a particular cable during Power Delivery discovery.
This file remains hidden until a value greater than or equal to 0
is set by Type C port driver.
USB Type-C partner/cable Power Delivery Identity objects
NOTE: The following attributes will be applicable to both
partner (e.g /sys/class/typec/port0-partner/) and
cable (e.g /sys/class/typec/port0-cable/) devices. Consequently, the example file
paths below are prefixed with "/sys/class/typec/<port>-{partner|cable}/" to
reflect this.
What: /sys/class/typec/<port>-{partner|cable}/identity/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This directory appears only if the port device driver is capable
of showing the result of Discover Identity USB power delivery
command. That will not always be possible even when USB power
delivery is supported. If the directory exists, it will have an
attribute for every VDO returned by Discover Identity command.
delivery is supported, for example when USB power delivery
communication for the port is mostly handled in firmware. If the
directory exists, it will have an attribute file for every VDO
in Discover Identity command result.
What: /sys/class/typec/<port>-cable/identity/id_header
What: /sys/class/typec/<port>-{partner|cable}/identity/id_header
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@ -220,7 +270,7 @@ Description:
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-cable/identity/cert_stat
What: /sys/class/typec/<port>-{partner|cable}/identity/cert_stat
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@ -228,7 +278,7 @@ Description:
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-cable/identity/product
What: /sys/class/typec/<port>-{partner|cable}/identity/product
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@ -236,6 +286,30 @@ Description:
will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo1
Date: October 2020
Contact: Prashant Malani <pmalani@chromium.org>
Description:
1st Product Type VDO of Discover Identity command result.
The value will show 0 until Discover Identity command result becomes
available and a valid Product Type VDO is returned.
What: /sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo2
Date: October 2020
Contact: Prashant Malani <pmalani@chromium.org>
Description:
2nd Product Type VDO of Discover Identity command result.
The value will show 0 until Discover Identity command result becomes
available and a valid Product Type VDO is returned.
What: /sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo3
Date: October 2020
Contact: Prashant Malani <pmalani@chromium.org>
Description:
3rd Product Type VDO of Discover Identity command result.
The value will show 0 until Discover Identity command result becomes
available and a valid Product Type VDO is returned.
USB Type-C port alternate mode devices.

2
Documentation/ABI/testing/sysfs-devices-memory
View File

@ -19,7 +19,7 @@ Description:
identify removable sections of the memory before attempting
potentially expensive hot-remove memory operation
Users: hotplug memory remove tools
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memory/memoryX/phys_device
Date: September 2008

2
Documentation/ABI/testing/sysfs-driver-w1_therm
View File

@ -14,7 +14,7 @@ Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../eeprom
What: /sys/bus/w1/devices/.../eeprom_cmd
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:

35
Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo Normal file
View File

@ -0,0 +1,35 @@
What: /sys/firmware/lefi/boardinfo
Date: October 2020
Contact: Tiezhu Yang <yangtiezhu@loongson.cn>
Description:
Get mainboard and BIOS info easily on the Loongson platform,
this is useful to point out the current used mainboard type
and BIOS version when there exists problems related with
hardware or firmware.
The related structures are already defined in the interface
specification about firmware and kernel which are common
requirement and specific for Loongson64, so only add a new
boardinfo.c file in arch/mips/loongson64.
For example:
[loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo
Board Info
Manufacturer : LEMOTE
Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
Family : LOONGSON3
BIOS Info
Vendor : Kunlun
Version : Kunlun-A1901-V4.1.3-20200414093938
ROM Size : 4 KB
Release Date : 2020-04-14
By the way, using dmidecode command can get the similar info if there
exists SMBIOS in firmware, but the fact is that there is no SMBIOS on
some machines, we can see nothing when execute dmidecode, like this:
[root@linux loongson]# dmidecode
# dmidecode 2.12
# No SMBIOS nor DMI entry point found, sorry.

160
Documentation/ABI/testing/sysfs-firmware-sgi_uv
View File

@ -1,27 +1,159 @@
What: /sys/firmware/sgi_uv/
Date: August 2008
Contact: Russ Anderson <rja@sgi.com>
Date: September 2020
Contact: Justin Ernst <justin.ernst@hpe.com>
Description:
The /sys/firmware/sgi_uv directory contains information
about the SGI UV platform.
about the UV platform.
Under that directory are a number of files::
Under that directory are a number of read-only attributes::
archtype
hub_type
hubless
partition_id
coherence_id
uv_type
The archtype entry contains the UV architecture type that
is used to select arch-dependent addresses and features.
It can be set via the OEM_ID in the ACPI MADT table or by
UVsystab entry both passed from UV BIOS.
The hub_type entry is used to select the type of hub which is
similar to uv_type but encoded in a binary format. Include
the file uv_hub.h to get the definitions.
The hubless entry basically is present and set only if there
is no hub. In this case the hub_type entry is not present.
The partition_id entry contains the partition id.
SGI UV systems can be partitioned into multiple physical
UV systems can be partitioned into multiple physical
machines, which each partition running a unique copy
of the operating system. Each partition will have a unique
partition id. To display the partition id, use the command::
cat /sys/firmware/sgi_uv/partition_id
of the operating system. Each partition will have a unique
partition id.
The coherence_id entry contains the coherence id.
A partitioned SGI UV system can have one or more coherence
domain. The coherence id indicates which coherence domain
this partition is in. To display the coherence id, use the
command::
A partitioned UV system can have one or more coherence
domains. The coherence id indicates which coherence domain
this partition is in.
cat /sys/firmware/sgi_uv/coherence_id
The uv_type entry contains the hub revision number.
This value can be used to identify the UV system version::
"0.*" = Hubless UV ('*' is subtype)
"3.0" = UV2
"5.0" = UV3
"7.0" = UV4
"7.1" = UV4a
"9.0" = UV5
The /sys/firmware/sgi_uv directory also contains two directories::
hubs/
pcibuses/
The hubs directory contains a number of hub objects, each representing
a UV Hub visible to the BIOS. Each hub object's name is appended by a
unique ordinal value (ex. /sys/firmware/sgi_uv/hubs/hub_5)
Each hub object directory contains a number of read-only attributes::
cnode
location
name
nasid
shared
this_partition
The cnode entry contains the cnode number of the corresponding hub.
If a cnode value is not applicable, the value returned will be -1.
The location entry contains the location string of the corresponding hub.
This value is used to physically identify a hub within a system.
The name entry contains the name of the corresponding hub. This name can
be two variants::
"UVHub x.x" = A 'node' ASIC, connecting a CPU to the interconnect
fabric. The 'x.x' value represents the ASIC revision.
(ex. 'UVHub 5.0')
"NLxRouter" = A 'router ASIC, only connecting other ASICs to
the interconnect fabric. The 'x' value representing
the fabric technology version. (ex. 'NL8Router')
The nasid entry contains the nasid number of the corresponding hub.
If a nasid value is not applicable, the value returned will be -1.
The shared entry contains a boolean value describing whether the
corresponding hub is shared between system partitions.
The this_partition entry contains a boolean value describing whether
the corresponding hub is local to the current partition.
Each hub object directory also contains a number of port objects,
each representing a fabric port on the corresponding hub.
A port object's name is appended by a unique ordinal value
(ex. /sys/firmware/sgi_uv/hubs/hub_5/port_3)
Each port object directory contains a number of read-only attributes::
conn_hub
conn_port
The conn_hub entry contains a value representing the unique
oridinal value of the hub on the other end of the fabric
cable plugged into the port. If the port is disconnected,
the value returned will be -1.
The conn_port entry contains a value representing the unique
oridinal value of the port on the other end of the fabric cable
plugged into the port. If the port is disconnected, the value
returned will be -1.
Ex:
A value of '3' is read from:
/sys/firmware/sgi_uv/hubs/hub_5/port_3/conn_hub
and a value of '6' is read from:
/sys/firmware/sgi_uv/hubs/hub_5/port_3/conn_port
representing that this port is connected to:
/sys/firmware/sgi_uv/hubs/hub_3/port_6
The pcibuses directory contains a number of PCI bus objects.
Each PCI bus object's name is appended by its PCI bus address.
(ex. pcibus_0003:80)
Each pcibus object has a number of possible read-only attributes::
type
location
slot
ppb_addr
iio_stack
The type entry contains a value describing the type of IO at
the corresponding PCI bus address. Known possible values
across all UV versions are::
BASE IO
PCIe IO
PCIe SLOT
NODE IO
Riser
PPB
The location entry contains the location string of the UV Hub
of the CPU physically connected to the corresponding PCI bus.
The slot entry contains the physical slot number of the
corresponding PCI bus. This value is used to physically locate
PCI cards within a system.
The ppb_addr entry contains the PCI address string of the
bridged PCI bus. This entry is only present when the PCI bus
object type is 'PPB'.
The iio_stack entry contains a value describing the IIO stack
number that the corresponding PCI bus object is connected to.

2
Documentation/ABI/testing/sysfs-fs-ext4
View File

@ -33,7 +33,7 @@ What: /sys/fs/ext4/<disk>/mb_order2_req
Date: March 2008
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
Tuning parameter which controls the minimum size for
Tuning parameter which controls the minimum size for
requests (as a power of 2) where the buddy cache is
used

8
Documentation/ABI/testing/sysfs-kernel-btf
View File

@ -15,3 +15,11 @@ Description:
information with description of all internal kernel types. See
Documentation/bpf/btf.rst for detailed description of format
itself.
What: /sys/kernel/btf/<module-name>
Date: Nov 2020
KernelVersion: 5.11
Contact: bpf@vger.kernel.org
Description:
Read-only binary attribute exposing kernel module's BTF type
information as an add-on to the kernel's BTF (/sys/kernel/btf/vmlinux).

30
Documentation/ABI/testing/sysfs-kernel-iommu_groups
View File

@ -33,3 +33,33 @@ Description: In case an RMRR is used only by graphics or USB devices
it is now exposed as "direct-relaxable" instead of "direct".
In device assignment use case, for instance, those RMRR
are considered to be relaxable and safe.
What: /sys/kernel/iommu_groups/<grp_id>/type
Date: November 2020
KernelVersion: v5.11
Contact: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
domain in use by iommu for this group. See include/linux/iommu.h
for possible read values. A privileged user could request kernel to
change the group type by writing to this file. Valid write values:
======== ======================================================
DMA All the DMA transactions from the device in this group
are translated by the iommu.
identity All the DMA transactions from the device in this group
are not translated by the iommu.
auto Change to the type the device was booted with.
======== ======================================================
The default domain type of a group may be modified only when
- The group has only one device.
- The device in the group is not bound to any device driver.
So, the users must unbind the appropriate driver before
changing the default domain type.
Unbinding a device driver will take away the driver's control
over the device and if done on devices that host root file
system could lead to catastrophic effects (the users might
need to reboot the machine to get it to normal state). So, it's
expected that the users understand what they're doing.

32
Documentation/ABI/testing/sysfs-kernel-reboot Normal file
View File

@ -0,0 +1,32 @@
What: /sys/kernel/reboot
Date: November 2020
KernelVersion: 5.11
Contact: Matteo Croce <mcroce@microsoft.com>
Description: Interface to set the kernel reboot behavior, similarly to
what can be done via the reboot= cmdline option.
(see Documentation/admin-guide/kernel-parameters.txt)
What: /sys/kernel/reboot/mode
Date: November 2020
KernelVersion: 5.11
Contact: Matteo Croce <mcroce@microsoft.com>
Description: Reboot mode. Valid values are: cold warm hard soft gpio
What: /sys/kernel/reboot/type
Date: November 2020
KernelVersion: 5.11
Contact: Matteo Croce <mcroce@microsoft.com>
Description: Reboot type. Valid values are: bios acpi kbd triple efi pci
What: /sys/kernel/reboot/cpu
Date: November 2020
KernelVersion: 5.11
Contact: Matteo Croce <mcroce@microsoft.com>
Description: CPU number to use to reboot.
What: /sys/kernel/reboot/force
Date: November 2020
KernelVersion: 5.11
Contact: Matteo Croce <mcroce@microsoft.com>
Description: Don't wait for any other CPUs on reboot and
avoid anything that could hang.

2
Documentation/ABI/testing/sysfs-module
View File

@ -25,7 +25,7 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
However there are cases, when 80% max isochronous bandwidth is
too limiting. For example two video streams could require 110
microseconds of isochronous bandwidth per microframe to work
together.
together.
Through this setting it is possible to raise the limit so that
the host controller would allow allocating more than 100

2
Documentation/ABI/testing/sysfs-platform-renesas_usb3
View File

@ -12,6 +12,6 @@ Description:
- "peripheral" - switching mode from host to peripheral.
Read the file, then it shows the following strings:
- "host" - The mode is host now.
- "peripheral" - The mode is peripheral now.

48
Documentation/RCU/Design/Requirements/Requirements.rst
View File

@ -1929,16 +1929,46 @@ The Linux-kernel CPU-hotplug implementation has notifiers that are used
to allow the various kernel subsystems (including RCU) to respond
appropriately to a given CPU-hotplug operation. Most RCU operations may
be invoked from CPU-hotplug notifiers, including even synchronous
grace-period operations such as ``synchronize_rcu()`` and
``synchronize_rcu_expedited()``.
grace-period operations such as (``synchronize_rcu()`` and
``synchronize_rcu_expedited()``). However, these synchronous operations
do block and therefore cannot be invoked from notifiers that execute via
``stop_machine()``, specifically those between the ``CPUHP_AP_OFFLINE``
and ``CPUHP_AP_ONLINE`` states.
However, all-callback-wait operations such as ``rcu_barrier()`` are also
not supported, due to the fact that there are phases of CPU-hotplug
operations where the outgoing CPU's callbacks will not be invoked until
after the CPU-hotplug operation ends, which could also result in
deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations
during its execution, which results in another type of deadlock when
invoked from a CPU-hotplug notifier.
In addition, all-callback-wait operations such as ``rcu_barrier()`` may
not be invoked from any CPU-hotplug notifier. This restriction is due
to the fact that there are phases of CPU-hotplug operations where the
outgoing CPU's callbacks will not be invoked until after the CPU-hotplug
operation ends, which could also result in deadlock. Furthermore,
``rcu_barrier()`` blocks CPU-hotplug operations during its execution,
which results in another type of deadlock when invoked from a CPU-hotplug
notifier.
Finally, RCU must avoid deadlocks due to interaction between hotplug,
timers and grace period processing. It does so by maintaining its own set
of books that duplicate the centrally maintained ``cpu_online_mask``,
and also by reporting quiescent states explicitly when a CPU goes
offline. This explicit reporting of quiescent states avoids any need
for the force-quiescent-state loop (FQS) to report quiescent states for
offline CPUs. However, as a debugging measure, the FQS loop does splat
if offline CPUs block an RCU grace period for too long.
An offline CPU's quiescent state will be reported either:
1. As the CPU goes offline using RCU's hotplug notifier (``rcu_report_dead()``).
2. When grace period initialization (``rcu_gp_init()``) detects a
race either with CPU offlining or with a task unblocking on a leaf
``rcu_node`` structure whose CPUs are all offline.
The CPU-online path (``rcu_cpu_starting()``) should never need to report
a quiescent state for an offline CPU. However, as a debugging measure,
it does emit a warning if a quiescent state was not already reported
for that CPU.
During the checking/modification of RCU's hotplug bookkeeping, the
corresponding CPU's leaf node lock is held. This avoids race conditions
between RCU's hotplug notifier hooks, the grace period initialization
code, and the FQS loop, all of which refer to or modify this bookkeeping.
Scheduler and RCU
~~~~~~~~~~~~~~~~~

7
Documentation/RCU/checklist.rst
View File

@ -314,6 +314,13 @@ over a rather long period of time, but improvements are always welcome!
shared between readers and updaters. Additional primitives
are provided for this case, as discussed in lockdep.txt.
One exception to this rule is when data is only ever added to
the linked data structure, and is never removed during any
time that readers might be accessing that structure. In such
cases, READ_ONCE() may be used in place of rcu_dereference()
and the read-side markers (rcu_read_lock() and rcu_read_unlock(),
for example) may be omitted.
10. Conversely, if you are in an RCU read-side critical section,
and you don't hold the appropriate update-side lock, you -must-
use the "_rcu()" variants of the list macros. Failing to do so

6
Documentation/RCU/rcu_dereference.rst
View File

@ -28,6 +28,12 @@ Follow these rules to keep your RCU code working properly:
for an example where the compiler can in fact deduce the exact
value of the pointer, and thus cause misordering.
- In the special case where data is added but is never removed
while readers are accessing the structure, READ_ONCE() may be used
instead of rcu_dereference(). In this case, use of READ_ONCE()
takes on the role of the lockless_dereference() primitive that
was removed in v4.15.
- You are only permitted to use rcu_dereference on pointer values.
The compiler simply knows too much about integral values to
trust it to carry dependencies through integer operations.

3
Documentation/RCU/whatisRCU.rst
View File

@ -497,8 +497,7 @@ long -- there might be other high-priority work to be done.
In such cases, one uses call_rcu() rather than synchronize_rcu().
The call_rcu() API is as follows::
void call_rcu(struct rcu_head * head,
void (*func)(struct rcu_head *head));
void call_rcu(struct rcu_head *head, rcu_callback_t func);
This function invokes func(head) after a grace period has elapsed.
This invocation might happen from either softirq or process context,

4
Documentation/admin-guide/README.rst
View File

@ -398,8 +398,8 @@ If something goes wrong
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
document for details.
possible will help. Please read
'Documentation/admin-guide/reporting-issues.rst' for details.
- Alternatively, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the

4
Documentation/admin-guide/acpi/cppc_sysfs.rst
View File

@ -8,7 +8,7 @@ CPPC
====
CPPC defined in the ACPI spec describes a mechanism for the OS to manage the
performance of a logical processor on a contigious and abstract performance
performance of a logical processor on a contiguous and abstract performance
scale. CPPC exposes a set of registers to describe abstract performance scale,
to request performance levels and to measure per-cpu delivered performance.
@ -45,7 +45,7 @@ for each cpu X::
* lowest_freq : CPU frequency corresponding to lowest_perf (in MHz).
* nominal_freq : CPU frequency corresponding to nominal_perf (in MHz).
The above frequencies should only be used to report processor performance in
freqency instead of abstract scale. These values should not be used for any
frequency instead of abstract scale. These values should not be used for any
functional decisions.
* feedback_ctrs : Includes both Reference and delivered performance counter.

2
Documentation/admin-guide/binderfs.rst
View File

@ -70,5 +70,5 @@ Deleting binder Devices
Binderfs binder devices can be deleted via `unlink() <unlink_>`_. This means
that the `rm() <rm_>`_ tool can be used to delete them. Note that the
``binder-control`` device cannot be deleted since this would make the binderfs
instance unuseable. The ``binder-control`` device will be deleted when the
instance unusable. The ``binder-control`` device will be deleted when the
binderfs instance is unmounted and all references to it have been dropped.

2
Documentation/admin-guide/blockdev/paride.rst
View File

@ -220,7 +220,7 @@ example::
Finally, you can load high-level drivers for each kind of device that
you have connected. By default, each driver will autoprobe for a single
device, but you can support up to four similar devices by giving their
individual co-ordinates when you load the driver.
individual coordinates when you load the driver.
For example, if you had two no-name CD-ROM drives both using the
KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc

8
Documentation/admin-guide/blockdev/zram.rst
View File

@ -266,6 +266,7 @@ line of text and contains the following stats separated by whitespace:
No memory is allocated for such pages.
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
huge_pages_since the number of incompressible pages since zram set up
================ =============================================================
File /sys/block/zram<id>/bd_stat
@ -334,6 +335,11 @@ Admin can request writeback of those idle pages at right timing via::
With the command, zram writeback idle pages from memory to the storage.
If admin want to write a specific page in zram device to backing device,
they could write a page index into the interface.
echo "page_index=1251" > /sys/block/zramX/writeback
If there are lots of write IO with flash device, potentially, it has
flash wearout problem so that admin needs to design write limitation
to guarantee storage health for entire product life.
@ -360,7 +366,7 @@ like below::
/sys/block/zram0/writeback_limit.
$ echo 1 > /sys/block/zram0/writeback_limit_enable
If admins want to allow further write again once the bugdet is exhausted,
If admins want to allow further write again once the budget is exhausted,
he could do it like below::
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \

20
Documentation/admin-guide/bootconfig.rst
View File

@ -137,15 +137,24 @@ Boot Kernel With a Boot Config
==============================
Since the boot configuration file is loaded with initrd, it will be added
to the end of the initrd (initramfs) image file with size, checksum and
12-byte magic word as below.
to the end of the initrd (initramfs) image file with padding, size,
checksum and 12-byte magic word as below.
[initrd][bootconfig][size(u32)][checksum(u32)][#BOOTCONFIG\n]
[initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n]
The size and checksum fields are unsigned 32bit little endian value.
When the boot configuration is added to the initrd image, the total
file size is aligned to 4 bytes. To fill the gap, null characters
(``\0``) will be added. Thus the ``size`` is the length of the bootconfig
file + padding bytes.
The Linux kernel decodes the last part of the initrd image in memory to
get the boot configuration data.
Because of this "piggyback" method, there is no need to change or
update the boot loader and the kernel image itself.
update the boot loader and the kernel image itself as long as the boot
loader passes the correct initrd file size. If by any chance, the boot
loader passes a longer size, the kernel feils to find the bootconfig data.
To do this operation, Linux kernel provides "bootconfig" command under
tools/bootconfig, which allows admin to apply or delete the config file
@ -176,7 +185,8 @@ up to 512 key-value pairs. If keys contains 3 words in average, it can
contain 256 key-value pairs. In most cases, the number of config items
will be under 100 entries and smaller than 8KB, so it would be enough.
If the node number exceeds 1024, parser returns an error even if the file
size is smaller than 32KB.
size is smaller than 32KB. (Note that this maximum size is not including
the padding null characters.)
Anyway, since bootconfig command verifies it when appending a boot config
to initrd image, user can notice it before boot.

2
Documentation/admin-guide/bug-bisect.rst
View File

@ -15,7 +15,7 @@ give up. Report as much as you have found to the relevant maintainer. See
MAINTAINERS for who that is for the subsystem you have worked on.
Before you submit a bug report read
:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`.
'Documentation/admin-guide/reporting-issues.rst'.
Devices not appearing
=====================

2
Documentation/admin-guide/bug-hunting.rst
View File

@ -263,7 +263,7 @@ Please notice that it will point to:
- The last developers that touched the source code (if this is done inside
a git tree). On the above example, Tejun and Bhaktipriya (in this
specific case, none really envolved on the development of this file);
specific case, none really involved on the development of this file);
- The driver maintainer (Hans Verkuil);
- The subsystem maintainer (Mauro Carvalho Chehab);
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);

23
Documentation/admin-guide/cgroup-v1/memcg_test.rst
View File

@ -133,18 +133,9 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
8. LRU
======
Each memcg has its own private LRU. Now, its handling is under global
VM's control (means that it's handled under global pgdat->lru_lock).
Almost all routines around memcg's LRU is called by global LRU's
list management functions under pgdat->lru_lock.
A special function is mem_cgroup_isolate_pages(). This scans
memcg's private LRU and call __isolate_lru_page() to extract a page
from LRU.
(By __isolate_lru_page(), the page is removed from both of global and
private LRU.)
Each memcg has its own vector of LRUs (inactive anon, active anon,
inactive file, active file, unevictable) of pages from each node,
each LRU handled under a single lru_lock for that memcg and node.
9. Typical Tests.
=================
@ -219,13 +210,11 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
This is an easy way to test page migration, too.
9.5 mkdir/rmdir
---------------
9.5 nested cgroups
------------------
When using hierarchy, mkdir/rmdir test should be done.
Use tests like the following::
Use tests like the following for testing nested cgroups::
echo 1 >/opt/cgroup/01/memory/use_hierarchy
mkdir /opt/cgroup/01/child_a
mkdir /opt/cgroup/01/child_b

61
Documentation/admin-guide/cgroup-v1/memory.rst
View File

@ -77,6 +77,8 @@ Brief summary of control files.
memory.soft_limit_in_bytes set/show soft limit of memory usage
memory.stat show various statistics
memory.use_hierarchy set/show hierarchical account enabled
This knob is deprecated and shouldn't be
used.
memory.force_empty trigger forced page reclaim
memory.pressure_level set memory pressure notifications
memory.swappiness set/show swappiness parameter of vmscan
@ -285,20 +287,17 @@ When oom event notifier is registered, event will be delivered.
2.6 Locking
-----------
lock_page_cgroup()/unlock_page_cgroup() should not be called under
the i_pages lock.
Lock order is as follows:
Other lock order is following:
Page lock (PG_locked bit of page->flags)
mm->page_table_lock or split pte_lock
lock_page_memcg (memcg->move_lock)
mapping->i_pages lock
lruvec->lru_lock.
PG_locked.
mm->page_table_lock
pgdat->lru_lock
lock_page_cgroup.
In many cases, just lock_page_cgroup() is called.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
pgdat->lru_lock, it has no lock of its own.
Per-node-per-memcgroup LRU (cgroup's private LRU) is guarded by
lruvec->lru_lock; PG_lru bit of page->flags is cleared before
isolating a page from its LRU under lruvec->lru_lock.
2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
-----------------------------------------------
@ -495,16 +494,13 @@ cgroup might have some charge associated with it, even though all
tasks have migrated away from it. (because we charge against pages, not
against tasks.)
We move the stats to root (if use_hierarchy==0) or parent (if
use_hierarchy==1), and no change on the charge except uncharging
We move the stats to parent, and no change on the charge except uncharging
from the child.
Charges recorded in swap information is not updated at removal of cgroup.
Recorded information is discarded and a cgroup which uses swap (swapcache)
will be charged as a new owner of it.
About use_hierarchy, see Section 6.
5. Misc. interfaces
===================
@ -527,8 +523,6 @@ About use_hierarchy, see Section 6.
write will still return success. In this case, it is expected that
memory.kmem.usage_in_bytes == memory.usage_in_bytes.
About use_hierarchy, see Section 6.
5.2 stat file
-------------
@ -675,32 +669,21 @@ hierarchy::
d e
In the diagram above, with hierarchical accounting enabled, all memory
usage of e, is accounted to its ancestors up until the root (i.e, c and root),
that has memory.use_hierarchy enabled. If one of the ancestors goes over its
limit, the reclaim algorithm reclaims from the tasks in the ancestor and the
children of the ancestor.
usage of e, is accounted to its ancestors up until the root (i.e, c and root).
If one of the ancestors goes over its limit, the reclaim algorithm reclaims
from the tasks in the ancestor and the children of the ancestor.
6.1 Enabling hierarchical accounting and reclaim
------------------------------------------------
6.1 Hierarchical accounting and reclaim
---------------------------------------
A memory cgroup by default disables the hierarchy feature. Support
can be enabled by writing 1 to memory.use_hierarchy file of the root cgroup::
Hierarchical accounting is enabled by default. Disabling the hierarchical
accounting is deprecated. An attempt to do it will result in a failure
and a warning printed to dmesg.
For compatibility reasons writing 1 to memory.use_hierarchy will always pass::
# echo 1 > memory.use_hierarchy
The feature can be disabled by::
# echo 0 > memory.use_hierarchy
NOTE1:
Enabling/disabling will fail if either the cgroup already has other
cgroups created below it, or if the parent cgroup has use_hierarchy
enabled.
NOTE2:
When panic_on_oom is set to "2", the whole system will panic in
case of an OOM event in any cgroup.
7. Soft limits
==============

11
Documentation/admin-guide/cgroup-v2.rst
View File

@ -1274,6 +1274,9 @@ PAGE_SIZE multiple when read back.
kernel_stack
Amount of memory allocated to kernel stacks.
pagetables
Amount of memory allocated for page tables.
percpu(npn)
Amount of memory used for storing per-cpu kernel
data structures.
@ -1300,6 +1303,14 @@ PAGE_SIZE multiple when read back.
Amount of memory used in anonymous mappings backed by
transparent hugepages
file_thp
Amount of cached filesystem data backed by transparent
hugepages
shmem_thp
Amount of shm, tmpfs, shared anonymous mmap()s backed by
transparent hugepages
inactive_anon, active_anon, inactive_file, active_file, unevictable
Amount of memory, swap-backed and filesystem-backed,
on the internal memory management lists used by the

2
Documentation/admin-guide/cifs/introduction.rst
View File

@ -9,7 +9,7 @@ Introduction
PC operating systems. New and improved versions of CIFS are now
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1)
is strongly preferred over using older dialects like CIFS due to
security reaasons. All modern dialects, including the most recent,
security reasons. All modern dialects, including the most recent,
SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol
is implemented and supported by all major file servers
such as all modern versions of Windows (including Windows 2016

6
Documentation/admin-guide/cifs/usage.rst
View File

@ -115,7 +115,7 @@ later source tree in docs/manpages/mount.cifs.8
Allowing User Unmounts
======================
To permit users to ummount directories that they have user mounted (see above),
To permit users to unmount directories that they have user mounted (see above),
the utility umount.cifs may be used. It may be invoked directly, or if
umount.cifs is placed in /sbin, umount can invoke the cifs umount helper
(at least for most versions of the umount utility) for umount of cifs
@ -197,7 +197,7 @@ that is ignored by local server applications and non-cifs clients and that will
not be traversed by the Samba server). This is opaque to the Linux client
application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or
later, but only for remote clients using the CIFS Unix extensions, and will
be invisbile to Windows clients and typically will not affect local
be invisible to Windows clients and typically will not affect local
applications running on the same server as Samba.
Use instructions
@ -267,7 +267,7 @@ would be forbidden for Windows/CIFS semantics) as long as the server is
configured for Unix Extensions (and the client has not disabled
/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option
``mapposix`` can be used on CIFS (vers=1.0) to force the mapping of
illegal Windows/NTFS/SMB characters to a remap range (this mount parm
illegal Windows/NTFS/SMB characters to a remap range (this mount parameter
is the default for SMB3). This remap (``mapposix``) range is also
compatible with Mac (and "Services for Mac" on some older Windows).

4
Documentation/admin-guide/device-mapper/dm-crypt.rst
View File

@ -46,7 +46,7 @@ Parameters::
capi:authenc(hmac(sha256),xts(aes))-random
capi:rfc7539(chacha20,poly1305)-random
The /proc/crypto contains a list of curently loaded crypto modes.
The /proc/crypto contains a list of currently loaded crypto modes.
<key>
Key used for encryption. It is encoded either as a hexadecimal number
@ -92,7 +92,7 @@ Parameters::
<#opt_params>
Number of optional parameters. If there are no optional parameters,
the optional paramaters section can be skipped or #opt_params can be zero.
the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:

4
Documentation/admin-guide/device-mapper/dm-integrity.rst
View File

@ -117,7 +117,7 @@ journal_watermark:number
commit_time:number
Commit time in milliseconds. When this time passes, the journal is
written. The journal is also written immediatelly if the FLUSH
written. The journal is also written immediately if the FLUSH
request is received.
internal_hash:algorithm(:key) (the key is optional)
@ -147,7 +147,7 @@ journal_crypt:algorithm(:key) (the key is optional)
"salsa20" or "ctr(aes)").
The journal contains history of last writes to the block device,
an attacker reading the journal could see the last sector nubmers
an attacker reading the journal could see the last sector numbers
that were written. From the sector numbers, the attacker can infer
the size of files that were written. To protect against this
situation, you can encrypt the journal.

2
Documentation/admin-guide/device-mapper/dm-raid.rst
View File

@ -418,6 +418,6 @@ Version History
specific devices are requested via rebuild. Fix RAID leg
rebuild errors.
1.15.0 Fix size extensions not being synchronized in case of new MD bitmap
pages allocated; also fix those not occuring after previous reductions
pages allocated; also fix those not occurring after previous reductions
1.15.1 Fix argument count and arguments for rebuild/write_mostly/journal_(dev|mode)
on the status line.

6
Documentation/admin-guide/device-mapper/dm-zoned.rst
View File

@ -24,7 +24,7 @@ The dm-zoned implementation is simple and minimizes system overhead (CPU
and memory usage as well as storage capacity loss). For a 10TB
host-managed disk with 256 MB zones, dm-zoned memory usage per disk
instance is at most 4.5 MB and as little as 5 zones will be used
internally for storing metadata and performaing reclaim operations.
internally for storing metadata and performing reclaim operations.
dm-zoned target devices are formatted and checked using the dmzadm
utility available at:
@ -102,7 +102,7 @@ the buffer zone assigned. If the accessed chunk has no mapping, or the
accessed blocks are invalid, the read buffer is zeroed and the read
operation terminated.
After some time, the limited number of convnetional zones available may
After some time, the limited number of conventional zones available may
be exhausted (all used to map chunks or buffer sequential zones) and
unaligned writes to unbuffered chunks become impossible. To avoid this
situation, a reclaim process regularly scans used conventional zones and
@ -158,7 +158,7 @@ Ex::
dmzadm --format /dev/sdxx /dev/sdyy
Fomatted device(s) can be started with the dmzadm utility, too.:
Formatted device(s) can be started with the dmzadm utility, too.:
Ex::

2
Documentation/admin-guide/device-mapper/verity.rst
View File

@ -69,7 +69,7 @@ Construction Parameters
<#opt_params>
Number of optional parameters. If there are no optional parameters,
the optional paramaters section can be skipped or #opt_params can be zero.
the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:

4
Documentation/admin-guide/device-mapper/writecache.rst
View File

@ -37,10 +37,10 @@ Constructor parameters:
autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
when the application writes this amount of blocks without
issuing the FLUSH request, the blocks are automatically
commited
committed
autocommit_time ms (default: 1000)
autocommit time in milliseconds. The data is automatically
commited if this time passes and no FLUSH request is
committed if this time passes and no FLUSH request is
received
fua (by default on)
applicable only to persistent memory - use the FUA flag

3
Documentation/admin-guide/features.rst Normal file
View File

@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features

2
Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
View File

@ -60,7 +60,7 @@ Hyper-Thread attacks are possible.
The victim of a malicious actor does not need to make use of TSX. Only the
attacker needs to begin a TSX transaction and raise an asynchronous abort
which in turn potenitally leaks data stored in the buffers.
which in turn potentially leaks data stored in the buffers.
More detailed technical information is available in the TAA specific x86
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.

6
Documentation/admin-guide/index.rst
View File

@ -19,6 +19,7 @@ etc.
sysctl/index
abi
features
This section describes CPU vulnerabilities and their mitigations.
@ -33,7 +34,8 @@ problems and bugs in particular.
.. toctree::
:maxdepth: 1
reporting-bugs
reporting-issues
Reporting bugs (obsolete) <reporting-bugs>
security-bugs
bug-hunting
bug-bisect
@ -111,13 +113,13 @@ configure specific aspects of kernel behavior to your liking.
rtc
serial-console
svga
syscall-user-dispatch
sysrq
thunderbolt
ufs
unicode
vga-softcursor
video-output
wimax/index
xfs
.. only:: subproject and html

6
Documentation/admin-guide/kdump/vmcoreinfo.rst
View File

@ -39,6 +39,12 @@ call.
User-space tools can get the kernel name, host name, kernel release
number, kernel version, architecture name and OS type from it.
(uts_namespace, name)
---------------------
Offset of the name's member. Crash Utility and Makedumpfile get
the start address of the init_uts_ns.name from this.
node_online_map
---------------

1
Documentation/admin-guide/kernel-parameters.rst
View File

@ -172,6 +172,7 @@ parameter is applicable::
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
X86_UV SGI UV support is enabled.
XEN Xen support is enabled
XTENSA xtensa architecture is enabled.
In addition, the following text indicates that the option::

12
Documentation/admin-guide/kernel-parameters.txt
View File

@ -1883,11 +1883,6 @@
Note that using this option lowers the security
provided by tboot because it makes the system
vulnerable to DMA attacks.
nobounce [Default off]
Disable bounce buffer for untrusted devices such as
the Thunderbolt devices. This will treat the untrusted
devices as the trusted ones, hence might expose security
risks of DMA attacks.
intel_idle.max_cstate= [KNL,HW,ACPI,X86]
0 disables intel_idle and fall back on acpi_idle.
@ -2709,7 +2704,7 @@
option description.
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
[KNL, X86, MIPS, XTENSA] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
If @ss[KMG] is omitted, it is equivalent to mem=nn[KMG],
which limits max address to nn[KMG].
@ -2953,7 +2948,7 @@
mtdset= [ARM]
ARM/S3C2412 JIVE boot control
See arch/arm/mach-s3c2412/mach-jive.c
See arch/arm/mach-s3c/mach-jive.c
mtouchusb.raw_coordinates=
[HW] Make the MicroTouch USB driver use raw coordinates
@ -3375,6 +3370,8 @@
nosep [BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support.
nosgx [X86-64,SGX] Disables Intel SGX kernel support.
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC. legacy for "maxcpus=0".
@ -5663,6 +5660,7 @@
device);
j = NO_REPORT_LUNS (don't use report luns
command, uas only);
k = NO_SAME (do not use WRITE_SAME, uas only)
l = NOT_LOCKABLE (don't try to lock and
unlock ejectable media, not on uas);
m = MAX_SECTORS_64 (don't transfer more

2
Documentation/admin-guide/md.rst
View File

@ -221,7 +221,7 @@ All md devices contain:
layout
The ``layout`` for the array for the particular level. This is
simply a number that is interpretted differently by different
simply a number that is interpreted differently by different
levels. It can be written while assembling an array.
array_size

2
Documentation/admin-guide/media/bttv.rst
View File

@ -77,7 +77,7 @@ the Subsystem ID in the second line, looks like this:
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
at :doc:`bttv-cardlist` (in case you are intrested or want to mail
at :doc:`bttv-cardlist` (in case you are interested or want to mail
patches with updates).

2
Documentation/admin-guide/media/dvb_references.rst
View File

@ -10,7 +10,7 @@ The DVB mailing list linux-dvb is hosted at vger. Please see
http://vger.kernel.org/vger-lists.html#linux-media for details.
There are also some other old lists hosted at:
https://linuxtv.org/lists.php. If you're insterested on that for historic
https://linuxtv.org/lists.php. If you're interested on that for historic
reasons, please check the archive at https://linuxtv.org/pipermail/linux-dvb/.
The media subsystem Wiki is hosted at https://linuxtv.org/wiki/.

4
Documentation/admin-guide/media/frontend-cardlist.rst
View File

@ -68,7 +68,7 @@ cx24116 Conexant CX24116 based
cx24117 Conexant CX24117 based
cx24120 Conexant CX24120 based
cx24123 Conexant CX24123 based
ds3000 Montage Tehnology DS3000 based
ds3000 Montage Technology DS3000 based
mb86a16 Fujitsu MB86A16 based
mt312 Zarlink VP310/MT312/ZL10313 based
s5h1420 Samsung S5H1420 based
@ -83,7 +83,7 @@ tda10086 Philips TDA10086 based
tda8083 Philips TDA8083 based
tda8261 Philips TDA8261 based
tda826x Philips TDA826X silicon tuner
ts2020 Montage Tehnology TS2020 based tuners
ts2020 Montage Technology TS2020 based tuners
tua6100 Infineon TUA6100 PLL
cx24113 Conexant CX24113/CX24128 tuner for DVB-S/DSS
itd1000 Integrant ITD1000 Zero IF tuner for DVB-S/DSS

2
Documentation/admin-guide/media/gspca-cardlist.rst
View File

@ -305,7 +305,7 @@ pac7302 093a:2625 Genius iSlim 310
pac7302 093a:2626 Labtec 2200
pac7302 093a:2627 Genius FaceCam 300
pac7302 093a:2628 Genius iLook 300
pac7302 093a:2629 Genious iSlim 300
pac7302 093a:2629 Genius iSlim 300
pac7302 093a:262a Webcam 300k
pac7302 093a:262c Philips SPC 230 NC
jl2005bcd 0979:0227 Various brands, 19 known cameras supported

6
Documentation/admin-guide/media/ipu3.rst
View File

@ -86,7 +86,7 @@ raw Bayer format that is specific to IPU3.
Let us take the example of ov5670 sensor connected to CSI2 port 0, for a
2592x1944 image capture.
Using the media contorller APIs, the ov5670 sensor is configured to send
Using the media controller APIs, the ov5670 sensor is configured to send
frames in packed raw Bayer format to IPU3 CSI2 receiver.
.. code-block:: none
@ -313,8 +313,8 @@ configuration steps of 0.03125 (1/32).
**Geometric Distortion Correction**
Geometric Distortion Correction is used to performe correction of distortions
and image filtering. It needs some extra filter and envelop padding pixels to
Geometric Distortion Correction is used to perform correction of distortions
and image filtering. It needs some extra filter and envelope padding pixels to
work, so the input resolution of GDC should be larger than the output
resolution.

2
Documentation/admin-guide/media/remote-controller.rst
View File

@ -68,7 +68,7 @@ Using without lircd
Xorg recognizes several IR keycodes that have its numerical value lower
than 247. With the advent of Wayland, the input driver got updated too,
and should now accept all keycodes. Yet, you may want to just reasign
and should now accept all keycodes. Yet, you may want to just reassign
the keycodes to something that your favorite media application likes.
This can be done by setting

4
Documentation/admin-guide/media/rkisp1.rst
View File

@ -86,7 +86,7 @@ the driver through the rkisp_params node to improve image quality during a
video stream.
The buffer format is defined by struct :c:type:`rkisp1_stat_buffer`, and
userspace should set
:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A <v4l2-meta-fmt-stat-rkisp1>` as the
:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A <v4l2-meta-fmt-rk-isp1-stat-3a>` as the
dataformat.
.. _rkisp1_params:
@ -100,7 +100,7 @@ and others.
The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
userspace should set
:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-params-rkisp1>` as the
:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-rk-isp1-params>` as the
dataformat.

4
Documentation/admin-guide/mm/index.rst
View File

@ -3,9 +3,9 @@ Memory Management
=================
Linux memory management subsystem is responsible, as the name implies,
for managing the memory in the system. This includes implemnetation of
for managing the memory in the system. This includes implementation of
virtual memory and demand paging, memory allocation both for kernel
internal structures and user space programms, mapping of files into
internal structures and user space programs, mapping of files into
processes address space and many other cool things.
Linux memory management is a complex system with many configurable

2
Documentation/admin-guide/mm/numaperf.rst
View File

@ -74,7 +74,7 @@ memory node's access class 0 initiators as follows::
/sys/devices/system/node/nodeY/access0/initiators/
These attributes apply only when accessed from nodes that have the
are linked under the this access's inititiators.
are linked under the this access's initiators.
The performance characteristics the kernel provides for the local initiators
are exported are as follows::

15
Documentation/admin-guide/mm/transhuge.rst
View File

@ -401,21 +401,6 @@ compact_fail
is incremented if the system tries to compact memory
but failed.
compact_pages_moved
is incremented each time a page is moved. If
this value is increasing rapidly, it implies that the system
is copying a lot of data to satisfy the huge page allocation.
It is possible that the cost of copying exceeds any savings
from reduced TLB misses.
compact_pagemigrate_failed
is incremented when the underlying mechanism
for moving a page failed.
compact_blocks_moved
is incremented each time memory compaction examines
a huge page aligned range of pages.
It is possible to establish how long the stalls were using the function
tracer to record how long was spent in __alloc_pages_nodemask and
using the mm_page_alloc tracepoint to identify which allocations were

2
Documentation/admin-guide/mm/userfaultfd.rst
View File

@ -114,7 +114,7 @@ Notes:
you must provide some kind of page in your thread after reading from
the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``.
The normal behavior of the OS automatically providing a zero page on
an annonymous mmaping is not in place.
an anonymous mmaping is not in place.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate

2
Documentation/admin-guide/module-signing.rst
View File

@ -106,7 +106,7 @@ This has a number of options available:
certificate and a private key.
If the PEM file containing the private key is encrypted, or if the
PKCS#11 token requries a PIN, this can be provided at build time by
PKCS#11 token requires a PIN, this can be provided at build time by
means of the ``KBUILD_SIGN_PIN`` variable.

2
Documentation/admin-guide/perf/imx-ddr.rst
View File

@ -4,7 +4,7 @@ Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
There are no performance counters inside the DRAM controller, so performance
signals are brought out to the edge of the controller where a set of 4 x 32 bit
counters is implemented. This is controlled by the CSV modes programed in counter
counters is implemented. This is controlled by the CSV modes programmed in counter
control register which causes a large number of PERF signals to be generated.
Selection of the value for each counter is done via the config registers. There

4
Documentation/admin-guide/pm/intel-speed-select.rst
View File

@ -57,7 +57,7 @@ To get help on a command, another level of help is provided. For example for the
Summary of platform capability
------------------------------
To check the current platform and driver capaibilities, execute::
To check the current platform and driver capabilities, execute::
#intel-speed-select --info
@ -658,7 +658,7 @@ If -a option is not used, then the following steps are required before enabling
Intel(R) SST-BF:
- Discover Intel(R) SST-BF and note low and high priority base frequency
- Note the high prioity CPU list
- Note the high priority CPU list
- Enable CLOS using core-power feature set
- Configure CLOS parameters. Use CLOS.min to set to minimum performance
- Subscribe desired CPUs to CLOS groups

6
Documentation/admin-guide/pm/intel_pstate.rst
View File

@ -56,7 +56,7 @@ Operation Modes
``intel_pstate`` can operate in two different modes, active or passive. In the
active mode, it uses its own internal performance scaling governor algorithm or
allows the hardware to do preformance scaling by itself, while in the passive
allows the hardware to do performance scaling by itself, while in the passive
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
a certain performance scaling algorithm. Which of them will be in effect
depends on what kernel command line options are used and on the capabilities of
@ -380,13 +380,13 @@ argument is passed to the kernel in the command line.
``no_turbo``
If set (equal to 1), the driver is not allowed to set any turbo P-states
(see `Turbo P-states Support`_). If unset (equalt to 0, which is the
(see `Turbo P-states Support`_). If unset (equal to 0, which is the
default), turbo P-states can be set by the driver.
[Note that ``intel_pstate`` does not support the general ``boost``
attribute (supported by some other scaling drivers) which is replaced
by this one.]
This attrubute does not affect the maximum supported frequency value
This attribute does not affect the maximum supported frequency value
supplied to the ``CPUFreq`` core and exposed via the policy interface,
but it affects the maximum possible value of per-policy P-state limits
(see `Interpretation of Policy Attributes`_ below for details).

7
Documentation/admin-guide/pstore-blk.rst
View File

@ -35,7 +35,7 @@ module parameters have priority over Kconfig.
Here is an example for module parameters::
pstore_blk.blkdev=179:7 pstore_blk.kmsg_size=64
pstore_blk.blkdev=/dev/mmcblk0p7 pstore_blk.kmsg_size=64 best_effort=y
The detail of each configurations may be of interest to you.
@ -151,10 +151,7 @@ otherwise KMSG_DUMP_MAX.
Configurations for driver
-------------------------
Only a block device driver cares about these configurations. A block device
driver uses ``register_pstore_blk`` to register to pstore/blk.
A non-block device driver uses ``register_pstore_device`` with
A device driver uses ``register_pstore_device`` with
``struct pstore_device_info`` to register to pstore/blk.
.. kernel-doc:: fs/pstore/blk.c

2
Documentation/admin-guide/ramoops.rst
View File

@ -22,7 +22,7 @@ and type of the memory area are set using three variables:
* ``mem_address`` for the start
* ``mem_size`` for the size. The memory size will be rounded down to a
power of two.
* ``mem_type`` to specifiy if the memory type (default is pgprot_writecombine).
* ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use

5
Documentation/admin-guide/reporting-bugs.rst
View File

@ -1,5 +1,10 @@
.. _reportingbugs:
.. note::
This document is obsolete, and will be replaced by
'Documentation/admin-guide/reporting-issues.rst' in the near future.
Reporting bugs
++++++++++++++

1631
Documentation/admin-guide/reporting-issues.rst Normal file
View File

File diff suppressed because it is too large Load Diff

2
Documentation/admin-guide/security-bugs.rst
View File

@ -21,7 +21,7 @@ understand and fix the security vulnerability.
As it is with any bug, the more information provided the easier it
will be to diagnose and fix. Please review the procedure outlined in
:doc:`reporting-bugs` if you are unclear about what
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.

1
Documentation/admin-guide/spkguide.txt
View File

@ -344,6 +344,7 @@ spk key_slash = say_attributes
spk key_8 = speakup_paste
shift spk key_m = say_first_char
ctrl spk key_semicolon = say_last_char
spk key_r = read_all_doc
5. The Speakup Sys System

90
Documentation/admin-guide/syscall-user-dispatch.rst Normal file
View File

@ -0,0 +1,90 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
Syscall User Dispatch
=====================
Background
----------
Compatibility layers like Wine need a way to efficiently emulate system
calls of only a part of their process - the part that has the
incompatible code - while being able to execute native syscalls without
a high performance penalty on the native part of the process. Seccomp
falls short on this task, since it has limited support to efficiently
filter syscalls based on memory regions, and it doesn't support removing
filters. Therefore a new mechanism is necessary.
Syscall User Dispatch brings the filtering of the syscall dispatcher
address back to userspace. The application is in control of a flip
switch, indicating the current personality of the process. A
multiple-personality application can then flip the switch without
invoking the kernel, when crossing the compatibility layer API
boundaries, to enable/disable the syscall redirection and execute
syscalls directly (disabled) or send them to be emulated in userspace
through a SIGSYS.
The goal of this design is to provide very quick compatibility layer
boundary crosses, which is achieved by not executing a syscall to change
personality every time the compatibility layer executes. Instead, a
userspace memory region exposed to the kernel indicates the current
personality, and the application simply modifies that variable to
configure the mechanism.
There is a relatively high cost associated with handling signals on most
architectures, like x86, but at least for Wine, syscalls issued by
native Windows code are currently not known to be a performance problem,
since they are quite rare, at least for modern gaming applications.
Since this mechanism is designed to capture syscalls issued by
non-native applications, it must function on syscalls whose invocation
ABI is completely unexpected to Linux. Syscall User Dispatch, therefore
doesn't rely on any of the syscall ABI to make the filtering. It uses
only the syscall dispatcher address and the userspace key.
As the ABI of these intercepted syscalls is unknown to Linux, these
syscalls are not instrumentable via ptrace or the syscall tracepoints.
Interface
---------
A thread can setup this mechanism on supported kernels by executing the
following prctl:
prctl(PR_SET_SYSCALL_USER_DISPATCH, <op>, <offset>, <length>, [selector])
<op> is either PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF, to enable and
disable the mechanism globally for that thread. When
PR_SYS_DISPATCH_OFF is used, the other fields must be zero.
[<offset>, <offset>+<length>) delimit a memory region interval
from which syscalls are always executed directly, regardless of the
userspace selector. This provides a fast path for the C library, which
includes the most common syscall dispatchers in the native code
applications, and also provides a way for the signal handler to return
without triggering a nested SIGSYS on (rt\_)sigreturn. Users of this
interface should make sure that at least the signal trampoline code is
included in this region. In addition, for syscalls that implement the
trampoline code on the vDSO, that trampoline is never intercepted.
[selector] is a pointer to a char-sized region in the process memory
region, that provides a quick way to enable disable syscall redirection
thread-wide, without the need to invoke the kernel directly. selector
can be set to PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF. Any other
value should terminate the program with a SIGSYS.
Security Notes
--------------
Syscall User Dispatch provides functionality for compatibility layers to
quickly capture system calls issued by a non-native part of the
application, while not impacting the Linux native regions of the
process. It is not a mechanism for sandboxing system calls, and it
should not be seen as a security mechanism, since it is trivial for a
malicious application to subvert the mechanism by jumping to an allowed
dispatcher region prior to executing the syscall, or to discover the
address and modify the selector value. If the use case requires any
kind of security sandboxing, Seccomp should be used instead.
Any fork or exec of the existing process resets the mechanism to
PR_SYS_DISPATCH_OFF.

2
Documentation/admin-guide/sysctl/abi.rst
View File

@ -28,7 +28,7 @@ vsyscall32 (x86)
Determines whether the kernels maps a vDSO page into 32-bit processes;
can be set to 1 to enable, or 0 to disable. Defaults to enabled if
``CONFIG_COMPAT_VDSO`` is set, disabled otherwide.
``CONFIG_COMPAT_VDSO`` is set, disabled otherwise.
This controls the same setting as the ``vdso32`` kernel boot
parameter.

18
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -14,7 +14,7 @@ For general info and legal blurb, please look in :doc:`index`.
------------------------------------------------------------------------------
This file contains documentation for the sysctl files in
``/proc/sys/kernel/`` and is valid for Linux kernel version 2.2.
``/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
@ -879,7 +879,7 @@ The default value is 127.
perf_event_mlock_kb
===================
Control size of per-cpu ring buffer not counted agains mlock limit.
Control size of per-cpu ring buffer not counted against mlock limit.
The default value is 512 + 1 page
@ -1095,8 +1095,8 @@ 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:
=====================
sched_util_clamp_min
====================
Max allowed *minimum* utilization.
@ -1106,8 +1106,8 @@ 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:
=====================
sched_util_clamp_max
====================
Max allowed *maximum* utilization.
@ -1117,8 +1117,8 @@ 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:
================================
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
@ -1336,7 +1336,7 @@ 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)` SMP kernel oops on an officially SMP incapable processor
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

17
Documentation/admin-guide/sysctl/vm.rst
View File

@ -146,7 +146,7 @@ This should be used on systems where stalls for minor page faults are an
acceptable trade for large contiguous free memory. Set to 0 to prevent
compaction from moving pages that are unevictable. Default value is 1.
On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
to compaction, which would block the task from becomming active until the fault
to compaction, which would block the task from becoming active until the fault
is resolved.
@ -873,12 +873,17 @@ file-backed pages is less than the high watermark in a zone.
unprivileged_userfaultfd
========================
This flag controls whether unprivileged users can use the userfaultfd
system calls. Set this to 1 to allow unprivileged users to use the
userfaultfd system calls, or set this to 0 to restrict userfaultfd to only
privileged users (with SYS_CAP_PTRACE capability).
This flag controls the mode in which unprivileged users can use the
userfaultfd system calls. Set this to 0 to restrict unprivileged users
to handle page faults in user mode only. In this case, users without
SYS_CAP_PTRACE must pass UFFD_USER_MODE_ONLY in order for userfaultfd to
succeed. Prohibiting use of userfaultfd for handling faults from kernel
mode may make certain vulnerabilities more difficult to exploit.
The default value is 1.
Set this to 1 to allow unprivileged users to use the userfaultfd system
calls without any restrictions.
The default value is 0.
user_reserve_kbytes

23
Documentation/admin-guide/tainted-kernels.rst
View File

@ -84,7 +84,7 @@ Bit Log Number Reason that got the kernel tainted
=== === ====== ========================================================
0 G/P 1 proprietary module was loaded
1 _/F 2 module was force loaded
2 _/S 4 SMP kernel oops on an officially SMP incapable processor
2 _/S 4 kernel running on an out of specification system
3 _/R 8 module was force unloaded
4 _/M 16 processor reported a Machine Check Exception (MCE)
5 _/B 32 bad page referenced or some unexpected page flags
@ -116,10 +116,23 @@ More detailed explanation for tainting
1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
modules were loaded normally.
2) ``S`` if the oops occurred on an SMP kernel running on hardware that
hasn't been certified as safe to run multiprocessor.
Currently this occurs only on various Athlons that are not
SMP capable.
2) ``S`` if the kernel is running on a processor or system that is out of
specification: hardware has been put into an unsupported configuration,
therefore proper execution cannot be guaranteed.
Kernel will be tainted if, for example:
- on x86: PAE is forced through forcepae on intel CPUs (such as Pentium M)
which do not report PAE but may have a functional implementation, an SMP
kernel is running on non officially capable SMP Athlon CPUs, MSRs are
being poked at from userspace.
- on arm: kernel running on certain CPUs (such as Keystone 2) without
having certain kernel features enabled.
- on arm64: there are mismatched hardware features between CPUs, the
bootloader has booted CPUs in different modes.
- certain drivers are being used on non supported architectures (such as
scsi/snic on something else than x86_64, scsi/ips on non
x86/x86_64/itanium, have broken firmware settings for the
irqchip/irq-gic on arm64 ...).
3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
modules were unloaded normally.

3
Documentation/arm/features.rst Normal file
View File

@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features arm

2
Documentation/arm/index.rst
View File

@ -23,6 +23,8 @@ ARM Architecture
vlocks
porting
features
SoC-specific documents
======================

4
Documentation/arm/samsung-s3c24xx/gpio.rst
View File

@ -29,7 +29,7 @@ GPIOLIB
The following functions now either have a `s3c_` specific variant
or are merged into gpiolib. See the definitions in
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
arch/arm/mach-s3c/gpio-cfg.h:
- s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
- s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
@ -86,7 +86,7 @@ between the calls.
Headers
-------
See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list
See arch/arm/mach-s3c/regs-gpio-s3c24xx.h for the list
of GPIO pins, and the configuration values for them. This
is included by using #include <mach/regs-gpio.h>

22
Documentation/arm/samsung-s3c24xx/overview.rst
View File

@ -18,7 +18,7 @@ Introduction
versions.
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
included under the arch/arm/mach-s3c2416 directory. Note, while core
included under the arch/arm/mach-s3c directory. Note, while core
support for these SoCs is in, work on some of the extra peripherals
and extra interrupts is still ongoing.
@ -37,19 +37,11 @@ Configuration
Layout
------
The core support files are located in the platform code contained in
arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx.
This directory should be kept to items shared between the platform
code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code.
The core support files, register, kernel and paltform data are located in the
platform code contained in arch/arm/mach-s3c with headers in
arch/arm/mach-s3c/include
Each cpu has a directory with the support files for it, and the
machines that carry the device. For example S3C2410 is contained
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
Register, kernel and platform data definitions are held in the
arch/arm/mach-s3c2410 directory./include/mach
arch/arm/plat-s3c24xx:
arch/arm/mach-s3c:
Files in here are either common to all the s3c24xx family,
or are common to only some of them with names to indicate this
@ -134,7 +126,7 @@ Adding New Machines
should keep this in mind before altering items outside of their own
machine files.
Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
Machine definitions should be kept in arch/arm/mach-s3c,
and there are a number of examples that can be looked at.
Read the kernel patch submission policies as well as the
@ -293,7 +285,7 @@ Platform Data
}
Note, since the code is marked as __init, it should not be
exported outside arch/arm/mach-s3c2410/, or exported to
exported outside arch/arm/mach-s3c/, or exported to
modules via EXPORT_SYMBOL() and related functions.

6
Documentation/arm/samsung-s3c24xx/usb-host.rst
View File

@ -36,7 +36,7 @@ Board Support
-------------
The driver attaches to a platform device, which will need to be
added by the board specific support file in linux/arch/arm/mach-s3c2410,
added by the board specific support file in arch/arm/mach-s3c,
such as mach-bast.c or mach-smdk2410.c
The platform device's platform_data field is only needed if the
@ -51,9 +51,9 @@ Board Support
Platform Data
-------------
See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
See include/linux/platform_data/usb-ohci-s3c2410.h for the
descriptions of the platform device data. An implementation
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
can be found in arch/arm/mach-s3c/simtec-usb.c .
The `struct s3c2410_hcd_info` contains a pair of functions
that get called to enable over-current detection, and to

3
Documentation/arm/samsung/gpio.rst
View File

@ -37,5 +37,4 @@ implementation to configure pins as necessary.
The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
driver or machine to change gpio configuration.
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
on these functions.
See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions.

10
Documentation/arm/sunxi.rst
View File

@ -158,3 +158,13 @@ SunXi family
* User Manual
https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf
- Allwinner H616
* Datasheet
https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf
* User Manual
https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf

2
Documentation/arm64/elf_hwcaps.rst
View File

@ -1,3 +1,5 @@
.. _elf_hwcaps_index:
================
ARM64 ELF hwcaps
================

3
Documentation/arm64/features.rst Normal file
View File

@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features arm64

2
Documentation/arm64/index.rst
View File

@ -24,6 +24,8 @@ ARM64 Architecture
tagged-address-abi
tagged-pointers
features
.. only:: subproject and html
Indices

3
Documentation/arm64/kasan-offsets.sh
View File

@ -1,12 +1,11 @@
#!/bin/sh
# Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW
# start address at the mid-point of the kernel VA space
# start address at the top of the linear region
print_kasan_offset () {
printf "%02d\t" $1
printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
+ (1 << ($1 - 32 - $2)) \
- (1 << (64 - 32 - $2)) ))
}

45
Documentation/arm64/memory.rst
View File

@ -32,17 +32,16 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
ffff800000000000 ffff9fffffffffff 32TB kasan shadow region
ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
ffffa00008000000 ffffa0000fffffff 128MB modules
ffffa00010000000 fffffdffbffeffff ~93TB vmalloc
fffffdffbfff0000 fffffdfffe5f8fff ~998MB [guard region]
fffffdfffe5f9000 fffffdfffe9fffff 4124KB fixed mappings
fffffdfffea00000 fffffdfffebfffff 2MB [guard region]
fffffdfffec00000 fffffdffffbfffff 16MB PCI I/O space
fffffdffffc00000 fffffdffffdfffff 2MB [guard region]
fffffdffffe00000 ffffffffffdfffff 2TB vmemmap
ffffffffffe00000 ffffffffffffffff 2MB [guard region]
[ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
ffff800000000000 ffff800007ffffff 128MB bpf jit region
ffff800008000000 ffff80000fffffff 128MB modules
ffff800010000000 fffffbffefffffff 124TB vmalloc
fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
fffffbffff800000 fffffbffffffffff 8MB [guard region]
fffffc0000000000 fffffdffffffffff 2TB vmemmap
fffffe0000000000 ffffffffffffffff 2TB [guard region]
AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
@ -50,19 +49,17 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000fffffffffffff 4PB user
fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map
fff8000000000000 fffd9fffffffffff 1440TB [gap]
fffda00000000000 ffff9fffffffffff 512TB kasan shadow region
ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
ffffa00008000000 ffffa0000fffffff 128MB modules
ffffa00010000000 fffff81ffffeffff ~88TB vmalloc
fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region]
fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings
fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region]
fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O space
fffffc1fffc00000 fffffc1fffdfffff 2MB [guard region]
fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap
ffffffffffe00000 ffffffffffffffff 2MB [guard region]
fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
[fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
ffff800000000000 ffff800007ffffff 128MB bpf jit region
ffff800008000000 ffff80000fffffff 128MB modules
ffff800010000000 fffffbffefffffff 124TB vmalloc
fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
fffffbffff800000 fffffbffffffffff 8MB [guard region]
fffffc0000000000 ffffffdfffffffff ~4TB vmemmap
ffffffe000000000 ffffffffffffffff 128GB [guard region]
Translation table lookup with 4KB pages::

2
Documentation/arm64/perf.rst
View File

@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
.. _perf_index:
=====================
Perf Event Attributes
=====================

25
Documentation/arm64/tagged-pointers.rst
View File

@ -53,12 +53,25 @@ visibility.
Preserving tags
---------------
Non-zero tags are not preserved when delivering signals. This means that
signal handlers in applications making use of tags cannot rely on the
tag information for user virtual addresses being maintained for fields
inside siginfo_t. One exception to this rule is for signals raised in
response to watchpoint debug exceptions, where the tag information will
be preserved.
When delivering signals, non-zero tags are not preserved in
siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in
sigaction.sa_flags when the signal handler was installed. This means
that signal handlers in applications making use of tags cannot rely
on the tag information for user virtual addresses being maintained
in these fields unless the flag was set.
Due to architecture limitations, bits 63:60 of the fault address
are not preserved in response to synchronous tag check faults
(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
treat the values of these bits as undefined in order to accommodate
future architecture revisions which may preserve the bits.
For signals raised in response to watchpoint debug exceptions, the
tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
flag setting.
Non-zero tags are never preserved in sigcontext.fault_address
regardless of the SA_EXPOSE_TAGBITS flag setting.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.

Some files were not shown because too many files have changed in this diff Show More