From 4a33aa34e4ac2c2bd746a305d4b39fb60dedc091 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 11 Sep 2024 13:16:48 +0300 Subject: drm/display: fix kerneldocs references The commit 9da7ec9b19d8 ("drm/bridge-connector: move to DRM_DISPLAY_HELPER module") changed location of the drm_bridge_connector.c file, but didn't update the kerneldocs. Fix that. Fixes: 9da7ec9b19d8 ("drm/bridge-connector: move to DRM_DISPLAY_HELPER module") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/dri-devel/20240904163018.214efaa7@canb.auug.org.au/ Acked-by: Thomas Zimmermann Reviewed-By: Carlos Bilbao Link: https://patchwork.freedesktop.org/patch/msgid/20240911-drm-fix-dbc-docs-v1-1-ae5cb82fce1e@linaro.org Signed-off-by: Dmitry Baryshkov --- Documentation/gpu/drm-kms-helpers.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 8435e8621cc0..c3e58856f75b 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -181,7 +181,7 @@ Bridge Operations Bridge Connector Helper ----------------------- -.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c +.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c :doc: overview @@ -204,7 +204,7 @@ MIPI-DSI bridge operation Bridge Connector Helper Reference --------------------------------- -.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c +.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c :export: Panel-Bridge Helper Reference -- cgit v1.2.3 From 9de32f48c5896e033b78a31da59a6594a805753f Mon Sep 17 00:00:00 2001 From: "Rob Herring (Arm)" Date: Tue, 10 Sep 2024 18:44:39 -0500 Subject: dt-bindings: iio: dac: adi,ad56xx: Fix duplicate compatible strings adi,ad5686.yaml and adi,ad5696.yaml duplicate all the I2C device compatible strings with the exception of "adi,ad5337r". Since adi,ad5686.yaml references spi-peripheral-props.yaml, drop the I2C devices from it making it only SPI devices. Update the titles to make the distinction clear. Signed-off-by: Rob Herring (Arm) Reviewed-by: Nuno Sa Acked-by: Conor Dooley Link: https://patch.msgid.link/20240910234440.1045098-1-robh@kernel.org Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/dac/adi,ad5686.yaml | 53 +++++++--------------- .../devicetree/bindings/iio/dac/adi,ad5696.yaml | 3 +- 2 files changed, 19 insertions(+), 37 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml index b4400c52bec3..713f535bb33a 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Analog Devices AD5360 and similar DACs +title: Analog Devices AD5360 and similar SPI DACs maintainers: - Michael Hennerich @@ -12,41 +12,22 @@ maintainers: properties: compatible: - oneOf: - - description: SPI devices - enum: - - adi,ad5310r - - adi,ad5672r - - adi,ad5674r - - adi,ad5676 - - adi,ad5676r - - adi,ad5679r - - adi,ad5681r - - adi,ad5682r - - adi,ad5683 - - adi,ad5683r - - adi,ad5684 - - adi,ad5684r - - adi,ad5685r - - adi,ad5686 - - adi,ad5686r - - description: I2C devices - enum: - - adi,ad5311r - - adi,ad5337r - - adi,ad5338r - - adi,ad5671r - - adi,ad5675r - - adi,ad5691r - - adi,ad5692r - - adi,ad5693 - - adi,ad5693r - - adi,ad5694 - - adi,ad5694r - - adi,ad5695r - - adi,ad5696 - - adi,ad5696r - + enum: + - adi,ad5310r + - adi,ad5672r + - adi,ad5674r + - adi,ad5676 + - adi,ad5676r + - adi,ad5679r + - adi,ad5681r + - adi,ad5682r + - adi,ad5683 + - adi,ad5683r + - adi,ad5684 + - adi,ad5684r + - adi,ad5685r + - adi,ad5686 + - adi,ad5686r reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml index 56b0cda0f30a..b5a88b03dc2f 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/dac/adi,ad5696.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Analog Devices AD5696 and similar multi-channel DACs +title: Analog Devices AD5696 and similar I2C multi-channel DACs maintainers: - Michael Auchter @@ -16,6 +16,7 @@ properties: compatible: enum: - adi,ad5311r + - adi,ad5337r - adi,ad5338r - adi,ad5671r - adi,ad5675r -- cgit v1.2.3 From a36614bf88cd4b43984f24fd960c7aa0e43b5fb7 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Thu, 26 Sep 2024 13:32:41 +0200 Subject: ASoC: dt-bindings: renesas,rsnd: correct reg-names for R-Car Gen1 The device at 0xffd90000 is named SRU, both in the datasheet and SoC DTSI. Fix the typo in the bindings to avoid the false positive report: sound@ffd90000: reg-names:0: 'sru' is not one of ['scu', 'ssi', 'adg'] Signed-off-by: Wolfram Sang Acked-by: Kuninori Morimoto Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring (Arm) Link: https://patch.msgid.link/20240926113241.24060-2-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 3bc93c59535e..6d0d1514cd42 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -302,7 +302,7 @@ allOf: reg-names: items: enum: - - scu + - sru - ssi - adg # for Gen2/Gen3 -- cgit v1.2.3 From 081eb7932c2b244f63317a982c5e3990e2c7fbdd Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Mon, 30 Sep 2024 12:17:05 +0100 Subject: arm64: errata: Expand speculative SSBS workaround once more A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time. We worked around this for a number of CPUs in commits: * 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417") * 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround") * 145502cac7ea70b5 ("arm64: errata: Expand speculative SSBS workaround (again)") Since then, a (hopefully final) batch of updates have been published, with two more affected CPUs. For the affected CPUs the existing mitigation is sufficient, as described in their respective Software Developer Errata Notice (SDEN) documents: * Cortex-A715 (MP148) SDEN v15.0, erratum 3456084 https://developer.arm.com/documentation/SDEN-2148827/1500/ * Neoverse-N3 (MP195) SDEN v5.0, erratum 3456111 https://developer.arm.com/documentation/SDEN-3050973/0500/ Enable the existing mitigation by adding the relevant MIDRs to erratum_spec_ssbs_list, and update silicon-errata.rst and the Kconfig text accordingly. Signed-off-by: Mark Rutland Cc: James Morse Cc: Will Deacon Link: https://lore.kernel.org/r/20240930111705.3352047-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas --- Documentation/arch/arm64/silicon-errata.rst | 4 ++++ arch/arm64/Kconfig | 2 ++ arch/arm64/kernel/cpu_errata.c | 2 ++ 3 files changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index 9eb5e70b4888..ae45a409f76f 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -146,6 +146,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 | @@ -186,6 +188,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V1 | #1619801 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 | diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3e29b44d2d7b..ae495cc848c5 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1097,6 +1097,7 @@ config ARM64_ERRATUM_3194386 * ARM Cortex-A78C erratum 3324346 * ARM Cortex-A78C erratum 3324347 * ARM Cortex-A710 erratam 3324338 + * ARM Cortex-A715 errartum 3456084 * ARM Cortex-A720 erratum 3456091 * ARM Cortex-A725 erratum 3456106 * ARM Cortex-X1 erratum 3324344 @@ -1107,6 +1108,7 @@ config ARM64_ERRATUM_3194386 * ARM Cortex-X925 erratum 3324334 * ARM Neoverse-N1 erratum 3324349 * ARM Neoverse N2 erratum 3324339 + * ARM Neoverse-N3 erratum 3456111 * ARM Neoverse-V1 erratum 3324341 * ARM Neoverse V2 erratum 3324336 * ARM Neoverse-V3 erratum 3312417 diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index dfefbdf4073a..d9b9ec2bd6ff 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -439,6 +439,7 @@ static const struct midr_range erratum_spec_ssbs_list[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_A78), MIDR_ALL_VERSIONS(MIDR_CORTEX_A78C), MIDR_ALL_VERSIONS(MIDR_CORTEX_A710), + MIDR_ALL_VERSIONS(MIDR_CORTEX_A715), MIDR_ALL_VERSIONS(MIDR_CORTEX_A720), MIDR_ALL_VERSIONS(MIDR_CORTEX_A725), MIDR_ALL_VERSIONS(MIDR_CORTEX_X1), @@ -449,6 +450,7 @@ static const struct midr_range erratum_spec_ssbs_list[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_X925), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2), + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3), -- cgit v1.2.3 From d0a0c91dff5f0d2a084f5dc859360e3dd549354c Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Mon, 30 Sep 2024 18:32:38 -0300 Subject: dt-bindings: display: elgin,jg10309-01: Add own binding Currently, the compatible 'elgin,jg10309-01' is documented inside trivial-devices.yaml, but it does not fit well there as it requires extra properties such as spi-max-frequency, spi-cpha, and spi-cpol. This causes the following dt-schema warnings: make CHECK_DTBS=y rockchip/rv1108-elgin-r1.dtb -j12 DTC [C] arch/arm/boot/dts/rockchip/rv1108-elgin-r1.dtb rv1108-elgin-r1.dtb:display@0: 'spi-cpha', 'spi-cpol' do not match any of the regexes: ... Fix this problem by introducing a specific binding for the Elgin JG10309-01 SPI-controlled display. Signed-off-by: Fabio Estevam Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240930213238.977833-1-festevam@gmail.com Signed-off-by: Rob Herring (Arm) --- .../bindings/display/elgin,jg10309-01.yaml | 54 ++++++++++++++++++++++ .../devicetree/bindings/trivial-devices.yaml | 2 - 2 files changed, 54 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml b/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml new file mode 100644 index 000000000000..faca0cb3f154 --- /dev/null +++ b/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Elgin JG10309-01 SPI-controlled display + +maintainers: + - Fabio Estevam + +description: | + The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1 + board and is a custom display. + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: elgin,jg10309-01 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 24000000 + + spi-cpha: true + + spi-cpol: true + +required: + - compatible + - reg + - spi-cpha + - spi-cpol + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + display@0 { + compatible = "elgin,jg10309-01"; + reg = <0>; + spi-max-frequency = <24000000>; + spi-cpha; + spi-cpol; + }; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 0108d7507215..9bf0fb17a05e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -101,8 +101,6 @@ properties: - domintech,dmard09 # DMARD10: 3-axis Accelerometer - domintech,dmard10 - # Elgin SPI-controlled LCD - - elgin,jg10309-01 # MMA7660FC: 3-Axis Orientation/Motion Detection Sensor - fsl,mma7660 # MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer -- cgit v1.2.3 From bbd1e5ea66f6ca88624faefe0a153637f53ad15d Mon Sep 17 00:00:00 2001 From: Alexey Klimov Date: Wed, 2 Oct 2024 03:20:09 +0100 Subject: ASoC: dt-bindings: qcom,sm8250: add qrb4210-rb2-sndcard Add adsp-backed soundcard compatible for QRB4210 RB2 platform, which as of now looks fully compatible with SM8250. Signed-off-by: Alexey Klimov Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20241002022015.867031-2-alexey.klimov@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 1d3acdc0c733..2e2e01493a5f 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -30,6 +30,7 @@ properties: - qcom,apq8096-sndcard - qcom,qcm6490-idp-sndcard - qcom,qcs6490-rb3gen2-sndcard + - qcom,qrb4210-rb2-sndcard - qcom,qrb5165-rb5-sndcard - qcom,sc7180-qdsp6-sndcard - qcom,sc8280xp-sndcard -- cgit v1.2.3 From 17d8adc4cd5181c13c1041b197b76efc09eaf8a8 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Tue, 1 Oct 2024 22:47:49 +0200 Subject: ASoC: dt-bindings: davinci-mcasp: Fix interrupts property My understanding of the interrupts property is that it can either be: 1/ - TX 2/ - TX - RX 3/ - Common/combined. There are very little chances that either: - TX - Common/combined or even - TX - RX - Common/combined could be a thing. Looking at the interrupt-names definition (which uses oneOf instead of anyOf), it makes indeed little sense to use anyOf in the interrupts definition. I believe this is just a mistake, hence let's fix it. Fixes: 8be90641a0bb ("ASoC: dt-bindings: davinci-mcasp: convert McASP bindings to yaml schema") Signed-off-by: Miquel Raynal Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20241001204749.390054-1-miquel.raynal@bootlin.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml index 7735e08d35ba..ab3206ffa4af 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml @@ -102,7 +102,7 @@ properties: default: 2 interrupts: - anyOf: + oneOf: - minItems: 1 items: - description: TX interrupt -- cgit v1.2.3 From 2d7a098b9dbe78b6b56694184315fbc1647719b7 Mon Sep 17 00:00:00 2001 From: Leo Stone Date: Sat, 28 Sep 2024 17:49:34 -0700 Subject: Documentation: networking/tcp_ao: typo and grammar fixes Fix multiple grammatical issues and add a missing period to improve readability. Signed-off-by: Leo Stone Reviewed-by: Simon Horman Link: https://patch.msgid.link/20240929005001.370991-1-leocstone@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/networking/tcp_ao.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/tcp_ao.rst b/Documentation/networking/tcp_ao.rst index e96e62d1dab3..d5b6d0df63c3 100644 --- a/Documentation/networking/tcp_ao.rst +++ b/Documentation/networking/tcp_ao.rst @@ -9,7 +9,7 @@ segments between trusted peers. It adds a new TCP header option with a Message Authentication Code (MAC). MACs are produced from the content of a TCP segment using a hashing function with a password known to both peers. The intent of TCP-AO is to deprecate TCP-MD5 providing better security, -key rotation and support for variety of hashing algorithms. +key rotation and support for a variety of hashing algorithms. 1. Introduction =============== @@ -164,9 +164,9 @@ A: It should not, no action needs to be performed [7.5.2.e]:: is not available, no action is required (RNextKeyID of a received segment needs to match the MKT’s SendID). -Q: How current_key is set and when does it change? It is a user-triggered -change, or is it by a request from the remote peer? Is it set by the user -explicitly, or by a matching rule? +Q: How is current_key set, and when does it change? Is it a user-triggered +change, or is it triggered by a request from the remote peer? Is it set by the +user explicitly, or by a matching rule? A: current_key is set by RNextKeyID [6.1]:: @@ -233,8 +233,8 @@ always have one current_key [3.3]:: Q: Can a non-TCP-AO connection become a TCP-AO-enabled one? -A: No: for already established non-TCP-AO connection it would be impossible -to switch using TCP-AO as the traffic key generation requires the initial +A: No: for an already established non-TCP-AO connection it would be impossible +to switch to using TCP-AO, as the traffic key generation requires the initial sequence numbers. Paraphrasing, starting using TCP-AO would require re-establishing the TCP connection. @@ -292,7 +292,7 @@ no transparency is really needed and modern BGP daemons already have Linux provides a set of ``setsockopt()s`` and ``getsockopt()s`` that let userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs -``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used +``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used. It is not allowed to add a key on an established non-TCP-AO connection as well as to remove the last key from TCP-AO connection. @@ -361,7 +361,7 @@ not implemented. 4. ``setsockopt()`` vs ``accept()`` race ======================================== -In contrast with TCP-MD5 established connection which has just one key, +In contrast with an established TCP-MD5 connection which has just one key, TCP-AO connections may have many keys, which means that accepted connections on a listen socket may have any amount of keys as well. As copying all those keys on a first properly signed SYN would make the request socket bigger, that @@ -374,7 +374,7 @@ keys from sockets that were already established, but not yet ``accept()``'ed, hanging in the accept queue. The reverse is valid as well: if userspace adds a new key for a peer on -a listener socket, the established sockets in accept queue won't +a listener socket, the established sockets in the accept queue won't have the new keys. At this moment, the resolution for the two races: @@ -382,7 +382,7 @@ At this moment, the resolution for the two races: and ``setsockopt(TCP_AO_DEL_KEY)`` vs ``accept()`` is delegated to userspace. This means that it's expected that userspace would check the MKTs on the socket that was returned by ``accept()`` to verify that any key rotation that -happened on listen socket is reflected on the newly established connection. +happened on the listen socket is reflected on the newly established connection. This is a similar "do-nothing" approach to TCP-MD5 from the kernel side and may be changed later by introducing new flags to ``tcp_ao_add`` -- cgit v1.2.3 From 3eddb108abe3de6723cc4b77e8558ce1b3047987 Mon Sep 17 00:00:00 2001 From: Easwar Hariharan Date: Thu, 3 Oct 2024 22:52:35 +0000 Subject: arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386 Add the Microsoft Azure Cobalt 100 CPU to the list of CPUs suffering from erratum 3194386 added in commit 75b3c43eab59 ("arm64: errata: Expand speculative SSBS workaround") CC: Mark Rutland CC: James More CC: Will Deacon CC: stable@vger.kernel.org # 6.6+ Signed-off-by: Easwar Hariharan Link: https://lore.kernel.org/r/20241003225239.321774-1-eahariha@linux.microsoft.com Signed-off-by: Catalin Marinas --- Documentation/arch/arm64/silicon-errata.rst | 2 ++ arch/arm64/kernel/cpu_errata.c | 1 + 2 files changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index ae45a409f76f..65bfab1b1861 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -293,3 +293,5 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 | +----------------+-----------------+-----------------+-----------------------------+ +| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index d9b9ec2bd6ff..a78f247029ae 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -448,6 +448,7 @@ static const struct midr_range erratum_spec_ssbs_list[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_X3), MIDR_ALL_VERSIONS(MIDR_CORTEX_X4), MIDR_ALL_VERSIONS(MIDR_CORTEX_X925), + MIDR_ALL_VERSIONS(MIDR_MICROSOFT_AZURE_COBALT_100), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3), -- cgit v1.2.3 From 7b954b9ba007d03ba26135ac49b2c93208cf090e Mon Sep 17 00:00:00 2001 From: Anaswara T Rajan Date: Sat, 5 Oct 2024 12:30:56 +0530 Subject: platform/x86: dell-ddv: Fix typo in documentation Fix typo in word 'diagnostics' in documentation. Signed-off-by: Anaswara T Rajan Reviewed-by: Armin Wolf Link: https://lore.kernel.org/r/20241005070056.16326-1-anaswaratrajan@gmail.com Signed-off-by: Hans de Goede --- Documentation/wmi/devices/dell-wmi-ddv.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/wmi/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst index 2fcdfcf03327..e0c20af30948 100644 --- a/Documentation/wmi/devices/dell-wmi-ddv.rst +++ b/Documentation/wmi/devices/dell-wmi-ddv.rst @@ -8,7 +8,7 @@ Introduction ============ Many Dell notebooks made after ~2020 support a WMI-based interface for -retrieving various system data like battery temperature, ePPID, diagostic data +retrieving various system data like battery temperature, ePPID, diagnostic data and fan/thermal sensor data. This interface is likely used by the `Dell Data Vault` software on Windows, @@ -277,7 +277,7 @@ Reverse-Engineering the DDV WMI interface 4. Try to deduce the meaning of a certain WMI method by comparing the control flow with other ACPI methods (_BIX or _BIF for battery related methods for example). -5. Use the built-in UEFI diagostics to view sensor types/values for fan/thermal +5. Use the built-in UEFI diagnostics to view sensor types/values for fan/thermal related methods (sometimes overwriting static ACPI data fields can be used to test different sensor type values, since on some machines this data is not reinitialized upon a warm reset). -- cgit v1.2.3 From 5984b40f5bcd41bfd08359cdb9c8cb7ca9d3cc60 Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Sat, 5 Oct 2024 23:38:24 +0200 Subject: platform/x86: wmi: Update WMI driver API documentation The WMI driver core now passes the WMI event data to legacy notify handlers, so WMI devices sharing notification IDs are now being handled properly. Fixes: e04e2b760ddb ("platform/x86: wmi: Pass event data directly to legacy notify handlers") Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20241005213825.701887-1-W_Armin@gmx.de Signed-off-by: Hans de Goede --- Documentation/driver-api/wmi.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/wmi.rst b/Documentation/driver-api/wmi.rst index 6ca58c8249e5..4e8dbdb1fc67 100644 --- a/Documentation/driver-api/wmi.rst +++ b/Documentation/driver-api/wmi.rst @@ -7,12 +7,11 @@ WMI Driver API The WMI driver core supports a more modern bus-based interface for interacting with WMI devices, and an older GUID-based interface. The latter interface is considered to be deprecated, so new WMI drivers should generally avoid it since -it has some issues with multiple WMI devices and events sharing the same GUIDs -and/or notification IDs. The modern bus-based interface instead maps each -WMI device to a :c:type:`struct wmi_device `, so it supports -WMI devices sharing GUIDs and/or notification IDs. Drivers can then register -a :c:type:`struct wmi_driver `, which will be bound to compatible -WMI devices by the driver core. +it has some issues with multiple WMI devices sharing the same GUID. +The modern bus-based interface instead maps each WMI device to a +:c:type:`struct wmi_device `, so it supports WMI devices sharing the +same GUID. Drivers can then register a :c:type:`struct wmi_driver ` +which will be bound to compatible WMI devices by the driver core. .. kernel-doc:: include/linux/wmi.h :internal: -- cgit v1.2.3 From e60099fa648666e4c1ff0fd90f3fece543896ff3 Mon Sep 17 00:00:00 2001 From: Frank Li Date: Mon, 7 Oct 2024 11:30:42 -0400 Subject: dt-bindings: misc: fsl,qoriq-mc: remove ref for msi-parent msi-parent is standard property. Needn't ref to phandle. Add maxItems: 1 for it. Fix below warning: arch/arm64/boot/dts/freescale/fsl-ls1088a-ten64.dtb: fsl-mc@80c000000: msi-parent:0: [16, 0] is too long Reviewed-by: Krzysztof Kozlowski Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241007153047.807723-1-Frank.Li@nxp.com Signed-off-by: Rob Herring (Arm) --- Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml index 01b00d89a992..df45ff56d444 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml @@ -113,7 +113,7 @@ properties: msi-parent: deprecated: true - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 description: Describes the MSI controller node handling message interrupts for the MC. When there is no translation -- cgit v1.2.3 From 6df1197815142f968d9bdf8b82f76b0b20a0b7bb Mon Sep 17 00:00:00 2001 From: Frank Li Date: Mon, 7 Oct 2024 12:18:23 -0400 Subject: dt-bindings: interrupt-controller: fsl,ls-extirq: workaround wrong interrupt-map number The driver(drivers/irqchip/irq-ls-extirq.c) have not use standard DT function to parser interrupt-map. So it doesn't consider '#address-size' in parent interrupt controller, such as GIC. When dt-binding verify interrupt-map, item data matrix is spitted at incorrect position. So cause below warning: arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dtb: interrupt-controller@14: interrupt-map: [[0, 0, 1, 0, 0, 4, 1, 0], [1, 0, 1, 4, 2, 0, 1, 0], ... is too short Remove interrupt-map restriction to workaround this warning for 'fsl,ls1088a-extirq', 'fsl,ls2080a-extirq' and fsl,lx2160a-extirq. Other keep the same restriction. Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241007161823.811021-1-Frank.Li@nxp.com Signed-off-by: Rob Herring (Arm) --- .../interrupt-controller/fsl,ls-extirq.yaml | 26 +++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml index 199b34fdbefc..7ff4efc4758a 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml @@ -82,9 +82,6 @@ allOf: enum: - fsl,ls1043a-extirq - fsl,ls1046a-extirq - - fsl,ls1088a-extirq - - fsl,ls2080a-extirq - - fsl,lx2160a-extirq then: properties: interrupt-map: @@ -95,6 +92,29 @@ allOf: - const: 0xf - const: 0 + - if: + properties: + compatible: + contains: + enum: + - fsl,ls1088a-extirq + - fsl,ls2080a-extirq + - fsl,lx2160a-extirq +# The driver(drivers/irqchip/irq-ls-extirq.c) have not use standard DT +# function to parser interrupt-map. So it doesn't consider '#address-size' +# in parent interrupt controller, such as GIC. +# +# When dt-binding verify interrupt-map, item data matrix is spitted at +# incorrect position. Remove interrupt-map restriction because it always +# wrong. + + then: + properties: + interrupt-map-mask: + items: + - const: 0xf + - const: 0 + additionalProperties: false examples: -- cgit v1.2.3 From 368196e5019464c7bf81c797a415d09e53f5792a Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Mon, 7 Oct 2024 11:04:57 -0600 Subject: netfs: fix documentation build error Commit 86b374d061ee ("netfs: Remove fs/netfs/io.c") did what it said on the tin, but failed to remove the reference to fs/netfs/io.c from the documentation, leading to this docs build error: WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 7.3.7 ./fs/netfs/io.c' failed with return code 1 Remove the offending kernel-doc line, making the docs build process a little happier. Fixes: 86b374d061ee ("netfs: Remove fs/netfs/io.c") Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/874j5nlu86.fsf@trenco.lwn.net Signed-off-by: Christian Brauner --- Documentation/filesystems/netfs_library.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index f0d2cb257bb8..73f0bfd7e903 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -592,4 +592,3 @@ API Function Reference .. kernel-doc:: include/linux/netfs.h .. kernel-doc:: fs/netfs/buffered_read.c -.. kernel-doc:: fs/netfs/io.c -- cgit v1.2.3 From e0ed52154e866a1e9e9b97ded50b164698f0a222 Mon Sep 17 00:00:00 2001 From: Devaansh-Kumar Date: Tue, 8 Oct 2024 19:56:20 +0530 Subject: sched_ext: Documentation: Update instructions for running example schedulers Since the artifact paths for tools changed, we need to update the documentation to reflect that path. Signed-off-by: Devaansh-Kumar Signed-off-by: Tejun Heo --- Documentation/scheduler/sched-ext.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/scheduler/sched-ext.rst index 6c0d70e2e27d..7b59bbd2e564 100644 --- a/Documentation/scheduler/sched-ext.rst +++ b/Documentation/scheduler/sched-ext.rst @@ -66,7 +66,7 @@ BPF scheduler and reverts all tasks back to CFS. .. code-block:: none # make -j16 -C tools/sched_ext - # tools/sched_ext/scx_simple + # tools/sched_ext/build/bin/scx_simple local=0 global=3 local=5 global=24 local=9 global=44 -- cgit v1.2.3 From aeb218d900e3ea2cc3878ba92cb4758227075358 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Wed, 9 Oct 2024 10:12:19 +0100 Subject: docs: netdev: document guidance on cleanup patches The purpose of this section is to document what is the current practice regarding clean-up patches which address checkpatch warnings and similar problems. I feel there is a value in having this documented so others can easily refer to it. Clearly this topic is subjective. And to some extent the current practice discourages a wider range of patches than is described here. But I feel it is best to start somewhere, with the most well established part of the current practice. Signed-off-by: Simon Horman Link: https://patch.msgid.link/20241009-doc-mc-clean-v2-1-e637b665fa81@kernel.org Signed-off-by: Jakub Kicinski --- Documentation/process/maintainer-netdev.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index c9edf9e7362d..1ae71e31591c 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -355,6 +355,8 @@ just do it. As a result, a sequence of smaller series gets merged quicker and with better review coverage. Re-posting large series also increases the mailing list traffic. +.. _rcs: + Local variable ordering ("reverse xmas tree", "RCS") ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -391,6 +393,21 @@ APIs and helpers, especially scoped iterators. However, direct use of ``__free()`` within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function. +Clean-up patches +~~~~~~~~~~~~~~~~ + +Netdev discourages patches which perform simple clean-ups, which are not in +the context of other work. For example: + +* Addressing ``checkpatch.pl`` warnings +* Addressing :ref:`Local variable ordering` issues +* Conversions to device-managed APIs (``devm_`` helpers) + +This is because it is felt that the churn that such changes produce comes +at a greater cost than the value of such clean-ups. + +Conversely, spelling and grammar fixes are not discouraged. + Resending after review ~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 29ce0bca6d5fc0f14a0b7a2c6551128fc27cb8db Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 25 Sep 2024 11:56:35 +0200 Subject: Documentation/process: maintainer-soc: clarify submitting patches MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Patches for SoCs are expected to be picked up by SoC submaintainers. The main SoC maintainers should be addressed only in few cases. Rewrite the section about maintainer handling to document above expectation. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Reviewed-by: Kevin Hilman Reviewed-by: Bagas Sanjaya Cc: Linus Walleij Cc: Alexandre Belloni Cc: Will Deacon Cc: Kevin Hilman Cc: Palmer Dabbelt Cc: Geert Uytterhoeven Cc: Conor Dooley Cc: Heiko Stübner Link: https://lore.kernel.org/r/20240925095635.30452-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann --- Documentation/process/maintainer-soc.rst | 42 ++++++++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst index 12637530d68f..fe9d8bcfbd2b 100644 --- a/Documentation/process/maintainer-soc.rst +++ b/Documentation/process/maintainer-soc.rst @@ -30,10 +30,13 @@ tree as a dedicated branch covering multiple subsystems. The main SoC tree is housed on git.kernel.org: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/ +Maintainers +----------- + Clearly this is quite a wide range of topics, which no one person, or even small group of people are capable of maintaining. Instead, the SoC subsystem -is comprised of many submaintainers, each taking care of individual platforms -and driver subdirectories. +is comprised of many submaintainers (platform maintainers), each taking care of +individual platforms and driver subdirectories. In this regard, "platform" usually refers to a series of SoCs from a given vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate on a vendor level, responsible for multiple product lines. For several reasons, @@ -43,14 +46,43 @@ MAINTAINERS file. Most of these submaintainers have their own trees where they stage patches, sending pull requests to the main SoC tree. These trees are usually, but not -always, listed in MAINTAINERS. The main SoC maintainers can be reached via the -alias soc@kernel.org if there is no platform-specific maintainer, or if they -are unresponsive. +always, listed in MAINTAINERS. What the SoC tree is not, however, is a location for architecture-specific code changes. Each architecture has its own maintainers that are responsible for architectural details, CPU errata and the like. +Submitting Patches for Given SoC +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All typical platform related patches should be sent via SoC submaintainers +(platform-specific maintainers). This includes also changes to per-platform or +shared defconfigs (scripts/get_maintainer.pl might not provide correct +addresses in such case). + +Submitting Patches to the Main SoC Maintainers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The main SoC maintainers can be reached via the alias soc@kernel.org only in +following cases: + +1. There are no platform-specific maintainers. + +2. Platform-specific maintainers are unresponsive. + +3. Introducing a completely new SoC platform. Such new SoC work should be sent + first to common mailing lists, pointed out by scripts/get_maintainer.pl, for + community review. After positive community review, work should be sent to + soc@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS + files, MAINTAINERS file entry and optionally initial drivers with their + Devicetree bindings. The MAINTAINERS file entry should list new + platform-specific maintainers, who are going to be responsible for handling + patches for the platform from now on. + +Note that the soc@kernel.org is usually not the place to discuss the patches, +thus work sent to this address should be already considered as acceptable by +the community. + Information for (new) Submaintainers ------------------------------------ -- cgit v1.2.3 From f56d8d2389ba2a0cab0512637bd264611eab1b9a Mon Sep 17 00:00:00 2001 From: Joey Gouly Date: Tue, 1 Oct 2024 14:36:18 +0100 Subject: Documentation/protection-keys: add AArch64 to documentation As POE support was recently added, update the documentation. Also note that kernel threads have a default protection key register value. Signed-off-by: Joey Gouly Cc: Will Deacon Cc: Catalin Marinas Cc: Jonathan Corbet Link: https://lore.kernel.org/r/20241001133618.1547996-3-joey.gouly@arm.com [will: Adjusted wording based on feedback from Kevin] Signed-off-by: Will Deacon --- Documentation/core-api/protection-keys.rst | 38 +++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst index bf28ac0401f3..7eb7c6023e09 100644 --- a/Documentation/core-api/protection-keys.rst +++ b/Documentation/core-api/protection-keys.rst @@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on: * Intel server CPUs, Skylake and later * Intel client CPUs, Tiger Lake (11th Gen Core) and later * Future AMD CPUs + * arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE) +x86_64 +====== Pkeys work by dedicating 4 previously Reserved bits in each page table entry to a "protection key", giving 16 possible keys. @@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is theoretically space in the PAE PTEs. These permissions are enforced on data access only and have no effect on instruction fetches. +arm64 +===== + +Pkeys use 3 bits in each page table entry, to encode a "protection key index", +giving 8 possible keys. + +Protections for each key are defined with a per-CPU user-writable system +register (POR_EL0). This is a 64-bit register encoding read, write and execute +overlay permissions for each protection key index. + +Being a CPU register, POR_EL0 is inherently thread-local, potentially giving +each thread a different set of protections from every other thread. + +Unlike x86_64, the protection key permissions also apply to instruction +fetches. + Syscalls ======== @@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys:: int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey); -Before a pkey can be used, it must first be allocated with -pkey_alloc(). An application calls the WRPKRU instruction -directly in order to change access permissions to memory covered -with a key. In this example WRPKRU is wrapped by a C function -called pkey_set(). +Before a pkey can be used, it must first be allocated with pkey_alloc(). An +application writes to the architecture specific CPU register directly in order +to change access permissions to memory covered with a key. In this example +this is wrapped by a C function called pkey_set(). :: int real_prot = PROT_READ|PROT_WRITE; @@ -64,9 +82,9 @@ is no longer in use:: munmap(ptr, PAGE_SIZE); pkey_free(pkey); -.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions. - An example implementation can be found in - tools/testing/selftests/x86/protection_keys.c. +.. note:: pkey_set() is a wrapper around writing to the CPU register. + Example implementations can be found in + tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h Behavior ======== @@ -96,3 +114,7 @@ with a read():: The kernel will send a SIGSEGV in both cases, but si_code will be set to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when the plain mprotect() permissions are violated. + +Note that kernel accesses from a kthread (such as io_uring) will use a default +value for the protection key register and so will not be consistent with +userspace's value of the register or mprotect(). -- cgit v1.2.3 From caf0ea451d97c33c5bbaa0074dad33b0b2a4e649 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Tue, 8 Oct 2024 10:59:13 +0200 Subject: iomap: remove iomap_file_buffered_write_punch_delalloc Currently iomap_file_buffered_write_punch_delalloc can be called from XFS either with the invalidate lock held or not. To fix this while keeping the locking in the file system and not the iomap library code we'll need to life the locking up into the file system. To prepare for that, open code iomap_file_buffered_write_punch_delalloc in the only caller, and instead export iomap_write_delalloc_release. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino --- Documentation/filesystems/iomap/operations.rst | 2 +- fs/iomap/buffered-io.c | 85 +++++++++----------------- fs/xfs/xfs_iomap.c | 16 ++++- include/linux/iomap.h | 6 +- 4 files changed, 46 insertions(+), 63 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst index 8e6c721d2330..b93115ab8748 100644 --- a/Documentation/filesystems/iomap/operations.rst +++ b/Documentation/filesystems/iomap/operations.rst @@ -208,7 +208,7 @@ The filesystem must arrange to `cancel such `reservations `_ because writeback will not consume the reservation. -The ``iomap_file_buffered_write_punch_delalloc`` can be called from a +The ``iomap_write_delalloc_release`` can be called from a ``->iomap_end`` function to find all the clean areas of the folios caching a fresh (``IOMAP_F_NEW``) delalloc mapping. It takes the ``invalidate_lock``. diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index b944d77a78c6..b4f742f31041 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1145,10 +1145,36 @@ static void iomap_write_delalloc_scan(struct inode *inode, } /* + * When a short write occurs, the filesystem might need to use ->iomap_end + * to remove space reservations created in ->iomap_begin. + * + * For filesystems that use delayed allocation, there can be dirty pages over + * the delalloc extent outside the range of a short write but still within the + * delalloc extent allocated for this iomap if the write raced with page + * faults. + * * Punch out all the delalloc blocks in the range given except for those that * have dirty data still pending in the page cache - those are going to be * written and so must still retain the delalloc backing for writeback. * + * The punch() callback *must* only punch delalloc extents in the range passed + * to it. It must skip over all other types of extents in the range and leave + * them completely unchanged. It must do this punch atomically with respect to + * other extent modifications. + * + * The punch() callback may be called with a folio locked to prevent writeback + * extent allocation racing at the edge of the range we are currently punching. + * The locked folio may or may not cover the range being punched, so it is not + * safe for the punch() callback to lock folios itself. + * + * Lock order is: + * + * inode->i_rwsem (shared or exclusive) + * inode->i_mapping->invalidate_lock (exclusive) + * folio_lock() + * ->punch + * internal filesystem allocation lock + * * As we are scanning the page cache for data, we don't need to reimplement the * wheel - mapping_seek_hole_data() does exactly what we need to identify the * start and end of data ranges correctly even for sub-folio block sizes. This @@ -1177,7 +1203,7 @@ static void iomap_write_delalloc_scan(struct inode *inode, * require sprinkling this code with magic "+ 1" and "- 1" arithmetic and expose * the code to subtle off-by-one bugs.... */ -static void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte, +void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte, loff_t end_byte, unsigned flags, struct iomap *iomap, iomap_punch_t punch) { @@ -1243,62 +1269,7 @@ static void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte, out_unlock: filemap_invalidate_unlock(inode->i_mapping); } - -/* - * When a short write occurs, the filesystem may need to remove reserved space - * that was allocated in ->iomap_begin from it's ->iomap_end method. For - * filesystems that use delayed allocation, we need to punch out delalloc - * extents from the range that are not dirty in the page cache. As the write can - * race with page faults, there can be dirty pages over the delalloc extent - * outside the range of a short write but still within the delalloc extent - * allocated for this iomap. - * - * This function uses [start_byte, end_byte) intervals (i.e. open ended) to - * simplify range iterations. - * - * The punch() callback *must* only punch delalloc extents in the range passed - * to it. It must skip over all other types of extents in the range and leave - * them completely unchanged. It must do this punch atomically with respect to - * other extent modifications. - * - * The punch() callback may be called with a folio locked to prevent writeback - * extent allocation racing at the edge of the range we are currently punching. - * The locked folio may or may not cover the range being punched, so it is not - * safe for the punch() callback to lock folios itself. - * - * Lock order is: - * - * inode->i_rwsem (shared or exclusive) - * inode->i_mapping->invalidate_lock (exclusive) - * folio_lock() - * ->punch - * internal filesystem allocation lock - */ -void iomap_file_buffered_write_punch_delalloc(struct inode *inode, - loff_t pos, loff_t length, ssize_t written, unsigned flags, - struct iomap *iomap, iomap_punch_t punch) -{ - loff_t start_byte; - loff_t end_byte; - - if (iomap->type != IOMAP_DELALLOC) - return; - - /* If we didn't reserve the blocks, we're not allowed to punch them. */ - if (!(iomap->flags & IOMAP_F_NEW)) - return; - - start_byte = iomap_last_written_block(inode, pos, written); - end_byte = round_up(pos + length, i_blocksize(inode)); - - /* Nothing to do if we've written the entire delalloc extent */ - if (start_byte >= end_byte) - return; - - iomap_write_delalloc_release(inode, start_byte, end_byte, flags, iomap, - punch); -} -EXPORT_SYMBOL_GPL(iomap_file_buffered_write_punch_delalloc); +EXPORT_SYMBOL_GPL(iomap_write_delalloc_release); static loff_t iomap_unshare_iter(struct iomap_iter *iter) { diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 1e11f48814c0..30f2530b6d54 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -1227,8 +1227,20 @@ xfs_buffered_write_iomap_end( unsigned flags, struct iomap *iomap) { - iomap_file_buffered_write_punch_delalloc(inode, offset, length, written, - flags, iomap, &xfs_buffered_write_delalloc_punch); + loff_t start_byte, end_byte; + + /* If we didn't reserve the blocks, we're not allowed to punch them. */ + if (iomap->type != IOMAP_DELALLOC || !(iomap->flags & IOMAP_F_NEW)) + return 0; + + /* Nothing to do if we've written the entire delalloc extent */ + start_byte = iomap_last_written_block(inode, offset, written); + end_byte = round_up(offset + length, i_blocksize(inode)); + if (start_byte >= end_byte) + return 0; + + iomap_write_delalloc_release(inode, start_byte, end_byte, flags, iomap, + xfs_buffered_write_delalloc_punch); return 0; } diff --git a/include/linux/iomap.h b/include/linux/iomap.h index 62253739dedc..d0420e962ffd 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -290,9 +290,9 @@ vm_fault_t iomap_page_mkwrite(struct vm_fault *vmf, typedef void (*iomap_punch_t)(struct inode *inode, loff_t offset, loff_t length, struct iomap *iomap); -void iomap_file_buffered_write_punch_delalloc(struct inode *inode, loff_t pos, - loff_t length, ssize_t written, unsigned flag, - struct iomap *iomap, iomap_punch_t punch); +void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte, + loff_t end_byte, unsigned flags, struct iomap *iomap, + iomap_punch_t punch); int iomap_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo, u64 start, u64 len, const struct iomap_ops *ops); -- cgit v1.2.3 From 6ed97afd75cc5cac34b1c15a930ab2a6b7c6ff0f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sat, 12 Oct 2024 22:35:22 +0200 Subject: dt-bindings: net: brcm,unimac-mdio: Add bcm6846-mdio The MDIO block in the BCM6846 is not identical to any of the previous versions, but has extended registers not present in the other variants. For this reason we need to use a new compatible especially for this SoC. Suggested-by: Florian Fainelli Link: https://lore.kernel.org/linux-devicetree/b542b2e8-115c-4234-a464-e73aa6bece5c@broadcom.com/ Signed-off-by: Linus Walleij Acked-by: Rob Herring (Arm) Link: https://patch.msgid.link/20241012-bcm6846-mdio-v1-1-c703ca83e962@linaro.org Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml index 23dfe0838dca..63bee5b542f5 100644 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -26,6 +26,7 @@ properties: - brcm,asp-v2.1-mdio - brcm,asp-v2.2-mdio - brcm,unimac-mdio + - brcm,bcm6846-mdio reg: minItems: 1 -- cgit v1.2.3 From 46e10f644ac0a48d719436d4e9d61289f3979835 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Fri, 11 Oct 2024 10:01:53 -0700 Subject: Docs/damon/maintainer-profile: add missing '_' suffixes for external web links Patch series "Docs/damon/maintainer-profile: a couple of minor hotfixes". DAMON maintainer-profile.rst file patches[1] that were merged into the v6.12-rc1 have a couple of minor mistakes. Fix those. [1] https://lore.kernel.org/20240826015741.80707-1-sj@kernel.org This patch (of 2): Links to external web pages on DAMON's maintainer-profile.rst are missing '_' suffixes. As a result, rendered document is having only verbose URLs that cannot be clicked. Fix those. Also, update the link texts for git trees to contain the names of the trees, for better readability and avoiding below Sphinx warning. maintainer-profile.rst:4: WARNING: Duplicate explicit target name: "tree". Link: https://lkml.kernel.org/r/20241011170154.70651-1-sj@kernel.org Link: https://lkml.kernel.org/r/20241011170154.70651-2-sj@kernel.org Fixes: 2e9b3d6e2e59 ("Docs/damon/maintainer-profile: add links in place") Signed-off-by: SeongJae Park Cc: Jonathan Corbet Signed-off-by: Andrew Morton --- Documentation/mm/damon/maintainer-profile.rst | 38 +++++++++++++-------------- 1 file changed, 19 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst index 2365c9a3c1f0..7b966480c79e 100644 --- a/Documentation/mm/damon/maintainer-profile.rst +++ b/Documentation/mm/damon/maintainer-profile.rst @@ -7,26 +7,26 @@ The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR' section of 'MAINTAINERS' file. The mailing lists for the subsystem are damon@lists.linux.dev and -linux-mm@kvack.org. Patches should be made against the mm-unstable `tree -` whenever possible and posted to -the mailing lists. +linux-mm@kvack.org. Patches should be made against the `mm-unstable tree +`_ whenever possible and posted +to the mailing lists. SCM Trees --------- There are multiple Linux trees for DAMON development. Patches under development or testing are queued in `damon/next -` by the DAMON maintainer. +`_ by the DAMON maintainer. Sufficiently reviewed patches will be queued in `mm-unstable -` by the memory management +`_ by the memory management subsystem maintainer. After more sufficient tests, the patches will be queued -in `mm-stable ` , and finally +in `mm-stable `_, and finally pull-requested to the mainline by the memory management subsystem maintainer. -Note again the patches for mm-unstable `tree -` are queued by the memory +Note again the patches for `mm-unstable tree +`_ are queued by the memory management subsystem maintainer. If the patches requires some patches in -damon/next `tree ` which not yet merged +`damon/next tree `_ which not yet merged in mm-unstable, please make sure the requirement is clearly specified. Submit checklist addendum @@ -37,25 +37,25 @@ When making DAMON changes, you should do below. - Build changes related outputs including kernel and documents. - Ensure the builds introduce no new errors or warnings. - Run and ensure no new failures for DAMON `selftests - ` and + `_ and `kunittests - `. + `_. Further doing below and putting the results will be helpful. - Run `damon-tests/corr - ` for normal + `_ for normal changes. - Run `damon-tests/perf - ` for performance + `_ for performance changes. Key cycle dates --------------- Patches can be sent anytime. Key cycle dates of the `mm-unstable -` and `mm-stable -` trees depend on the memory +`_ and `mm-stable +`_ trees depend on the memory management subsystem maintainer. Review cadence @@ -72,13 +72,13 @@ Mailing tool Like many other Linux kernel subsystems, DAMON uses the mailing lists (damon@lists.linux.dev and linux-mm@kvack.org) as the major communication channel. There is a simple tool called `HacKerMaiL -` (``hkml``), which is for people who +`_ (``hkml``), which is for people who are not very familiar with the mailing lists based communication. The tool could be particularly helpful for DAMON community members since it is developed and maintained by DAMON maintainer. The tool is also officially announced to support DAMON and general Linux kernel development workflow. -In other words, `hkml ` is a mailing +In other words, `hkml `_ is a mailing tool for DAMON community, which DAMON maintainer is committed to support. Please feel free to try and report issues or feature requests for the tool to the maintainer. @@ -98,8 +98,8 @@ slots, and attendees should reserve one of those at least 24 hours before the time slot, by reaching out to the maintainer. Schedules and available reservation time slots are available at the Google `doc -`. +`_. There is also a public Google `calendar -` +`_ that has the events. Anyone can subscribe it. DAMON maintainer will also provide periodic reminder to the mailing list (damon@lists.linux.dev). -- cgit v1.2.3 From f4050ccab716541454d2d33758eab6df1a092f7a Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Fri, 11 Oct 2024 10:01:54 -0700 Subject: Docs/damon/maintainer-profile: update deprecated awslabs GitHub URLs DAMON GitHub repos have moved from awslabs GitHub org to damonitor org[1]. Following the change, URLs on documents are also updated[2]. However, commit 2e9b3d6e2e59 ("Docs/damon/maintainer-profile: add links in place"), which was added just after the update, was using the deprecated GitHub URLs. Update those to use damonitor GitHub URLs instead. [1] https://lore.kernel.org/20240813232158.83903-1-sj@kernel.org [2] https://lore.kernel.org/20240826015741.80707-2-sj@kernel.org Link: https://lkml.kernel.org/r/20241011170154.70651-3-sj@kernel.org Fixes: 2e9b3d6e2e59 ("Docs/damon/maintainer-profile: add links in place") Signed-off-by: SeongJae Park Cc: Jonathan Corbet Signed-off-by: Andrew Morton --- Documentation/mm/damon/maintainer-profile.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst index 7b966480c79e..ce3e98458339 100644 --- a/Documentation/mm/damon/maintainer-profile.rst +++ b/Documentation/mm/damon/maintainer-profile.rst @@ -37,17 +37,17 @@ When making DAMON changes, you should do below. - Build changes related outputs including kernel and documents. - Ensure the builds introduce no new errors or warnings. - Run and ensure no new failures for DAMON `selftests - `_ and + `_ and `kunittests - `_. + `_. Further doing below and putting the results will be helpful. - Run `damon-tests/corr - `_ for normal + `_ for normal changes. - Run `damon-tests/perf - `_ for performance + `_ for performance changes. Key cycle dates -- cgit v1.2.3 From 5ceecb301e50e933c1e621fbeea5ec239fbff858 Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Wed, 25 Sep 2024 23:01:34 +0200 Subject: ipe: also reject policy updates with the same version Currently IPE accepts an update that has the same version as the policy being updated, but it doesn't make it a no-op nor it checks that the old and new policyes are the same. So it is possible to change the content of a policy, without changing its version. This is very confusing from userspace when managing policies. Instead change the update logic to reject updates that have the same version with ESTALE, as that is much clearer and intuitive behaviour. Signed-off-by: Luca Boccassi Reviewed-by: Serge Hallyn Signed-off-by: Fan Wu --- Documentation/admin-guide/LSM/ipe.rst | 2 +- security/ipe/policy.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/LSM/ipe.rst b/Documentation/admin-guide/LSM/ipe.rst index f38e641df0e9..fcb3c493104b 100644 --- a/Documentation/admin-guide/LSM/ipe.rst +++ b/Documentation/admin-guide/LSM/ipe.rst @@ -266,7 +266,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed policy. Two checks will always be performed on this policy: First, the ``policy_names`` must match with the updated version and the existing version. Second the updated policy must have a policy version greater than -or equal to the currently-running version. This is to prevent rollback attacks. +the currently-running version. This is to prevent rollback attacks. The ``delete`` file is used to remove a policy that is no longer needed. This file is write-only and accepts a value of ``1`` to delete the policy. diff --git a/security/ipe/policy.c b/security/ipe/policy.c index dcaac8c4bb38..4cea067adf6a 100644 --- a/security/ipe/policy.c +++ b/security/ipe/policy.c @@ -106,7 +106,7 @@ int ipe_update_policy(struct inode *root, const char *text, size_t textlen, goto err; } - if (ver_to_u64(old) > ver_to_u64(new)) { + if (ver_to_u64(old) >= ver_to_u64(new)) { rc = -ESTALE; goto err; } -- cgit v1.2.3 From 02e2f9aa33e461468de02e35ad977bd7233960ae Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Sun, 15 Sep 2024 11:11:19 +0200 Subject: ipe: allow secondary and platform keyrings to install/update policies The current policy management makes it impossible to use IPE in a general purpose distribution. In such cases the users are not building the kernel, the distribution is, and access to the private key included in the trusted keyring is, for obvious reason, not available. This means that users have no way to enable IPE, since there will be no built-in generic policy, and no access to the key to sign updates validated by the trusted keyring. Just as we do for dm-verity, kernel modules and more, allow the secondary and platform keyrings to also validate policies. This allows users enrolling their own keys in UEFI db or MOK to also sign policies, and enroll them. This makes it sensible to enable IPE in general purpose distributions, as it becomes usable by any user wishing to do so. Keys in these keyrings can already load kernels and kernel modules, so there is no security downgrade. Add a kconfig each, like dm-verity does, but default to enabled if the dependencies are available. Signed-off-by: Luca Boccassi Reviewed-by: Serge Hallyn [FW: fixed some style issues] Signed-off-by: Fan Wu --- Documentation/admin-guide/LSM/ipe.rst | 5 ++++- security/ipe/Kconfig | 19 +++++++++++++++++++ security/ipe/policy.c | 14 +++++++++++++- 3 files changed, 36 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/LSM/ipe.rst b/Documentation/admin-guide/LSM/ipe.rst index fcb3c493104b..f93a467db628 100644 --- a/Documentation/admin-guide/LSM/ipe.rst +++ b/Documentation/admin-guide/LSM/ipe.rst @@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of authorization of the policies (prohibiting an attacker from gaining unconstrained root, and deploying an "allow all" policy). These policies must be signed by a certificate that chains to the -``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by:: +``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if +``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or +``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively. +With openssl, the policy can be signed by:: openssl smime -sign \ -in "$MY_POLICY" \ diff --git a/security/ipe/Kconfig b/security/ipe/Kconfig index 3ab582606ed2..3c75bf267da4 100644 --- a/security/ipe/Kconfig +++ b/security/ipe/Kconfig @@ -31,6 +31,25 @@ config IPE_BOOT_POLICY If unsure, leave blank. +config IPE_POLICY_SIG_SECONDARY_KEYRING + bool "IPE policy update verification with secondary keyring" + default y + depends on SECONDARY_TRUSTED_KEYRING + help + Also allow the secondary trusted keyring to verify IPE policy + updates. + + If unsure, answer Y. + +config IPE_POLICY_SIG_PLATFORM_KEYRING + bool "IPE policy update verification with platform keyring" + default y + depends on INTEGRITY_PLATFORM_KEYRING + help + Also allow the platform keyring to verify IPE policy updates. + + If unsure, answer Y. + menu "IPE Trust Providers" config IPE_PROP_DM_VERITY diff --git a/security/ipe/policy.c b/security/ipe/policy.c index 4cea067adf6a..45f7d6a0ed23 100644 --- a/security/ipe/policy.c +++ b/security/ipe/policy.c @@ -169,9 +169,21 @@ struct ipe_policy *ipe_new_policy(const char *text, size_t textlen, goto err; } - rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len, NULL, + rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len, +#ifdef CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING + VERIFY_USE_SECONDARY_KEYRING, +#else + NULL, +#endif VERIFYING_UNSPECIFIED_SIGNATURE, set_pkcs7_data, new); +#ifdef CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING + if (rc == -ENOKEY) + rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len, + VERIFY_USE_PLATFORM_KEYRING, + VERIFYING_UNSPECIFIED_SIGNATURE, + set_pkcs7_data, new); +#endif if (rc) goto err; } else { -- cgit v1.2.3 From bc07eea2f3b330127242df2e0ec2d6cd16b4f2e8 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Tue, 1 Oct 2024 15:13:54 +0100 Subject: KVM: Remove unused kvm_vcpu_gfn_to_pfn_atomic The last use of kvm_vcpu_gfn_to_pfn_atomic was removed by commit 1bbc60d0c7e5 ("KVM: x86/mmu: Remove MMU auditing") Remove it. Signed-off-by: Dr. David Alan Gilbert Message-ID: <20241001141354.18009-3-linux@treblig.org> [Adjust Documentation/virt/kvm/locking.rst. - Paolo] Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/locking.rst | 2 +- include/linux/kvm_host.h | 1 - virt/kvm/kvm_main.c | 6 ------ 3 files changed, 1 insertion(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 20a9a37d1cdd..1bedd56e2fe3 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -136,7 +136,7 @@ For direct sp, we can easily avoid it since the spte of direct sp is fixed to gfn. For indirect sp, we disabled fast page fault for simplicity. A solution for indirect sp could be to pin the gfn, for example via -kvm_vcpu_gfn_to_pfn_atomic, before the cmpxchg. After the pinning: +gfn_to_pfn_memslot_atomic, before the cmpxchg. After the pinning: - We have held the refcount of pfn; that means the pfn can not be freed and be reused for another gfn. diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index b9b2e42e3fa7..45be36e5285f 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1313,7 +1313,6 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn); struct kvm_memslots *kvm_vcpu_memslots(struct kvm_vcpu *vcpu); struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn); -kvm_pfn_t kvm_vcpu_gfn_to_pfn_atomic(struct kvm_vcpu *vcpu, gfn_t gfn); int kvm_vcpu_map(struct kvm_vcpu *vcpu, gpa_t gpa, struct kvm_host_map *map); void kvm_vcpu_unmap(struct kvm_vcpu *vcpu, struct kvm_host_map *map, bool dirty); unsigned long kvm_vcpu_gfn_to_hva(struct kvm_vcpu *vcpu, gfn_t gfn); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f82131e7978b..141db5b79cd4 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3035,12 +3035,6 @@ kvm_pfn_t gfn_to_pfn_memslot_atomic(const struct kvm_memory_slot *slot, gfn_t gf } EXPORT_SYMBOL_GPL(gfn_to_pfn_memslot_atomic); -kvm_pfn_t kvm_vcpu_gfn_to_pfn_atomic(struct kvm_vcpu *vcpu, gfn_t gfn) -{ - return gfn_to_pfn_memslot_atomic(kvm_vcpu_gfn_to_memslot(vcpu, gfn), gfn); -} -EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_pfn_atomic); - kvm_pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn) { return gfn_to_pfn_memslot(gfn_to_memslot(kvm, gfn), gfn); -- cgit v1.2.3 From 5a279842441b68727d53b6333d0c3af90dd5a2f8 Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Wed, 9 Oct 2024 12:23:45 -0700 Subject: KVM: x86: Clean up documentation for KVM_X86_QUIRK_SLOT_ZAP_ALL Massage the documentation for KVM_X86_QUIRK_SLOT_ZAP_ALL to call out that it applies to moved memslots as well as deleted memslots, to avoid KVM's "fast zap" terminology (which has no meaning for userspace), and to reword the documented targeted zap behavior to specifically say that KVM _may_ zap a subset of all SPTEs. As evidenced by the fix to zap non-leafs SPTEs with gPTEs, formally documenting KVM's exact internal behavior is risky and unnecessary. Signed-off-by: Sean Christopherson Message-ID: <20241009192345.1148353-4-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e32471977d0a..edc070c6e19b 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8098,13 +8098,15 @@ KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS By default, KVM emulates MONITOR/MWAIT (if KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is disabled. -KVM_X86_QUIRK_SLOT_ZAP_ALL By default, KVM invalidates all SPTEs in - fast way for memslot deletion when VM type - is KVM_X86_DEFAULT_VM. - When this quirk is disabled or when VM type - is other than KVM_X86_DEFAULT_VM, KVM zaps - only leaf SPTEs that are within the range of - the memslot being deleted. +KVM_X86_QUIRK_SLOT_ZAP_ALL By default, for KVM_X86_DEFAULT_VM VMs, KVM + invalidates all SPTEs in all memslots and + address spaces when a memslot is deleted or + moved. When this quirk is disabled (or the + VM type isn't KVM_X86_DEFAULT_VM), KVM only + ensures the backing memory of the deleted + or moved memslot isn't reachable, i.e KVM + _may_ invalidate only SPTEs related to the + memslot. =================================== ============================================ 7.32 KVM_CAP_MAX_VCPU_ID -- cgit v1.2.3