* Re: [PATCH 22/22] docs: fix broken documentation links
From: Michael S. Tsirkin @ 2019-05-30 22:49 UTC (permalink / raw)
To: Federico Vaga
Cc: kvm, Linux Doc Mailing List, linux-pci, platform-driver-x86,
linux-mm, linux-i2c, linux-kselftest, devel, x86, linux-acpi,
xen-devel, linux-edac, devicetree, linux-arm-msm, linux-gpio,
linux-amlogic, virtualization, linux-arm-kernel, devel, netdev,
linux-kernel, linux-security-module, linuxppc-dev
In-Reply-To: <1574052.9PXfBvmXpz@harkonnen>
On Thu, May 30, 2019 at 10:17:32PM +0200, Federico Vaga wrote:
> On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote:
> > Mostly due to x86 and acpi conversion, several documentation
> > links are still pointing to the old file. Fix them.
>
> For the Italian documentation I just send I patch to fix them in a dedicated
> patch
Acked-by: Michael S. Tsirkin <mst@redhat.com>
for the vhost change.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/acpi/dsd/leds.txt | 2 +-
> > Documentation/admin-guide/kernel-parameters.rst | 6 +++---
> > Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------
> > Documentation/admin-guide/ras.rst | 2 +-
> > .../devicetree/bindings/net/fsl-enetc.txt | 7 +++----
> > .../bindings/pci/amlogic,meson-pcie.txt | 2 +-
> > .../bindings/regulator/qcom,rpmh-regulator.txt | 2 +-
> > Documentation/devicetree/booting-without-of.txt | 2 +-
> > Documentation/driver-api/gpio/board.rst | 2 +-
> > Documentation/driver-api/gpio/consumer.rst | 2 +-
> > .../firmware-guide/acpi/enumeration.rst | 2 +-
> > .../firmware-guide/acpi/method-tracing.rst | 2 +-
> > Documentation/i2c/instantiating-devices | 2 +-
> > Documentation/sysctl/kernel.txt | 4 ++--
> > .../translations/it_IT/process/howto.rst | 2 +-
> > .../it_IT/process/stable-kernel-rules.rst | 4 ++--
> > .../translations/zh_CN/process/4.Coding.rst | 2 +-
> > Documentation/x86/x86_64/5level-paging.rst | 2 +-
> > Documentation/x86/x86_64/boot-options.rst | 4 ++--
> > .../x86/x86_64/fake-numa-for-cpusets.rst | 2 +-
> > MAINTAINERS | 6 +++---
> > arch/arm/Kconfig | 2 +-
> > arch/arm64/kernel/kexec_image.c | 2 +-
> > arch/powerpc/Kconfig | 2 +-
> > arch/x86/Kconfig | 16 ++++++++--------
> > arch/x86/Kconfig.debug | 2 +-
> > arch/x86/boot/header.S | 2 +-
> > arch/x86/entry/entry_64.S | 2 +-
> > arch/x86/include/asm/bootparam_utils.h | 2 +-
> > arch/x86/include/asm/page_64_types.h | 2 +-
> > arch/x86/include/asm/pgtable_64_types.h | 2 +-
> > arch/x86/kernel/cpu/microcode/amd.c | 2 +-
> > arch/x86/kernel/kexec-bzimage64.c | 2 +-
> > arch/x86/kernel/pci-dma.c | 2 +-
> > arch/x86/mm/tlb.c | 2 +-
> > arch/x86/platform/pvh/enlighten.c | 2 +-
> > drivers/acpi/Kconfig | 10 +++++-----
> > drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
> > .../fieldbus/Documentation/fieldbus_dev.txt | 4 ++--
> > drivers/vhost/vhost.c | 2 +-
> > include/acpi/acpi_drivers.h | 2 +-
> > include/linux/fs_context.h | 2 +-
> > include/linux/lsm_hooks.h | 2 +-
> > mm/Kconfig | 2 +-
> > security/Kconfig | 2 +-
> > tools/include/linux/err.h | 2 +-
> > tools/objtool/Documentation/stack-validation.txt | 4 ++--
> > tools/testing/selftests/x86/protection_keys.c | 2 +-
> > 48 files changed, 77 insertions(+), 78 deletions(-)
> >
> > diff --git a/Documentation/acpi/dsd/leds.txt
> > b/Documentation/acpi/dsd/leds.txt index 81a63af42ed2..cc58b1a574c5 100644
> > --- a/Documentation/acpi/dsd/leds.txt
> > +++ b/Documentation/acpi/dsd/leds.txt
> > @@ -96,4 +96,4 @@ where
> >
> > <URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-da
> > ta-extension-UUID-v1.1.pdf>, referenced 2019-02-21.
> >
> > -[7] Documentation/acpi/dsd/data-node-reference.txt
> > +[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > diff --git a/Documentation/admin-guide/kernel-parameters.rst
> > b/Documentation/admin-guide/kernel-parameters.rst index
> > 0124980dca2d..8d3273e32eb1 100644
> > --- a/Documentation/admin-guide/kernel-parameters.rst
> > +++ b/Documentation/admin-guide/kernel-parameters.rst
> > @@ -167,7 +167,7 @@ parameter is applicable::
> > X86-32 X86-32, aka i386 architecture is enabled.
> > X86-64 X86-64 architecture is enabled.
> > More X86-64 boot options can be found in
> > - Documentation/x86/x86_64/boot-options.txt
> .
> > + Documentation/x86/x86_64/boot-options.rst.
> > 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
> > @@ -181,10 +181,10 @@ In addition, the following text indicates that the
> > option:: Parameters denoted with BOOT are actually interpreted by the boot
> > loader, and have no meaning to the kernel directly.
> > Do not modify the syntax of boot loader parameters without extreme
> > -need or coordination with <Documentation/x86/boot.txt>.
> > +need or coordination with <Documentation/x86/boot.rst>.
> >
> > There are also arch-specific kernel-parameters not documented here.
> > -See for example <Documentation/x86/x86_64/boot-options.txt>.
> > +See for example <Documentation/x86/x86_64/boot-options.rst>.
> >
> > Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
> > a trailing = on the name of any parameter states that that parameter will
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt index
> > 138f6664b2e2..4a02d1346635 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -53,7 +53,7 @@
> > ACPI_DEBUG_PRINT statements, e.g.,
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
> > The debug_level mask defaults to "info".
> See
> > - Documentation/acpi/debug.txt for more
> information about
> > + Documentation/firmware-guide/acpi/debug.rst
> for more information about
> > debug layers and levels.
> >
> > Enable processor driver info messages:
> > @@ -963,7 +963,7 @@
> > for details.
> >
> > nompx [X86] Disables Intel Memory Protection
> Extensions.
> > - See Documentation/x86/intel_mpx.txt for
> more
> > + See Documentation/x86/intel_mpx.rst for
> more
> > information about the feature.
> >
> > nopku [X86] Disable Memory Protection Keys CPU
> feature found
> > @@ -1189,7 +1189,7 @@
> > that is to be dynamically loaded by Linux.
> If there are
> > multiple variables with the same name but
> with different
> > vendor GUIDs, all of them will be loaded.
> See
> > - Documentation/acpi/ssdt-overlays.txt for
> details.
> > + Documentation/admin-guide/acpi/ssdt-
> overlays.rst for details.
> >
> >
> > eisa_irq_edge= [PARISC,HW]
> > @@ -2383,7 +2383,7 @@
> >
> > mce [X86-32] Machine Check Exception
> >
> > - mce=option [X86-64] See Documentation/x86/x86_64/boot-
> options.txt
> > + mce=option [X86-64] See Documentation/x86/x86_64/boot-
> options.rst
> >
> > md= [HW] RAID subsystems devices and level
> > See Documentation/admin-guide/md.rst.
> > @@ -2439,7 +2439,7 @@
> > set according to the
> > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
> kernel config
> > option.
> > - See Documentation/memory-hotplug.txt.
> > + See Documentation/admin-guide/mm/memory-
> hotplug.rst.
> >
> > memmap=exactmap [KNL,X86] Enable setting of an exact
> > E820 memory map, as specified by the user.
> > @@ -2528,7 +2528,7 @@
> > mem_encrypt=on: Activate
> SME
> > mem_encrypt=off: Do not activate SME
> >
> > - Refer to Documentation/x86/amd-memory-
> encryption.txt
> > + Refer to Documentation/virtual/kvm/amd-
> memory-encryption.rst
> > for details on when memory encryption can
> be activated.
> >
> > mem_sleep_default= [SUSPEND] Default system suspend mode:
> > @@ -3528,7 +3528,7 @@
> > See Documentation/blockdev/paride.txt.
> >
> > pirq= [SMP,APIC] Manual mp-table setup
> > - See Documentation/x86/i386/IO-APIC.txt.
> > + See Documentation/x86/i386/IO-APIC.rst.
> >
> > plip= [PPT,NET] Parallel port network link
> > Format: { parport<nr> | timid | 0 }
> > @@ -5054,7 +5054,7 @@
> > Can be used multiple times for multiple
> devices.
> >
> > vga= [BOOT,X86-32] Select a particular video
> mode
> > - See Documentation/x86/boot.txt and
> > + See Documentation/x86/boot.rst and
> > Documentation/svga.txt.
> > Use vga=ask for menu.
> > This is actually a boot loader parameter;
> the value is
> > diff --git a/Documentation/admin-guide/ras.rst
> > b/Documentation/admin-guide/ras.rst index c7495e42e6f4..2b20f5f7380d 100644
> > --- a/Documentation/admin-guide/ras.rst
> > +++ b/Documentation/admin-guide/ras.rst
> > @@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_.
> > mode).
> >
> > .. [#f3] For more details about the Machine Check Architecture (MCA),
> > - please read Documentation/x86/x86_64/machinecheck at the Kernel tree.
> > + please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree.
> >
> > EDAC - Error Detection And Correction
> > *************************************
> > diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt
> > b/Documentation/devicetree/bindings/net/fsl-enetc.txt index
> > c812e25ae90f..25fc687419db 100644
> > --- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
> > +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
> > @@ -16,8 +16,8 @@ Required properties:
> > In this case, the ENETC node should include a "mdio" sub-node
> > that in turn should contain the "ethernet-phy" node describing the
> > external phy. Below properties are required, their bindings
> > -already defined in ethernet.txt or phy.txt, under
> > -Documentation/devicetree/bindings/net/*.
> > +already defined in Documentation/devicetree/bindings/net/ethernet.txt or
> > +Documentation/devicetree/bindings/net/phy.txt.
> >
> > Required:
> >
> > @@ -51,8 +51,7 @@ Example:
> > connection:
> >
> > In this case, the ENETC port node defines a fixed link connection,
> > -as specified by "fixed-link.txt", under
> > -Documentation/devicetree/bindings/net/*.
> > +as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
> >
> > Required:
> >
> > diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> > b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt index
> > 12b18f82d441..efa2c8b9b85a 100644
> > --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> > @@ -3,7 +3,7 @@ Amlogic Meson AXG DWC PCIE SoC controller
> > Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI
> > core. It shares common functions with the PCIe DesignWare core driver and
> > inherits common properties defined in
> > -Documentation/devicetree/bindings/pci/designware-pci.txt.
> > +Documentation/devicetree/bindings/pci/designware-pcie.txt.
> >
> > Additional properties are described here:
> >
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt index
> > 7ef2dbe48e8a..14d2eee96b3d 100644
> > --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> > @@ -97,7 +97,7 @@ Second Level Nodes - Regulators
> > sent for this regulator including those which are
> for a
> > strictly lower power state.
> >
> > -Other properties defined in Documentation/devicetree/bindings/regulator.txt
> > +Other properties defined in
> > Documentation/devicetree/bindings/regulator/regulator.txt may also be used.
> > regulator-initial-mode and regulator-allowed-modes may be specified for
> > VRM regulators using mode values from
> > include/dt-bindings/regulator/qcom,rpmh-regulator.h.
> > regulator-allow-bypass diff --git
> > a/Documentation/devicetree/booting-without-of.txt
> > b/Documentation/devicetree/booting-without-of.txt index
> > e86bd2f64117..60f8640f2b2f 100644
> > --- a/Documentation/devicetree/booting-without-of.txt
> > +++ b/Documentation/devicetree/booting-without-of.txt
> > @@ -277,7 +277,7 @@ it with special cases.
> > the decompressor (the real mode entry point goes to the same 32bit
> > entry point once it switched into protected mode). That entry point
> > supports one calling convention which is documented in
> > - Documentation/x86/boot.txt
> > + Documentation/x86/boot.rst
> > The physical pointer to the device-tree block (defined in chapter II)
> > is passed via setup_data which requires at least boot protocol 2.09.
> > The type filed is defined as
> > diff --git a/Documentation/driver-api/gpio/board.rst
> > b/Documentation/driver-api/gpio/board.rst index b37f3f7b8926..ce91518bf9f4
> > 100644
> > --- a/Documentation/driver-api/gpio/board.rst
> > +++ b/Documentation/driver-api/gpio/board.rst
> > @@ -101,7 +101,7 @@ with the help of _DSD (Device Specific Data), introduced
> > in ACPI 5.1:: }
> >
> > For more information about the ACPI GPIO bindings see
> > -Documentation/acpi/gpio-properties.txt.
> > +Documentation/firmware-guide/acpi/gpio-properties.rst.
> >
> > Platform Data
> > -------------
> > diff --git a/Documentation/driver-api/gpio/consumer.rst
> > b/Documentation/driver-api/gpio/consumer.rst index
> > 5e4d8aa68913..fdecb6d711db 100644
> > --- a/Documentation/driver-api/gpio/consumer.rst
> > +++ b/Documentation/driver-api/gpio/consumer.rst
> > @@ -437,7 +437,7 @@ case, it will be handled by the GPIO subsystem
> > automatically. However, if the _DSD is not present, the mappings between
> > GpioIo()/GpioInt() resources and GPIO connection IDs need to be provided by
> > device drivers.
> >
> > -For details refer to Documentation/acpi/gpio-properties.txt
> > +For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst
> >
> >
> > Interacting With the Legacy GPIO Subsystem
> > diff --git a/Documentation/firmware-guide/acpi/enumeration.rst
> > b/Documentation/firmware-guide/acpi/enumeration.rst index
> > 850be9696931..1252617b520f 100644
> > --- a/Documentation/firmware-guide/acpi/enumeration.rst
> > +++ b/Documentation/firmware-guide/acpi/enumeration.rst
> > @@ -339,7 +339,7 @@ a code like this::
> > There are also devm_* versions of these functions which release the
> > descriptors once the device is released.
> >
> > -See Documentation/acpi/gpio-properties.txt for more information about the
> > +See Documentation/firmware-guide/acpi/gpio-properties.rst for more
> > information about the _DSD binding related to GPIOs.
> >
> > MFD devices
> > diff --git a/Documentation/firmware-guide/acpi/method-tracing.rst
> > b/Documentation/firmware-guide/acpi/method-tracing.rst index
> > d0b077b73f5f..0aa7e2c5d32a 100644
> > --- a/Documentation/firmware-guide/acpi/method-tracing.rst
> > +++ b/Documentation/firmware-guide/acpi/method-tracing.rst
> > @@ -68,7 +68,7 @@ c. Filter out the debug layer/level matched logs when the
> > specified
> >
> > Where:
> > 0xXXXXXXXX/0xYYYYYYYY
> > - Refer to Documentation/acpi/debug.txt for possible debug layer/level
> > + Refer to Documentation/firmware-guide/acpi/debug.rst for possible
> > debug layer/level masking values.
> > \PPPP.AAAA.TTTT.HHHH
> > Full path of a control method that can be found in the ACPI namespace.
> > diff --git a/Documentation/i2c/instantiating-devices
> > b/Documentation/i2c/instantiating-devices index 0d85ac1935b7..5a3e2f331e8c
> > 100644
> > --- a/Documentation/i2c/instantiating-devices
> > +++ b/Documentation/i2c/instantiating-devices
> > @@ -85,7 +85,7 @@ Method 1c: Declare the I2C devices via ACPI
> > -------------------------------------------
> >
> > ACPI can also describe I2C devices. There is special documentation for this
> > -which is currently located at Documentation/acpi/enumeration.txt. +which
> > is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
> >
> >
> > Method 2: Instantiate the devices explicitly
> > diff --git a/Documentation/sysctl/kernel.txt
> > b/Documentation/sysctl/kernel.txt index f0c86fbb3b48..92f7f34b021a 100644
> > --- a/Documentation/sysctl/kernel.txt
> > +++ b/Documentation/sysctl/kernel.txt
> > @@ -155,7 +155,7 @@ is 0x15 and the full version number is 0x234, this file
> > will contain the value 340 = 0x154.
> >
> > See the type_of_loader and ext_loader_type fields in
> > -Documentation/x86/boot.txt for additional information.
> > +Documentation/x86/boot.rst for additional information.
> >
> > ==============================================================
> >
> > @@ -167,7 +167,7 @@ The complete bootloader version number. In the example
> > above, this file will contain the value 564 = 0x234.
> >
> > See the type_of_loader and ext_loader_ver fields in
> > -Documentation/x86/boot.txt for additional information.
> > +Documentation/x86/boot.rst for additional information.
> >
> > ==============================================================
> >
> > diff --git a/Documentation/translations/it_IT/process/howto.rst
> > b/Documentation/translations/it_IT/process/howto.rst index
> > 9903ac7c566b..44e6077730e8 100644
> > --- a/Documentation/translations/it_IT/process/howto.rst
> > +++ b/Documentation/translations/it_IT/process/howto.rst
> > @@ -131,7 +131,7 @@ Di seguito una lista di file che sono presenti nei
> > sorgente del kernel e che "Linux kernel patch submission format"
> > http://linux.yyz.us/patch-format.html
> >
> > - :ref:`Documentation/process/translations/it_IT/stable-api-nonsense.rst
> > <it_stable_api_nonsense>` +
> > :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst
> > <it_stable_api_nonsense>`
> >
> > Questo file descrive la motivazioni sottostanti la conscia decisione di
> > non avere un API stabile all'interno del kernel, incluso cose come: diff
> > --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> > b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index
> > 48e88e5ad2c5..4f206cee31a7 100644
> > --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> > +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> > @@ -33,7 +33,7 @@ Regole sul tipo di patch che vengono o non vengono
> > accettate nei sorgenti - Non deve includere alcuna correzione "banale"
> > (correzioni grammaticali, pulizia dagli spazi bianchi, eccetera).
> > - Deve rispettare le regole scritte in
> > - :ref:`Documentation/translation/it_IT/process/submitting-patches.rst
> > <it_submittingpatches>` +
> > :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
> > <it_submittingpatches>` - Questa patch o una equivalente deve esistere già
> > nei sorgenti principali di Linux
> >
> > @@ -43,7 +43,7 @@ Procedura per sottomettere patch per i sorgenti -stable
> >
> > - Se la patch contiene modifiche a dei file nelle cartelle net/ o
> > drivers/net, allora seguite le linee guida descritte in
> > - :ref:`Documentation/translation/it_IT/networking/netdev-FAQ.rst
> > <it_netdev-FAQ>`; +
> > :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst
> > <it_netdev-FAQ>`; ma solo dopo aver verificato al seguente indirizzo che la
> > patch non sia già in coda:
> >
> > https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=
> > *&q=&archive= diff --git
> > a/Documentation/translations/zh_CN/process/4.Coding.rst
> > b/Documentation/translations/zh_CN/process/4.Coding.rst index
> > 5301e9d55255..8bb777941394 100644
> > --- a/Documentation/translations/zh_CN/process/4.Coding.rst
> > +++ b/Documentation/translations/zh_CN/process/4.Coding.rst
> > @@ -241,7 +241,7 @@ scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”
> >
> > 任何添加新用户空间界面的代码（包括新的sysfs或/proc文件）都应该包含该界面的
> > 文档，该文档使用户空间开发人员能够知道他们在使用什么。请参阅
> > -Documentation/abi/readme，了解如何格式化此文档以及需要提供哪些信息。
> > +Documentation/ABI/README，了解如何格式化此文档以及需要提供哪些信息。
> >
> > 文件 :ref:`Documentation/admin-guide/kernel-parameters.rst
> > <kernelparameters>` 描述了内核的所有引导时间参数。任何添加新参数的补丁都应该向该文件添加适当的
> > diff --git a/Documentation/x86/x86_64/5level-paging.rst
> > b/Documentation/x86/x86_64/5level-paging.rst index
> > ab88a4514163..44856417e6a5 100644
> > --- a/Documentation/x86/x86_64/5level-paging.rst
> > +++ b/Documentation/x86/x86_64/5level-paging.rst
> > @@ -20,7 +20,7 @@ physical address space. This "ought to be enough for
> > anybody" ©. QEMU 2.9 and later support 5-level paging.
> >
> > Virtual memory layout for 5-level paging is described in
> > -Documentation/x86/x86_64/mm.txt
> > +Documentation/x86/x86_64/mm.rst
> >
> >
> > Enabling 5-level paging
> > diff --git a/Documentation/x86/x86_64/boot-options.rst
> > b/Documentation/x86/x86_64/boot-options.rst index
> > 2f69836b8445..6a4285a3c7a4 100644
> > --- a/Documentation/x86/x86_64/boot-options.rst
> > +++ b/Documentation/x86/x86_64/boot-options.rst
> > @@ -9,7 +9,7 @@ only the AMD64 specific ones are listed here.
> >
> > Machine check
> > =============
> > -Please see Documentation/x86/x86_64/machinecheck for sysfs runtime
> > tunables. +Please see Documentation/x86/x86_64/machinecheck.rst for sysfs
> > runtime tunables.
> >
> > mce=off
> > Disable machine check
> > @@ -89,7 +89,7 @@ APICs
> > Don't use the local APIC (alias for i386 compatibility)
> >
> > pirq=...
> > - See Documentation/x86/i386/IO-APIC.txt
> > + See Documentation/x86/i386/IO-APIC.rst
> >
> > noapictimer
> > Don't set up the APIC timer
> > diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> > b/Documentation/x86/x86_64/fake-numa-for-cpusets.rst index
> > 74fbb78b3c67..04df57b9aa3f 100644
> > --- a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> > +++ b/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> > @@ -18,7 +18,7 @@ For more information on the features of cpusets, see
> > Documentation/cgroup-v1/cpusets.txt.
> > There are a number of different configurations you can use for your needs.
> > For more information on the numa=fake command line option and its various
> > ways of -configuring fake nodes, see
> > Documentation/x86/x86_64/boot-options.txt. +configuring fake nodes, see
> > Documentation/x86/x86_64/boot-options.rst.
> >
> > For the purposes of this introduction, we'll assume a very primitive NUMA
> > emulation setup of "numa=fake=4*512,". This will split our system memory
> > into diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5cfbea4ce575..a38d7273705a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3874,7 +3874,7 @@
> > F: Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt
> > F: Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt
> > F: Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt
> > F: Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt
> > -F: Documentation/hwmon/lochnagar
> > +F: Documentation/hwmon/lochnagar.rst
> >
> > CISCO FCOE HBA DRIVER
> > M: Satish Kharat <satishkh@cisco.com>
> > @@ -11272,7 +11272,7 @@ NXP FXAS21002C DRIVER
> > M: Rui Miguel Silva <rmfrfs@gmail.com>
> > L: linux-iio@vger.kernel.org
> > S: Maintained
> > -F: Documentation/devicetree/bindings/iio/gyroscope/fxas21002c.txt
> > +F: Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt
> > F: drivers/iio/gyro/fxas21002c_core.c
> > F: drivers/iio/gyro/fxas21002c.h
> > F: drivers/iio/gyro/fxas21002c_i2c.c
> > @@ -13043,7 +13043,7 @@ M: Niklas Cassel <niklas.cassel@linaro.org>
> > L: netdev@vger.kernel.org
> > S: Maintained
> > F: drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > -F: Documentation/devicetree/bindings/net/qcom,dwmac.txt
> > +F: Documentation/devicetree/bindings/net/qcom,ethqos.txt
> >
> > QUALCOMM GENERIC INTERFACE I2C DRIVER
> > M: Alok Chauhan <alokc@codeaurora.org>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 8869742a85df..0f220264cc23 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1263,7 +1263,7 @@ config SMP
> > uniprocessor machines. On a uniprocessor machine, the kernel
> > will run faster if you say N here.
> >
> > - See also <file:Documentation/x86/i386/IO-APIC.txt>,
> > + See also <file:Documentation/x86/i386/IO-APIC.rst>,
> > <file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO
> available at
> > <http://tldp.org/HOWTO/SMP-HOWTO.html>.
> >
> > diff --git a/arch/arm64/kernel/kexec_image.c
> > b/arch/arm64/kernel/kexec_image.c index 07bf740bea91..31cc2f423aa8 100644
> > --- a/arch/arm64/kernel/kexec_image.c
> > +++ b/arch/arm64/kernel/kexec_image.c
> > @@ -53,7 +53,7 @@ static void *image_load(struct kimage *image,
> >
> > /*
> > * We require a kernel with an unambiguous Image header. Per
> > - * Documentation/booting.txt, this is the case when image_size
> > + * Documentation/arm64/booting.txt, this is the case when
> image_size
> > * is non-zero (practically speaking, since v3.17).
> > */
> > h = (struct arm64_image_header *)kernel;
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 8c1c636308c8..e868d2bd48b8 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -898,7 +898,7 @@ config PPC_MEM_KEYS
> > page-based protections, but without requiring modification of
> the
> > page tables when an application changes protection domains.
> >
> > - For details, see Documentation/vm/protection-keys.rst
> > + For details, see Documentation/x86/protection-keys.rst
> >
> > If unsure, say y.
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 2bbbd4d1ba31..78fdf2dd71d1 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -395,7 +395,7 @@ config SMP
> > Y to "Enhanced Real Time Clock Support", below. The "Advanced
> Power
> > Management" code will be disabled if you say Y here.
> >
> > - See also <file:Documentation/x86/i386/IO-APIC.txt>,
> > + See also <file:Documentation/x86/i386/IO-APIC.rst>,
> > <file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO
> available at
> > <http://www.tldp.org/docs.html#howto>.
> >
> > @@ -1290,7 +1290,7 @@ config MICROCODE
> > the Linux kernel.
> >
> > The preferred method to load microcode from a detached initrd is
> > described - in Documentation/x86/microcode.txt. For that you
> need to
> > enable + in Documentation/x86/microcode.rst. For that you need to enable
> > CONFIG_BLK_DEV_INITRD in order for the loader to be able to scan the initrd
> > for microcode blobs.
> >
> > @@ -1329,7 +1329,7 @@ config MICROCODE_OLD_INTERFACE
> > It is inadequate because it runs too late to be able to properly
> > load microcode on a machine and it needs special tools. Instead,
> you
> > should've switched to the early loading method with the initrd
> or
> > - builtin microcode by now: Documentation/x86/microcode.txt
> > + builtin microcode by now: Documentation/x86/microcode.rst
> >
> > config X86_MSR
> > tristate "/dev/cpu/*/msr - Model-specific register support"
> > @@ -1478,7 +1478,7 @@ config X86_5LEVEL
> > A kernel with the option enabled can be booted on machines that
> > support 4- or 5-level paging.
> >
> > - See Documentation/x86/x86_64/5level-paging.txt for more
> > + See Documentation/x86/x86_64/5level-paging.rst for more
> > information.
> >
> > Say N if unsure.
> > @@ -1626,7 +1626,7 @@ config ARCH_MEMORY_PROBE
> > depends on X86_64 && MEMORY_HOTPLUG
> > help
> > This option enables a sysfs memory/probe interface for testing.
> > - See Documentation/memory-hotplug.txt for more information.
> > + See Documentation/admin-guide/mm/memory-hotplug.rst for more
> > information. If you are unsure how to answer this question, answer N.
> >
> > config ARCH_PROC_KCORE_TEXT
> > @@ -1783,7 +1783,7 @@ config MTRR
> > You can safely say Y even if your machine doesn't have MTRRs,
> you'll
> > just add about 9 KB to your kernel.
> >
> > - See <file:Documentation/x86/mtrr.txt> for more information.
> > + See <file:Documentation/x86/mtrr.rst> for more information.
> >
> > config MTRR_SANITIZER
> > def_bool y
> > @@ -1895,7 +1895,7 @@ config X86_INTEL_MPX
> > process and adds some branches to paths used during
> > exec() and munmap().
> >
> > - For details, see Documentation/x86/intel_mpx.txt
> > + For details, see Documentation/x86/intel_mpx.rst
> >
> > If unsure, say N.
> >
> > @@ -1911,7 +1911,7 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
> > page-based protections, but without requiring modification of
> the
> > page tables when an application changes protection domains.
> >
> > - For details, see Documentation/x86/protection-keys.txt
> > + For details, see Documentation/x86/protection-keys.rst
> >
> > If unsure, say y.
> >
> > diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> > index f730680dc818..59f598543203 100644
> > --- a/arch/x86/Kconfig.debug
> > +++ b/arch/x86/Kconfig.debug
> > @@ -156,7 +156,7 @@ config IOMMU_DEBUG
> > code. When you use it make sure you have a big enough
> > IOMMU/AGP aperture. Most of the options enabled by this can
> > be set more finegrained using the iommu= command line
> > - options. See Documentation/x86/x86_64/boot-options.txt for more
> > + options. See Documentation/x86/x86_64/boot-options.rst for more
> > details.
> >
> > config IOMMU_LEAK
> > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> > index 850b8762e889..90d791ca1a95 100644
> > --- a/arch/x86/boot/header.S
> > +++ b/arch/x86/boot/header.S
> > @@ -313,7 +313,7 @@ start_sys_seg: .word SYSSEG
> # obsolete and meaningless,
> > but just
> >
> > type_of_loader: .byte 0 # 0 means ancient
> bootloader, newer
> > # bootloaders know
> to change this.
> > - # See
> Documentation/x86/boot.txt for
> > + # See
> Documentation/x86/boot.rst for
> > # assigned ids
> >
> > # flags, unused bits must be zero (RFU) bit within loadflags
> > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > index 11aa3b2afa4d..33f9fc38d014 100644
> > --- a/arch/x86/entry/entry_64.S
> > +++ b/arch/x86/entry/entry_64.S
> > @@ -8,7 +8,7 @@
> > *
> > * entry.S contains the system-call and fault low-level handling routines.
> > *
> > - * Some of this is documented in Documentation/x86/entry_64.txt
> > + * Some of this is documented in Documentation/x86/entry_64.rst
> > *
> > * A note on terminology:
> > * - iret frame: Architecture defined interrupt frame from SS to RIP
> > diff --git a/arch/x86/include/asm/bootparam_utils.h
> > b/arch/x86/include/asm/bootparam_utils.h index f6f6ef436599..101eb944f13c
> > 100644
> > --- a/arch/x86/include/asm/bootparam_utils.h
> > +++ b/arch/x86/include/asm/bootparam_utils.h
> > @@ -24,7 +24,7 @@ static void sanitize_boot_params(struct boot_params
> > *boot_params) * IMPORTANT NOTE TO BOOTLOADER AUTHORS: do not simply clear
> > * this field. The purpose of this field is to guarantee
> > * compliance with the x86 boot spec located in
> > - * Documentation/x86/boot.txt . That spec says that the
> > + * Documentation/x86/boot.rst . That spec says that the
> > * *whole* structure should be cleared, after which only the
> > * portion defined by struct setup_header (boot_params->hdr)
> > * should be copied in.
> > diff --git a/arch/x86/include/asm/page_64_types.h
> > b/arch/x86/include/asm/page_64_types.h index 793c14c372cb..288b065955b7
> > 100644
> > --- a/arch/x86/include/asm/page_64_types.h
> > +++ b/arch/x86/include/asm/page_64_types.h
> > @@ -48,7 +48,7 @@
> >
> > #define __START_KERNEL_map _AC(0xffffffff80000000, UL)
> >
> > -/* See Documentation/x86/x86_64/mm.txt for a description of the memory map.
> > */ +/* See Documentation/x86/x86_64/mm.rst for a description of the memory
> > map. */
> >
> > #define __PHYSICAL_MASK_SHIFT 52
> >
> > diff --git a/arch/x86/include/asm/pgtable_64_types.h
> > b/arch/x86/include/asm/pgtable_64_types.h index 88bca456da99..52e5f5f2240d
> > 100644
> > --- a/arch/x86/include/asm/pgtable_64_types.h
> > +++ b/arch/x86/include/asm/pgtable_64_types.h
> > @@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d;
> > #define PGDIR_MASK (~(PGDIR_SIZE - 1))
> >
> > /*
> > - * See Documentation/x86/x86_64/mm.txt for a description of the memory map.
> > + * See Documentation/x86/x86_64/mm.rst for a description of the memory
> > map. *
> > * Be very careful vs. KASLR when changing anything here. The KASLR address
> > * range must not overlap with anything except the KASAN shadow area, which
> > diff --git a/arch/x86/kernel/cpu/microcode/amd.c
> > b/arch/x86/kernel/cpu/microcode/amd.c index e1f3ba19ba54..06d4e67f31ab
> > 100644
> > --- a/arch/x86/kernel/cpu/microcode/amd.c
> > +++ b/arch/x86/kernel/cpu/microcode/amd.c
> > @@ -61,7 +61,7 @@ static u8 amd_ucode_patch[PATCH_MAX_SIZE];
> >
> > /*
> > * Microcode patch container file is prepended to the initrd in cpio
> > - * format. See Documentation/x86/microcode.txt
> > + * format. See Documentation/x86/microcode.rst
> > */
> > static const char
> > ucode_path[] __maybe_unused = "kernel/x86/microcode/AuthenticAMD.bin";
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > b/arch/x86/kernel/kexec-bzimage64.c index 22f60dd26460..b07e7069b09e 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -416,7 +416,7 @@ static void *bzImage64_load(struct kimage *image, char
> > *kernel, efi_map_offset = params_cmdline_sz;
> > efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
> >
> > - /* Copy setup header onto bootparams. Documentation/x86/boot.txt
> */
> > + /* Copy setup header onto bootparams. Documentation/x86/boot.rst */
> > setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;
> >
> > /* Is there a limit on setup header size? */
> > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> > index dcd272dbd0a9..f62b498b18fb 100644
> > --- a/arch/x86/kernel/pci-dma.c
> > +++ b/arch/x86/kernel/pci-dma.c
> > @@ -70,7 +70,7 @@ void __init pci_iommu_alloc(void)
> > }
> >
> > /*
> > - * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
> > + * See <Documentation/x86/x86_64/boot-options.rst> for the iommu kernel
> > * parameter documentation.
> > */
> > static __init int iommu_setup(char *p)
> > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> > index 7f61431c75fb..400c1ba033aa 100644
> > --- a/arch/x86/mm/tlb.c
> > +++ b/arch/x86/mm/tlb.c
> > @@ -711,7 +711,7 @@ void native_flush_tlb_others(const struct cpumask
> > *cpumask, }
> >
> > /*
> > - * See Documentation/x86/tlb.txt for details. We choose 33
> > + * See Documentation/x86/tlb.rst for details. We choose 33
> > * because it is large enough to cover the vast majority (at
> > * least 95%) of allocations, and is small enough that we are
> > * confident it will not cause too much overhead. Each single
> > diff --git a/arch/x86/platform/pvh/enlighten.c
> > b/arch/x86/platform/pvh/enlighten.c index 1861a2ba0f2b..c0a502f7e3a7 100644
> > --- a/arch/x86/platform/pvh/enlighten.c
> > +++ b/arch/x86/platform/pvh/enlighten.c
> > @@ -86,7 +86,7 @@ static void __init init_pvh_bootparams(bool xen_guest)
> > }
> >
> > /*
> > - * See Documentation/x86/boot.txt.
> > + * See Documentation/x86/boot.rst.
> > *
> > * Version 2.12 supports Xen entry point but we will use default
> x86/PC
> > * environment (i.e. hardware_subarch 0).
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index 283ee94224c6..2438f37f2ca1 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -333,7 +333,7 @@ config ACPI_CUSTOM_DSDT_FILE
> > depends on !STANDALONE
> > help
> > This option supports a custom DSDT by linking it into the
> kernel.
> > - See Documentation/acpi/dsdt-override.txt
> > + See Documentation/admin-guide/acpi/dsdt-override.rst
> >
> > Enter the full path name to the file which includes the AmlCode
> > or dsdt_aml_code declaration.
> > @@ -355,7 +355,7 @@ config ACPI_TABLE_UPGRADE
> > This option provides functionality to upgrade arbitrary ACPI
> tables
> > via initrd. No functional change if no ACPI tables are passed
> via
> > initrd, therefore it's safe to say Y.
> > - See Documentation/acpi/initrd_table_override.txt for details
> > + See Documentation/admin-guide/acpi/initrd_table_override.rst for
> details
> >
> > config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
> > bool "Override ACPI tables from built-in initrd"
> > @@ -365,7 +365,7 @@ config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
> > This option provides functionality to override arbitrary ACPI
> tables
> > from built-in uncompressed initrd.
> >
> > - See Documentation/acpi/initrd_table_override.txt for details
> > + See Documentation/admin-guide/acpi/initrd_table_override.rst for
> details
> >
> > config ACPI_DEBUG
> > bool "Debug Statements"
> > @@ -374,7 +374,7 @@ config ACPI_DEBUG
> > output and increases the kernel size by around 50K.
> >
> > Use the acpi.debug_layer and acpi.debug_level kernel command-
> line
> > - parameters documented in Documentation/acpi/debug.txt and
> > + parameters documented in Documentation/firmware-guide/acpi/
> debug.rst and
> > Documentation/admin-guide/kernel-parameters.rst to control the type and
> > amount of debug output.
> >
> > @@ -445,7 +445,7 @@ config ACPI_CUSTOM_METHOD
> > help
> > This debug facility allows ACPI AML methods to be inserted and/
> or
> > replaced without rebooting the system. For details refer to:
> > - Documentation/acpi/method-customizing.txt.
> > + Documentation/firmware-guide/acpi/method-customizing.rst.
> >
> > NOTE: This option is security sensitive, because it allows
> arbitrary
> > kernel memory to be written to by root (uid=0) users, allowing
> them
> > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> > b/drivers/net/ethernet/faraday/ftgmac100.c index b17b79e612a3..ac6280ad43a1
> > 100644
> > --- a/drivers/net/ethernet/faraday/ftgmac100.c
> > +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> > @@ -1075,7 +1075,7 @@ static int ftgmac100_mii_probe(struct ftgmac100 *priv,
> > phy_interface_t intf) }
> >
> > /* Indicate that we support PAUSE frames (see comment in
> > - * Documentation/networking/phy.txt)
> > + * Documentation/networking/phy.rst)
> > */
> > phy_support_asym_pause(phydev);
> >
> > diff --git a/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> > b/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt index
> > 56af3f650fa3..89fb8e14676f 100644
> > --- a/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> > +++ b/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> > @@ -54,8 +54,8 @@ a limited few common behaviours and properties. This
> > allows us to define a simple interface consisting of a character device and
> > a set of sysfs files:
> >
> > See:
> > -Documentation/ABI/testing/sysfs-class-fieldbus-dev
> > -Documentation/ABI/testing/fieldbus-dev-cdev
> > +drivers/staging/fieldbus/Documentation/ABI/sysfs-class-fieldbus-dev
> > +drivers/staging/fieldbus/Documentation/ABI/fieldbus-dev-cdev
> >
> > Note that this simple interface does not provide a way to modify adapter
> > configuration settings. It is therefore useful only for adapters that get
> > their diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 1e3ed41ae1f3..69938dbae2d0 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -1694,7 +1694,7 @@ EXPORT_SYMBOL_GPL(vhost_dev_ioctl);
> >
> > /* TODO: This is really inefficient. We need something like get_user()
> > * (instruction directly accesses the data, with an exception table entry
> > - * returning -EFAULT). See Documentation/x86/exception-tables.txt.
> > + * returning -EFAULT). See Documentation/x86/exception-tables.rst.
> > */
> > static int set_bit_to_user(int nr, void __user *addr)
> > {
> > diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> > index de1804aeaf69..98e3db7a89cd 100644
> > --- a/include/acpi/acpi_drivers.h
> > +++ b/include/acpi/acpi_drivers.h
> > @@ -25,7 +25,7 @@
> > #define ACPI_MAX_STRING 80
> >
> > /*
> > - * Please update drivers/acpi/debug.c and Documentation/acpi/debug.txt
> > + * Please update drivers/acpi/debug.c and
> > Documentation/firmware-guide/acpi/debug.rst * if you add to this list.
> > */
> > #define ACPI_BUS_COMPONENT 0x00010000
> > diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> > index 1f966670c8dc..623eb58560b9 100644
> > --- a/include/linux/fs_context.h
> > +++ b/include/linux/fs_context.h
> > @@ -85,7 +85,7 @@ struct fs_parameter {
> > * Superblock creation fills in ->root whereas reconfiguration begins with
> > this * already set.
> > *
> > - * See Documentation/filesystems/mounting.txt
> > + * See Documentation/filesystems/mount_api.txt
> > */
> > struct fs_context {
> > const struct fs_context_operations *ops;
> > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> > index 47f58cfb6a19..df1318d85f7d 100644
> > --- a/include/linux/lsm_hooks.h
> > +++ b/include/linux/lsm_hooks.h
> > @@ -77,7 +77,7 @@
> > * state. This is called immediately after commit_creds().
> > *
> > * Security hooks for mount using fs_context.
> > - * [See also Documentation/filesystems/mounting.txt]
> > + * [See also Documentation/filesystems/mount_api.txt]
> > *
> > * @fs_context_dup:
> > * Allocate and attach a security structure to sc->security. This
> pointer
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index ee8d1f311858..6e5fb81bde4b 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -165,7 +165,7 @@ config MEMORY_HOTPLUG_DEFAULT_ONLINE
> > onlining policy (/sys/devices/system/memory/auto_online_blocks)
> which
> > determines what happens to newly added memory regions. Policy
> setting
> > can always be changed at runtime.
> > - See Documentation/memory-hotplug.txt for more information.
> > + See Documentation/admin-guide/mm/memory-hotplug.rst for more
> > information.
> >
> > Say Y here if you want all hot-plugged memory blocks to appear
> in
> > 'online' state by default.
> > diff --git a/security/Kconfig b/security/Kconfig
> > index aeac3676dd4d..6d75ed71970c 100644
> > --- a/security/Kconfig
> > +++ b/security/Kconfig
> > @@ -62,7 +62,7 @@ config PAGE_TABLE_ISOLATION
> > ensuring that the majority of kernel addresses are not mapped
> > into userspace.
> >
> > - See Documentation/x86/pti.txt for more details.
> > + See Documentation/x86/pti.rst for more details.
> >
> > config SECURITY_INFINIBAND
> > bool "Infiniband Security Hooks"
> > diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
> > index 2f5a12b88a86..25f2bb3a991d 100644
> > --- a/tools/include/linux/err.h
> > +++ b/tools/include/linux/err.h
> > @@ -20,7 +20,7 @@
> > * Userspace note:
> > * The same principle works for userspace, because 'error' pointers
> > * fall down to the unused hole far from user space, as described
> > - * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
> > + * in Documentation/x86/x86_64/mm.rst for x86_64 arch:
> > *
> > * 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per
> > mm hole caused by [48:63] sign extension * ffffffffffe00000 -
> > ffffffffffffffff (=2 MB) unused hole
> > diff --git a/tools/objtool/Documentation/stack-validation.txt
> > b/tools/objtool/Documentation/stack-validation.txt index
> > 4dd11a554b9b..de094670050b 100644
> > --- a/tools/objtool/Documentation/stack-validation.txt
> > +++ b/tools/objtool/Documentation/stack-validation.txt
> > @@ -21,7 +21,7 @@ instructions). Similarly, it knows how to follow switch
> > statements, for which gcc sometimes uses jump tables.
> >
> > (Objtool also has an 'orc generate' subcommand which generates debuginfo
> > -for the ORC unwinder. See Documentation/x86/orc-unwinder.txt in the
> > +for the ORC unwinder. See Documentation/x86/orc-unwinder.rst in the
> > kernel tree for more details.)
> >
> >
> > @@ -101,7 +101,7 @@ b) ORC (Oops Rewind Capability) unwind table generation
> > band. So it doesn't affect runtime performance and it can be
> > reliable even when interrupts or exceptions are involved.
> >
> > - For more details, see Documentation/x86/orc-unwinder.txt.
> > + For more details, see Documentation/x86/orc-unwinder.rst.
> >
> > c) Higher live patching compatibility rate
> >
> > diff --git a/tools/testing/selftests/x86/protection_keys.c
> > b/tools/testing/selftests/x86/protection_keys.c index
> > 5d546dcdbc80..798a5ddeee55 100644
> > --- a/tools/testing/selftests/x86/protection_keys.c
> > +++ b/tools/testing/selftests/x86/protection_keys.c
> > @@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * Tests x86 Memory Protection Keys (see
> > Documentation/x86/protection-keys.txt) + * Tests x86 Memory Protection Keys
> > (see Documentation/x86/protection-keys.rst) *
> > * There are examples in here of:
> > * * how to set protection keys on memory
>
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 07/10] KVM: PPC: Ultravisor: Restrict LDBAR access
From: Claudio Carvalho @ 2019-05-30 22:51 UTC (permalink / raw)
To: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <600cdf4c-7195-ab32-5fe4-13b71845d222@linux.vnet.ibm.com>
On 5/21/19 2:24 AM, Madhavan Srinivasan wrote:
>
> On 18/05/19 7:55 PM, Claudio Carvalho wrote:
>> From: Ram Pai <linuxram@us.ibm.com> When the ultravisor firmware is
>> available, it takes control over the LDBAR register. In this case,
>> thread-imc updates and save/restore operations on the LDBAR register are
>> handled by ultravisor.
> we should remove the core and thread imc nodes in the skiboot
> if the ultravisor is enabled. We dont need imc-pmu.c file changes, imc-pmu.c
> inits only if we have the corresponding nodes. I will post a skiboot patch.
Hi Maddy,
Thanks for the feedback and for taking care of the change needed in skiboot.
Right, if the core and thread imc devtree nodes were not created by
skiboot, then we don't need imc-pmu changes. As a sanity check, should we
have something like the following to make sure that the imc-pmu code will
not be executed even in the situation where ultravisor is enabled, but for
some reason skiboot did not remove those devtree nodes (e.g. your skiboot
patch was not applied)?
-------------------------
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -258,6 +258,15 @@ static int opal_imc_counters_probe(struct
platform_device *pdev)
bool core_imc_reg = false, thread_imc_reg = false;
u32 type;
+ /*
+ * When ultravisor is enabled, it is responsible for thread-imc
+ * updates
+ */
+ if (firmware_has_feature(FW_FEATURE_ULTRAVISOR)) {
+ pr_info("IMC Ultravisor enabled\n");
+ return -EACCES;
+ }
+
/*
* Check whether this is kdump kernel. If yes, force the engines to
* stop and return.
----------------------------
Claudio
> Maddy
>
>> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
>> [Restrict LDBAR access in assembly code and some in C, update the commit
>> message]
>> Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
>> ---
>> arch/powerpc/kvm/book3s_hv.c | 4 +-
>> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +
>> arch/powerpc/perf/imc-pmu.c | 64 ++++++++++++--------
>> arch/powerpc/platforms/powernv/idle.c | 6 +-
>> arch/powerpc/platforms/powernv/subcore-asm.S | 4 ++
>> 5 files changed, 52 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 0fab0a201027..81f35f955d16 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -75,6 +75,7 @@
>> #include <asm/xics.h>
>> #include <asm/xive.h>
>> #include <asm/hw_breakpoint.h>
>> +#include <asm/firmware.h>
>>
>> #include "book3s.h"
>>
>> @@ -3117,7 +3118,8 @@ static noinline void kvmppc_run_core(struct
>> kvmppc_vcore *vc)
>> subcore_size = MAX_SMT_THREADS / split;
>> split_info.rpr = mfspr(SPRN_RPR);
>> split_info.pmmar = mfspr(SPRN_PMMAR);
>> - split_info.ldbar = mfspr(SPRN_LDBAR);
>> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR))
>> + split_info.ldbar = mfspr(SPRN_LDBAR);
>> split_info.subcore_size = subcore_size;
>> } else {
>> split_info.subcore_size = 1;
>> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> index dd014308f065..938cfa5dceed 100644
>> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> @@ -375,8 +375,10 @@ BEGIN_FTR_SECTION
>> mtspr SPRN_RPR, r0
>> ld r0, KVM_SPLIT_PMMAR(r6)
>> mtspr SPRN_PMMAR, r0
>> +BEGIN_FW_FTR_SECTION_NESTED(70)
>> ld r0, KVM_SPLIT_LDBAR(r6)
>> mtspr SPRN_LDBAR, r0
>> +END_FW_FTR_SECTION_NESTED(FW_FEATURE_ULTRAVISOR, 0, 70)
>> isync
>> FTR_SECTION_ELSE
>> /* On P9 we use the split_info for coordinating LPCR changes */
>> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
>> index 31fa753e2eb2..39c84de74da9 100644
>> --- a/arch/powerpc/perf/imc-pmu.c
>> +++ b/arch/powerpc/perf/imc-pmu.c
>> @@ -17,6 +17,7 @@
>> #include <asm/cputhreads.h>
>> #include <asm/smp.h>
>> #include <linux/string.h>
>> +#include <asm/firmware.h>
>>
>> /* Nest IMC data structures and variables */
>>
>> @@ -816,6 +817,17 @@ static int core_imc_event_init(struct perf_event
>> *event)
>> return 0;
>> }
>>
>> +static void thread_imc_ldbar_disable(void *dummy)
>> +{
>> + /*
>> + * By Zeroing LDBAR, we disable thread-imc updates. When the
>> ultravisor
>> + * firmware is available, it is responsible for handling thread-imc
>> + * updates, though
>> + */
>> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR))
>> + mtspr(SPRN_LDBAR, 0);
>> +}
>> +
>> /*
>> * Allocates a page of memory for each of the online cpus, and load
>> * LDBAR with 0.
>> @@ -856,7 +868,7 @@ static int thread_imc_mem_alloc(int cpu_id, int size)
>> per_cpu(thread_imc_mem, cpu_id) = local_mem;
>> }
>>
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>> return 0;
>> }
>>
>> @@ -867,7 +879,7 @@ static int ppc_thread_imc_cpu_online(unsigned int cpu)
>>
>> static int ppc_thread_imc_cpu_offline(unsigned int cpu)
>> {
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>> return 0;
>> }
>>
>> @@ -1010,7 +1022,6 @@ static int thread_imc_event_add(struct perf_event
>> *event, int flags)
>> {
>> int core_id;
>> struct imc_pmu_ref *ref;
>> - u64 ldbar_value, *local_mem = per_cpu(thread_imc_mem,
>> smp_processor_id());
>>
>> if (flags & PERF_EF_START)
>> imc_event_start(event, flags);
>> @@ -1019,8 +1030,14 @@ static int thread_imc_event_add(struct perf_event
>> *event, int flags)
>> return -EINVAL;
>>
>> core_id = smp_processor_id() / threads_per_core;
>> - ldbar_value = ((u64)local_mem & THREAD_IMC_LDBAR_MASK) |
>> THREAD_IMC_ENABLE;
>> - mtspr(SPRN_LDBAR, ldbar_value);
>> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR)) {
>> + u64 ldbar_value, *local_mem;
>> +
>> + local_mem = per_cpu(thread_imc_mem, smp_processor_id());
>> + ldbar_value = ((u64)local_mem & THREAD_IMC_LDBAR_MASK) |
>> + THREAD_IMC_ENABLE;
>> + mtspr(SPRN_LDBAR, ldbar_value);
>> + }
>>
>> /*
>> * imc pmus are enabled only when it is used.
>> @@ -1053,7 +1070,7 @@ static void thread_imc_event_del(struct perf_event
>> *event, int flags)
>> int core_id;
>> struct imc_pmu_ref *ref;
>>
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>>
>> core_id = smp_processor_id() / threads_per_core;
>> ref = &core_imc_refc[core_id];
>> @@ -1109,7 +1126,7 @@ static int trace_imc_mem_alloc(int cpu_id, int size)
>> trace_imc_refc[core_id].id = core_id;
>> mutex_init(&trace_imc_refc[core_id].lock);
>>
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>> return 0;
>> }
>>
>> @@ -1120,7 +1137,7 @@ static int ppc_trace_imc_cpu_online(unsigned int cpu)
>>
>> static int ppc_trace_imc_cpu_offline(unsigned int cpu)
>> {
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>> return 0;
>> }
>>
>> @@ -1207,11 +1224,6 @@ static int trace_imc_event_add(struct perf_event
>> *event, int flags)
>> {
>> int core_id = smp_processor_id() / threads_per_core;
>> struct imc_pmu_ref *ref = NULL;
>> - u64 local_mem, ldbar_value;
>> -
>> - /* Set trace-imc bit in ldbar and load ldbar with per-thread memory
>> address */
>> - local_mem = get_trace_imc_event_base_addr();
>> - ldbar_value = ((u64)local_mem & THREAD_IMC_LDBAR_MASK) |
>> TRACE_IMC_ENABLE;
>>
>> if (core_imc_refc)
>> ref = &core_imc_refc[core_id];
>> @@ -1222,14 +1234,25 @@ static int trace_imc_event_add(struct perf_event
>> *event, int flags)
>> if (!ref)
>> return -EINVAL;
>> }
>> - mtspr(SPRN_LDBAR, ldbar_value);
>> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR)) {
>> + u64 local_mem, ldbar_value;
>> +
>> + /*
>> + * Set trace-imc bit in ldbar and load ldbar with per-thread
>> + * memory address
>> + */
>> + local_mem = get_trace_imc_event_base_addr();
>> + ldbar_value = ((u64)local_mem & THREAD_IMC_LDBAR_MASK) |
>> + TRACE_IMC_ENABLE;
>> + mtspr(SPRN_LDBAR, ldbar_value);
>> + }
>> mutex_lock(&ref->lock);
>> if (ref->refc == 0) {
>> if (opal_imc_counters_start(OPAL_IMC_COUNTERS_TRACE,
>> get_hard_smp_processor_id(smp_processor_id()))) {
>> mutex_unlock(&ref->lock);
>> pr_err("trace-imc: Unable to start the counters for core
>> %d\n", core_id);
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>> return -EINVAL;
>> }
>> }
>> @@ -1270,7 +1293,7 @@ static void trace_imc_event_del(struct perf_event
>> *event, int flags)
>> if (!ref)
>> return;
>> }
>> - mtspr(SPRN_LDBAR, 0);
>> + thread_imc_ldbar_disable(NULL);
>> mutex_lock(&ref->lock);
>> ref->refc--;
>> if (ref->refc == 0) {
>> @@ -1413,15 +1436,6 @@ static void cleanup_all_core_imc_memory(void)
>> kfree(core_imc_refc);
>> }
>>
>> -static void thread_imc_ldbar_disable(void *dummy)
>> -{
>> - /*
>> - * By Zeroing LDBAR, we disable thread-imc
>> - * updates.
>> - */
>> - mtspr(SPRN_LDBAR, 0);
>> -}
>> -
>> void thread_imc_disable(void)
>> {
>> on_each_cpu(thread_imc_ldbar_disable, NULL, 1);
>> diff --git a/arch/powerpc/platforms/powernv/idle.c
>> b/arch/powerpc/platforms/powernv/idle.c
>> index c9133f7908ca..fd62435e3267 100644
>> --- a/arch/powerpc/platforms/powernv/idle.c
>> +++ b/arch/powerpc/platforms/powernv/idle.c
>> @@ -679,7 +679,8 @@ static unsigned long power9_idle_stop(unsigned long
>> psscr, bool mmu_on)
>> sprs.ptcr = mfspr(SPRN_PTCR);
>> sprs.rpr = mfspr(SPRN_RPR);
>> sprs.tscr = mfspr(SPRN_TSCR);
>> - sprs.ldbar = mfspr(SPRN_LDBAR);
>> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR))
>> + sprs.ldbar = mfspr(SPRN_LDBAR);
>>
>> sprs_saved = true;
>>
>> @@ -762,7 +763,8 @@ static unsigned long power9_idle_stop(unsigned long
>> psscr, bool mmu_on)
>> mtspr(SPRN_PTCR, sprs.ptcr);
>> mtspr(SPRN_RPR, sprs.rpr);
>> mtspr(SPRN_TSCR, sprs.tscr);
>> - mtspr(SPRN_LDBAR, sprs.ldbar);
>> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR))
>> + mtspr(SPRN_LDBAR, sprs.ldbar);
>>
>> if (pls >= pnv_first_tb_loss_level) {
>> /* TB loss */
>> diff --git a/arch/powerpc/platforms/powernv/subcore-asm.S
>> b/arch/powerpc/platforms/powernv/subcore-asm.S
>> index 39bb24aa8f34..e4383fa5e150 100644
>> --- a/arch/powerpc/platforms/powernv/subcore-asm.S
>> +++ b/arch/powerpc/platforms/powernv/subcore-asm.S
>> @@ -44,7 +44,9 @@ _GLOBAL(split_core_secondary_loop)
>>
>> real_mode:
>> /* Grab values from unsplit SPRs */
>> +BEGIN_FW_FTR_SECTION
>> mfspr r6, SPRN_LDBAR
>> +END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ULTRAVISOR)
>> mfspr r7, SPRN_PMMAR
>> mfspr r8, SPRN_PMCR
>> mfspr r9, SPRN_RPR
>> @@ -77,7 +79,9 @@ real_mode:
>> mtspr SPRN_HDEC, r4
>>
>> /* Restore SPR values now we are split */
>> +BEGIN_FW_FTR_SECTION
>> mtspr SPRN_LDBAR, r6
>> +END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ULTRAVISOR)
>> mtspr SPRN_PMMAR, r7
>> mtspr SPRN_PMCR, r8
>> mtspr SPRN_RPR, r9
>
^ permalink raw reply
* Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware
From: Benjamin Herrenschmidt @ 2019-05-31 1:03 UTC (permalink / raw)
To: Segher Boessenkool, Alexey Kardashevskiy
Cc: linuxppc-dev, Suraj Jitindar Singh, David Gibson
In-Reply-To: <20190530193736.GC31586@gate.crashing.org>
On Thu, 2019-05-30 at 14:37 -0500, Segher Boessenkool wrote:
> On Thu, May 30, 2019 at 05:09:06PM +1000, Alexey Kardashevskiy wrote:
> > so, it is sort-of nack from David and sort-of ack from Segher, what
> > happens now?
>
> Maybe what we really need just a CI call to get all properties of a node
> at once? Will that speed up things enough?
>
> That way you need no change at all in lifetime of properties and how they
> are used, etc.; just a client getting the properties is a lot faster.
Hrm... if we're going to create a new interface, let's go for what we
need.
What we need is the FDT. It's a rather ubiquitous thing these days, it
makes sense to have a way to fetch an FDT directly from FW.
There is no use for the "fetch all properties" cases other than
building an FDT that any of us can think of, and it would create a more
complicated interface than just "fetch an FDT".
So I go for the simple one and agree with Alexey's idea.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH] powerpc/book3e: KASAN Full support for 64bit
From: Daniel Axtens @ 2019-05-31 1:29 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3401648225001077db54172ee87573b21e1cfa38.1553782837.git.christophe.leroy@c-s.fr>
Hi Christophe,
I tried this on the t4240rdb and it fails to boot if KASAN is
enabled. It does boot with the patch applied but KASAN disabled, so that
narrows it down a little bit.
I need to focus on 3s first so I'll just drop 3e from my patch set for
now.
Regards,
Daniel
> The KASAN shadow area is mapped into vmemmap space:
> 0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
> For this vmemmap has to be disabled.
>
> Cc: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/Kconfig.debug | 3 +-
> arch/powerpc/include/asm/kasan.h | 11 +++
> arch/powerpc/kernel/Makefile | 2 +
> arch/powerpc/kernel/head_64.S | 3 +
> arch/powerpc/kernel/setup_64.c | 20 +++---
> arch/powerpc/mm/kasan/Makefile | 1 +
> arch/powerpc/mm/kasan/kasan_init_64.c | 129 ++++++++++++++++++++++++++++++++++
> 8 files changed, 159 insertions(+), 11 deletions(-)
> create mode 100644 arch/powerpc/mm/kasan/kasan_init_64.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1a2fb50126b2..e0b7c45e4dc7 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -174,6 +174,7 @@ config PPC
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_KASAN if PPC32
> + select HAVE_ARCH_KASAN if PPC_BOOK3E_64 && !SPARSEMEM_VMEMMAP
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_MMAP_RND_BITS
> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index 61febbbdd02b..b4140dd6b4e4 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -370,4 +370,5 @@ config PPC_FAST_ENDIAN_SWITCH
> config KASAN_SHADOW_OFFSET
> hex
> depends on KASAN
> - default 0xe0000000
> + default 0xe0000000 if PPC32
> + default 0x6800040000000000 if PPC64
> diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
> index 296e51c2f066..756b3d58f921 100644
> --- a/arch/powerpc/include/asm/kasan.h
> +++ b/arch/powerpc/include/asm/kasan.h
> @@ -23,10 +23,21 @@
>
> #define KASAN_SHADOW_OFFSET ASM_CONST(CONFIG_KASAN_SHADOW_OFFSET)
>
> +#ifdef CONFIG_PPC32
> #define KASAN_SHADOW_END 0UL
>
> #define KASAN_SHADOW_SIZE (KASAN_SHADOW_END - KASAN_SHADOW_START)
>
> +#else
> +
> +#include <asm/pgtable.h>
> +
> +#define KASAN_SHADOW_SIZE (KERN_VIRT_SIZE >> KASAN_SHADOW_SCALE_SHIFT)
> +
> +#define KASAN_SHADOW_END (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
> +
> +#endif /* CONFIG_PPC32 */
> +
> #ifdef CONFIG_KASAN
> void kasan_early_init(void);
> void kasan_mmu_init(void);
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 0ea6c4aa3a20..7f232c06f11d 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -35,6 +35,8 @@ KASAN_SANITIZE_early_32.o := n
> KASAN_SANITIZE_cputable.o := n
> KASAN_SANITIZE_prom_init.o := n
> KASAN_SANITIZE_btext.o := n
> +KASAN_SANITIZE_paca.o := n
> +KASAN_SANITIZE_setup_64.o := n
>
> ifdef CONFIG_KASAN
> CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 3fad8d499767..80fbd8024fb2 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -966,6 +966,9 @@ start_here_multiplatform:
> * and SLB setup before we turn on relocation.
> */
>
> +#ifdef CONFIG_KASAN
> + bl kasan_early_init
> +#endif
> /* Restore parameters passed from prom_init/kexec */
> mr r3,r31
> bl early_setup /* also sets r13 and SPRG_PACA */
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index ba404dd9ce1d..d2bf860dd966 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -311,6 +311,16 @@ void __init early_setup(unsigned long dt_ptr)
> DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
>
> /*
> + * Configure exception handlers. This include setting up trampolines
> + * if needed, setting exception endian mode, etc...
> + */
> + configure_exceptions();
> +
> + /* Apply all the dynamic patching */
> + apply_feature_fixups();
> + setup_feature_keys();
> +
> + /*
> * Do early initialization using the flattened device
> * tree, such as retrieving the physical memory map or
> * calculating/retrieving the hash table size.
> @@ -325,16 +335,6 @@ void __init early_setup(unsigned long dt_ptr)
> setup_paca(paca_ptrs[boot_cpuid]);
> fixup_boot_paca();
>
> - /*
> - * Configure exception handlers. This include setting up trampolines
> - * if needed, setting exception endian mode, etc...
> - */
> - configure_exceptions();
> -
> - /* Apply all the dynamic patching */
> - apply_feature_fixups();
> - setup_feature_keys();
> -
> /* Initialize the hash table or TLB handling */
> early_init_mmu();
>
> diff --git a/arch/powerpc/mm/kasan/Makefile b/arch/powerpc/mm/kasan/Makefile
> index 6577897673dd..0bfbe3892808 100644
> --- a/arch/powerpc/mm/kasan/Makefile
> +++ b/arch/powerpc/mm/kasan/Makefile
> @@ -3,3 +3,4 @@
> KASAN_SANITIZE := n
>
> obj-$(CONFIG_PPC32) += kasan_init_32.o
> +obj-$(CONFIG_PPC64) += kasan_init_64.o
> diff --git a/arch/powerpc/mm/kasan/kasan_init_64.c b/arch/powerpc/mm/kasan/kasan_init_64.c
> new file mode 100644
> index 000000000000..7fd71b8e883b
> --- /dev/null
> +++ b/arch/powerpc/mm/kasan/kasan_init_64.c
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define DISABLE_BRANCH_PROFILING
> +
> +#include <linux/kasan.h>
> +#include <linux/printk.h>
> +#include <linux/memblock.h>
> +#include <linux/sched/task.h>
> +#include <asm/pgalloc.h>
> +
> +static void __init kasan_populate_pte(pte_t *ptep, pgprot_t prot)
> +{
> + unsigned long va = (unsigned long)kasan_early_shadow_page;
> + phys_addr_t pa = __pa(kasan_early_shadow_page);
> + int i;
> +
> + for (i = 0; i < PTRS_PER_PTE; i++, ptep++)
> + __set_pte_at(&init_mm, va, ptep, pfn_pte(PHYS_PFN(pa), prot), 0);
> +}
> +
> +static void __init kasan_populate_pmd(pmd_t *pmdp)
> +{
> + int i;
> +
> + for (i = 0; i < PTRS_PER_PMD; i++)
> + pmd_populate_kernel(&init_mm, pmdp + i, kasan_early_shadow_pte);
> +}
> +
> +static void __init kasan_populate_pud(pud_t *pudp)
> +{
> + int i;
> +
> + for (i = 0; i < PTRS_PER_PUD; i++)
> + pud_populate(&init_mm, pudp + i, kasan_early_shadow_pmd);
> +}
> +
> +static void __init *kasan_alloc_pgtable(unsigned long size)
> +{
> + void *ptr = memblock_alloc_try_nid(size, size, MEMBLOCK_LOW_LIMIT,
> + __pa(MAX_DMA_ADDRESS), NUMA_NO_NODE);
> +
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx max_addr=%lx\n",
> + __func__, size, size, __pa(MAX_DMA_ADDRESS));
> +
> + return ptr;
> +}
> +
> +static int __init kasan_map_page(unsigned long va, unsigned long pa, pgprot_t prot)
> +{
> + pgd_t *pgdp = pgd_offset_k(va);
> + pud_t *pudp;
> + pmd_t *pmdp;
> + pte_t *ptep;
> +
> + if (pgd_none(*pgdp) || (void *)pgd_page_vaddr(*pgdp) == kasan_early_shadow_pud) {
> + pudp = kasan_alloc_pgtable(PUD_TABLE_SIZE);
> + kasan_populate_pud(pudp);
> + pgd_populate(&init_mm, pgdp, pudp);
> + }
> + pudp = pud_offset(pgdp, va);
> + if (pud_none(*pudp) || (void *)pud_page_vaddr(*pudp) == kasan_early_shadow_pmd) {
> + pmdp = kasan_alloc_pgtable(PMD_TABLE_SIZE);
> + kasan_populate_pmd(pmdp);
> + pud_populate(&init_mm, pudp, pmdp);
> + }
> + pmdp = pmd_offset(pudp, va);
> + if (!pmd_present(*pmdp) || (void *)pmd_page_vaddr(*pmdp) == kasan_early_shadow_pte) {
> + ptep = kasan_alloc_pgtable(PTE_TABLE_SIZE);
> + kasan_populate_pte(ptep, PAGE_KERNEL);
> + pmd_populate_kernel(&init_mm, pmdp, ptep);
> + }
> + ptep = pte_offset_kernel(pmdp, va);
> +
> + __set_pte_at(&init_mm, va, ptep, pfn_pte(pa >> PAGE_SHIFT, prot), 0);
> +
> + return 0;
> +}
> +
> +static void __init kasan_init_region(struct memblock_region *reg)
> +{
> + void *start = __va(reg->base);
> + void *end = __va(reg->base + reg->size);
> + unsigned long k_start, k_end, k_cur;
> +
> + if (start >= end)
> + return;
> +
> + k_start = (unsigned long)kasan_mem_to_shadow(start);
> + k_end = (unsigned long)kasan_mem_to_shadow(end);
> +
> + for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE) {
> + void *va = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> +
> + kasan_map_page(k_cur, __pa(va), PAGE_KERNEL);
> + }
> + flush_tlb_kernel_range(k_start, k_end);
> +}
> +
> +void __init kasan_init(void)
> +{
> + struct memblock_region *reg;
> +
> + for_each_memblock(memory, reg)
> + kasan_init_region(reg);
> +
> + /* It's too early to use clear_page() ! */
> + memset(kasan_early_shadow_page, 0, sizeof(kasan_early_shadow_page));
> +
> + /* Enable error messages */
> + init_task.kasan_depth = 0;
> + pr_info("KASAN init done\n");
> +}
> +
> +/* The early shadow maps everything to a single page of zeroes */
> +asmlinkage void __init kasan_early_init(void)
> +{
> + unsigned long addr = KASAN_SHADOW_START;
> + unsigned long end = KASAN_SHADOW_END;
> + pgd_t *pgdp = pgd_offset_k(addr);
> +
> + kasan_populate_pte(kasan_early_shadow_pte, PAGE_KERNEL);
> + kasan_populate_pmd(kasan_early_shadow_pmd);
> + kasan_populate_pud(kasan_early_shadow_pud);
> +
> + do {
> + pgd_populate(&init_mm, pgdp, kasan_early_shadow_pud);
> + } while (pgdp++, addr = pgd_addr_end(addr, end), addr != end);
> +}
> --
> 2.13.3
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Introduce pcibios_ignore_alignment_request
From: Alexey Kardashevskiy @ 2019-05-31 3:56 UTC (permalink / raw)
To: Shawn Anastasio, Oliver
Cc: Sam Bobroff, linux-pci, Linux Kernel Mailing List, rppt,
Paul Mackerras, Bjorn Helgaas, xyjxie, linuxppc-dev
In-Reply-To: <985681e4-1236-fff7-e9e7-189a340487dd@anastas.io>
On 31/05/2019 08:49, Shawn Anastasio wrote:
> On 5/29/19 10:39 PM, Alexey Kardashevskiy wrote:
>>
>>
>> On 28/05/2019 17:39, Shawn Anastasio wrote:
>>>
>>>
>>> On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
>>>>
>>>>
>>>> On 28/05/2019 15:36, Oliver wrote:
>>>>> On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio <shawn@anastas.io>
>>>>> wrote:
>>>>>>
>>>>>> Introduce a new pcibios function pcibios_ignore_alignment_request
>>>>>> which allows the PCI core to defer to platform-specific code to
>>>>>> determine whether or not to ignore alignment requests for PCI
>>>>>> resources.
>>>>>>
>>>>>> The existing behavior is to simply ignore alignment requests when
>>>>>> PCI_PROBE_ONLY is set. This is behavior is maintained by the
>>>>>> default implementation of pcibios_ignore_alignment_request.
>>>>>>
>>>>>> Signed-off-by: Shawn Anastasio <shawn@anastas.io>
>>>>>> ---
>>>>>> drivers/pci/pci.c | 9 +++++++--
>>>>>> include/linux/pci.h | 1 +
>>>>>> 2 files changed, 8 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>>>> index 8abc843b1615..8207a09085d1 100644
>>>>>> --- a/drivers/pci/pci.c
>>>>>> +++ b/drivers/pci/pci.c
>>>>>> @@ -5882,6 +5882,11 @@ resource_size_t __weak
>>>>>> pcibios_default_alignment(void)
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> +int __weak pcibios_ignore_alignment_request(void)
>>>>>> +{
>>>>>> + return pci_has_flag(PCI_PROBE_ONLY);
>>>>>> +}
>>>>>> +
>>>>>> #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
>>>>>> static char
>>>>>> resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
>>>>>> static DEFINE_SPINLOCK(resource_alignment_lock);
>>>>>> @@ -5906,9 +5911,9 @@ static resource_size_t
>>>>>> pci_specified_resource_alignment(struct pci_dev *dev,
>>>>>> p = resource_alignment_param;
>>>>>> if (!*p && !align)
>>>>>> goto out;
>>>>>> - if (pci_has_flag(PCI_PROBE_ONLY)) {
>>>>>> + if (pcibios_ignore_alignment_request()) {
>>>>>> align = 0;
>>>>>> - pr_info_once("PCI: Ignoring requested alignments
>>>>>> (PCI_PROBE_ONLY)\n");
>>>>>> + pr_info_once("PCI: Ignoring requested alignments\n");
>>>>>> goto out;
>>>>>> }
>>>>>
>>>>> I think the logic here is questionable to begin with. If the user has
>>>>> explicitly requested re-aligning a resource via the command line then
>>>>> we should probably do it even if PCI_PROBE_ONLY is set. When it breaks
>>>>> they get to keep the pieces.
>>>>>
>>>>> That said, the real issue here is that PCI_PROBE_ONLY probably
>>>>> shouldn't be set under qemu/kvm. Under the other hypervisor (PowerVM)
>>>>> hotplugged devices are configured by firmware before it's passed to
>>>>> the guest and we need to keep the FW assignments otherwise things
>>>>> break. QEMU however doesn't do any BAR assignments and relies on that
>>>>> being handled by the guest. At boot time this is done by SLOF, but
>>>>> Linux only keeps SLOF around until it's extracted the device-tree.
>>>>> Once that's done SLOF gets blown away and the kernel needs to do it's
>>>>> own BAR assignments. I'm guessing there's a hack in there to make it
>>>>> work today, but it's a little surprising that it works at all...
>>>>
>>>>
>>>> The hack is to run a modified qemu-aware "/usr/sbin/rtas_errd" in the
>>>> guest which receives an event from qemu (RAS_EPOW from
>>>> /proc/interrupts), fetches device tree chunks (and as I understand it -
>>>> they come with BARs from phyp but without from qemu) and writes "1" to
>>>> "/sys/bus/pci/rescan" which calls pci_assign_resource() eventually:
>>>
>>> Interesting. Does this mean that the PHYP hotplug path doesn't
>>> call pci_assign_resource?
>>
>>
>> I'd expect dlpar_add_slot() to be called under phyp and eventually
>> pci_device_add() which (I think) may or may not trigger later
>> reassignment.
>>
>>
>>> If so it means the patch may not
>>> break that platform after all, though it still may not be
>>> the correct way of doing things.
>>
>>
>> We should probably stop enforcing the PCI_PROBE_ONLY flag - it seems
>> that (unless resource_alignment= is used) the pseries guest should just
>> walk through all allocated resources and leave them unchanged.
>
> If we add a pcibios_default_alignment() implementation like was
> suggested earlier, then it will behave as if the user has
> specified resource_alignment= by default and SLOF's assignments
> won't be honored (I think).
I removed pci_add_flags(PCI_PROBE_ONLY) from pSeries_setup_arch and
tried booting with and without pci=resource_alignment= and I can see no
difference - BARs are still aligned to 64K as programmed in SLOF; if I
hack SLOF to align to 4K or 32K - BARs get packed and the guest leaves
them unchanged.
> I guess it boils down to one question - is it important that we
> observe SLOF's initial BAR assignments?
It isn't if it's SLOF but it is if it's phyp. It used to not
allow/support BAR reassignment and even if it does not, I'd rather avoid
touching them.
> If not, the device tree
> modification that Sam found would work fine here. Otherwise,
> we need a way to honor the initial assignments from SLOF while
> still allowing custom alignments for hotplugged devices, either
> by deferring to the platform code like I do here, unsetting
> PCI_PROBE_ONLY in certain cases or by using IORESOURCE_PCI_FIXED
> like Bjorn suggested.
>
>>
>>
>>>> [c000000006e6f960] [c0000000005f62d4] pci_assign_resource+0x44/0x360
>>>>
>>>> [c000000006e6fa10] [c0000000005f8b54]
>>>> assign_requested_resources_sorted+0x84/0x110
>>>> [c000000006e6fa60] [c0000000005f9540]
>>>> __assign_resources_sorted+0xd0/0x750
>>>> [c000000006e6fb40] [c0000000005fb2e0]
>>>> __pci_bus_assign_resources+0x80/0x280
>>>> [c000000006e6fc00] [c0000000005fb95c]
>>>> pci_assign_unassigned_bus_resources+0xbc/0x100
>>>> [c000000006e6fc60] [c0000000005e3d74] pci_rescan_bus+0x34/0x60
>>>>
>>>> [c000000006e6fc90] [c0000000005f1ef4] rescan_store+0x84/0xc0
>>>>
>>>> [c000000006e6fcd0] [c00000000068060c] bus_attr_store+0x3c/0x60
>>>>
>>>> [c000000006e6fcf0] [c00000000037853c] sysfs_kf_write+0x5c/0x80
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> IIRC Sam Bobroff was looking at hotplug under pseries recently so he
>>>>> might have something to add. He's sick at the moment, but I'll ask him
>>>>> to take a look at this once he's back among the living
>>>>>
>>>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>>>> index 4a5a84d7bdd4..47471dcdbaf9 100644
>>>>>> --- a/include/linux/pci.h
>>>>>> +++ b/include/linux/pci.h
>>>>>> @@ -1990,6 +1990,7 @@ static inline void
>>>>>> pcibios_penalize_isa_irq(int irq, int active) {}
>>>>>> int pcibios_alloc_irq(struct pci_dev *dev);
>>>>>> void pcibios_free_irq(struct pci_dev *dev);
>>>>>> resource_size_t pcibios_default_alignment(void);
>>>>>> +int pcibios_ignore_alignment_request(void);
>>>>>>
>>>>>> #ifdef CONFIG_HIBERNATE_CALLBACKS
>>>>>> extern struct dev_pm_ops pcibios_pm_ops;
>>>>>> --
>>>>>> 2.20.1
>>>>>>
>>>>
>>
--
Alexey
^ permalink raw reply
* Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
From: Nayna @ 2019-05-31 4:04 UTC (permalink / raw)
To: Daniel Axtens, nayna, cclaudio, linux-fsdevel, greg, linuxppc-dev
In-Reply-To: <20190520062553.14947-1-dja@axtens.net>
On 05/20/2019 02:25 AM, Daniel Axtens wrote:
> Hi all,
>
> As PowerNV moves towards secure boot, we need a place to put secure
> variables. One option that has been canvassed is to make our secure
> variables look like EFI variables. This is an early sketch of another
> approach where we create a generic firmware variable file system,
> fwvarfs, and an OPAL Secure Variable backend for it.
Is there a need of new filesystem ? I am wondering why can't these be
exposed via sysfs / securityfs ?
Probably, something like... /sys/firmware/secureboot or
/sys/kernel/security/secureboot/ ?
Also, it sounds like this is needed only for secure firmware variables
and does not include
other firmware variables which are not security relevant ? Is that
correct understanding ?
Thanks & Regards,
- Nayna
^ permalink raw reply
* [PATCH BACKPORT 4.19, 5.0, 5.1] crypto: vmx - ghash: do nosimd fallback manually
From: Daniel Axtens @ 2019-05-31 6:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Herbert Xu, stable, Daniel Axtens
VMX ghash was using a fallback that did not support interleaving simd
and nosimd operations, leading to failures in the extended test suite.
If I understood correctly, Eric's suggestion was to use the same
data format that the generic code uses, allowing us to call into it
with the same contexts. I wasn't able to get that to work - I think
there's a very different key structure and data layout being used.
So instead steal the arm64 approach and perform the fallback
operations directly if required.
Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: stable@vger.kernel.org # v4.1+
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(backported from commit 357d065a44cdd77ed5ff35155a989f2a763e96ef)
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
drivers/crypto/vmx/ghash.c | 212 +++++++++++++++----------------------
1 file changed, 86 insertions(+), 126 deletions(-)
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index dd8b8716467a..2d1a8cd35509 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -1,22 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
/**
* GHASH routines supporting VMX instructions on the Power 8
*
- * Copyright (C) 2015 International Business Machines Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 only.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * Copyright (C) 2015, 2019 International Business Machines Inc.
*
* Author: Marcelo Henrique Cerri <mhcerri@br.ibm.com>
+ *
+ * Extended by Daniel Axtens <dja@axtens.net> to replace the fallback
+ * mechanism. The new approach is based on arm64 code, which is:
+ * Copyright (C) 2014 - 2018 Linaro Ltd. <ard.biesheuvel@linaro.org>
*/
#include <linux/types.h>
@@ -39,71 +31,25 @@ void gcm_ghash_p8(u64 Xi[2], const u128 htable[16],
const u8 *in, size_t len);
struct p8_ghash_ctx {
+ /* key used by vector asm */
u128 htable[16];
- struct crypto_shash *fallback;
+ /* key used by software fallback */
+ be128 key;
};
struct p8_ghash_desc_ctx {
u64 shash[2];
u8 buffer[GHASH_DIGEST_SIZE];
int bytes;
- struct shash_desc fallback_desc;
};
-static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
-{
- const char *alg = "ghash-generic";
- struct crypto_shash *fallback;
- struct crypto_shash *shash_tfm = __crypto_shash_cast(tfm);
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
-
- fallback = crypto_alloc_shash(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
- if (IS_ERR(fallback)) {
- printk(KERN_ERR
- "Failed to allocate transformation for '%s': %ld\n",
- alg, PTR_ERR(fallback));
- return PTR_ERR(fallback);
- }
-
- crypto_shash_set_flags(fallback,
- crypto_shash_get_flags((struct crypto_shash
- *) tfm));
-
- /* Check if the descsize defined in the algorithm is still enough. */
- if (shash_tfm->descsize < sizeof(struct p8_ghash_desc_ctx)
- + crypto_shash_descsize(fallback)) {
- printk(KERN_ERR
- "Desc size of the fallback implementation (%s) does not match the expected value: %lu vs %u\n",
- alg,
- shash_tfm->descsize - sizeof(struct p8_ghash_desc_ctx),
- crypto_shash_descsize(fallback));
- return -EINVAL;
- }
- ctx->fallback = fallback;
-
- return 0;
-}
-
-static void p8_ghash_exit_tfm(struct crypto_tfm *tfm)
-{
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
-
- if (ctx->fallback) {
- crypto_free_shash(ctx->fallback);
- ctx->fallback = NULL;
- }
-}
-
static int p8_ghash_init(struct shash_desc *desc)
{
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
dctx->bytes = 0;
memset(dctx->shash, 0, GHASH_DIGEST_SIZE);
- dctx->fallback_desc.tfm = ctx->fallback;
- dctx->fallback_desc.flags = desc->flags;
- return crypto_shash_init(&dctx->fallback_desc);
+ return 0;
}
static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
@@ -121,7 +67,51 @@ static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
disable_kernel_vsx();
pagefault_enable();
preempt_enable();
- return crypto_shash_setkey(ctx->fallback, key, keylen);
+
+ memcpy(&ctx->key, key, GHASH_BLOCK_SIZE);
+
+ return 0;
+}
+
+static inline void __ghash_block(struct p8_ghash_ctx *ctx,
+ struct p8_ghash_desc_ctx *dctx)
+{
+ if (!IN_INTERRUPT) {
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_vsx();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ dctx->buffer, GHASH_DIGEST_SIZE);
+ disable_kernel_vsx();
+ pagefault_enable();
+ preempt_enable();
+ } else {
+ crypto_xor((u8 *)dctx->shash, dctx->buffer, GHASH_BLOCK_SIZE);
+ gf128mul_lle((be128 *)dctx->shash, &ctx->key);
+ }
+}
+
+static inline void __ghash_blocks(struct p8_ghash_ctx *ctx,
+ struct p8_ghash_desc_ctx *dctx,
+ const u8 *src, unsigned int srclen)
+{
+ if (!IN_INTERRUPT) {
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_vsx();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ src, srclen);
+ disable_kernel_vsx();
+ pagefault_enable();
+ preempt_enable();
+ } else {
+ while (srclen >= GHASH_BLOCK_SIZE) {
+ crypto_xor((u8 *)dctx->shash, src, GHASH_BLOCK_SIZE);
+ gf128mul_lle((be128 *)dctx->shash, &ctx->key);
+ srclen -= GHASH_BLOCK_SIZE;
+ src += GHASH_BLOCK_SIZE;
+ }
+ }
}
static int p8_ghash_update(struct shash_desc *desc,
@@ -131,49 +121,33 @@ static int p8_ghash_update(struct shash_desc *desc,
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- if (IN_INTERRUPT) {
- return crypto_shash_update(&dctx->fallback_desc, src,
- srclen);
- } else {
- if (dctx->bytes) {
- if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
- memcpy(dctx->buffer + dctx->bytes, src,
- srclen);
- dctx->bytes += srclen;
- return 0;
- }
+ if (dctx->bytes) {
+ if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
memcpy(dctx->buffer + dctx->bytes, src,
- GHASH_DIGEST_SIZE - dctx->bytes);
- preempt_disable();
- pagefault_disable();
- enable_kernel_vsx();
- gcm_ghash_p8(dctx->shash, ctx->htable,
- dctx->buffer, GHASH_DIGEST_SIZE);
- disable_kernel_vsx();
- pagefault_enable();
- preempt_enable();
- src += GHASH_DIGEST_SIZE - dctx->bytes;
- srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
- dctx->bytes = 0;
- }
- len = srclen & ~(GHASH_DIGEST_SIZE - 1);
- if (len) {
- preempt_disable();
- pagefault_disable();
- enable_kernel_vsx();
- gcm_ghash_p8(dctx->shash, ctx->htable, src, len);
- disable_kernel_vsx();
- pagefault_enable();
- preempt_enable();
- src += len;
- srclen -= len;
- }
- if (srclen) {
- memcpy(dctx->buffer, src, srclen);
- dctx->bytes = srclen;
+ srclen);
+ dctx->bytes += srclen;
+ return 0;
}
- return 0;
+ memcpy(dctx->buffer + dctx->bytes, src,
+ GHASH_DIGEST_SIZE - dctx->bytes);
+
+ __ghash_block(ctx, dctx);
+
+ src += GHASH_DIGEST_SIZE - dctx->bytes;
+ srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
+ dctx->bytes = 0;
+ }
+ len = srclen & ~(GHASH_DIGEST_SIZE - 1);
+ if (len) {
+ __ghash_blocks(ctx, dctx, src, len);
+ src += len;
+ srclen -= len;
}
+ if (srclen) {
+ memcpy(dctx->buffer, src, srclen);
+ dctx->bytes = srclen;
+ }
+ return 0;
}
static int p8_ghash_final(struct shash_desc *desc, u8 *out)
@@ -182,25 +156,14 @@ static int p8_ghash_final(struct shash_desc *desc, u8 *out)
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- if (IN_INTERRUPT) {
- return crypto_shash_final(&dctx->fallback_desc, out);
- } else {
- if (dctx->bytes) {
- for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
- dctx->buffer[i] = 0;
- preempt_disable();
- pagefault_disable();
- enable_kernel_vsx();
- gcm_ghash_p8(dctx->shash, ctx->htable,
- dctx->buffer, GHASH_DIGEST_SIZE);
- disable_kernel_vsx();
- pagefault_enable();
- preempt_enable();
- dctx->bytes = 0;
- }
- memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
- return 0;
+ if (dctx->bytes) {
+ for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
+ dctx->buffer[i] = 0;
+ __ghash_block(ctx, dctx);
+ dctx->bytes = 0;
}
+ memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
+ return 0;
}
struct shash_alg p8_ghash_alg = {
@@ -215,11 +178,8 @@ struct shash_alg p8_ghash_alg = {
.cra_name = "ghash",
.cra_driver_name = "p8_ghash",
.cra_priority = 1000,
- .cra_flags = CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = GHASH_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct p8_ghash_ctx),
.cra_module = THIS_MODULE,
- .cra_init = p8_ghash_init_tfm,
- .cra_exit = p8_ghash_exit_tfm,
},
};
--
2.19.1
^ permalink raw reply related
* [PATCH BACKPORT 4.9, 4.14] crypto: vmx - ghash: do nosimd fallback manually
From: Daniel Axtens @ 2019-05-31 6:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Herbert Xu, stable, Daniel Axtens
VMX ghash was using a fallback that did not support interleaving simd
and nosimd operations, leading to failures in the extended test suite.
If I understood correctly, Eric's suggestion was to use the same
data format that the generic code uses, allowing us to call into it
with the same contexts. I wasn't able to get that to work - I think
there's a very different key structure and data layout being used.
So instead steal the arm64 approach and perform the fallback
operations directly if required.
Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: stable@vger.kernel.org # v4.1+
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(backported from commit 357d065a44cdd77ed5ff35155a989f2a763e96ef)
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
drivers/crypto/vmx/ghash.c | 213 +++++++++++++++----------------------
1 file changed, 87 insertions(+), 126 deletions(-)
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index 1c4b5b889fba..1bfe867c0b7b 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -1,22 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
/**
* GHASH routines supporting VMX instructions on the Power 8
*
- * Copyright (C) 2015 International Business Machines Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 only.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * Copyright (C) 2015, 2019 International Business Machines Inc.
*
* Author: Marcelo Henrique Cerri <mhcerri@br.ibm.com>
+ *
+ * Extended by Daniel Axtens <dja@axtens.net> to replace the fallback
+ * mechanism. The new approach is based on arm64 code, which is:
+ * Copyright (C) 2014 - 2018 Linaro Ltd. <ard.biesheuvel@linaro.org>
*/
#include <linux/types.h>
@@ -39,71 +31,25 @@ void gcm_ghash_p8(u64 Xi[2], const u128 htable[16],
const u8 *in, size_t len);
struct p8_ghash_ctx {
+ /* key used by vector asm */
u128 htable[16];
- struct crypto_shash *fallback;
+ /* key used by software fallback */
+ be128 key;
};
struct p8_ghash_desc_ctx {
u64 shash[2];
u8 buffer[GHASH_DIGEST_SIZE];
int bytes;
- struct shash_desc fallback_desc;
};
-static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
-{
- const char *alg = "ghash-generic";
- struct crypto_shash *fallback;
- struct crypto_shash *shash_tfm = __crypto_shash_cast(tfm);
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
-
- fallback = crypto_alloc_shash(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
- if (IS_ERR(fallback)) {
- printk(KERN_ERR
- "Failed to allocate transformation for '%s': %ld\n",
- alg, PTR_ERR(fallback));
- return PTR_ERR(fallback);
- }
-
- crypto_shash_set_flags(fallback,
- crypto_shash_get_flags((struct crypto_shash
- *) tfm));
-
- /* Check if the descsize defined in the algorithm is still enough. */
- if (shash_tfm->descsize < sizeof(struct p8_ghash_desc_ctx)
- + crypto_shash_descsize(fallback)) {
- printk(KERN_ERR
- "Desc size of the fallback implementation (%s) does not match the expected value: %lu vs %u\n",
- alg,
- shash_tfm->descsize - sizeof(struct p8_ghash_desc_ctx),
- crypto_shash_descsize(fallback));
- return -EINVAL;
- }
- ctx->fallback = fallback;
-
- return 0;
-}
-
-static void p8_ghash_exit_tfm(struct crypto_tfm *tfm)
-{
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
-
- if (ctx->fallback) {
- crypto_free_shash(ctx->fallback);
- ctx->fallback = NULL;
- }
-}
-
static int p8_ghash_init(struct shash_desc *desc)
{
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
dctx->bytes = 0;
memset(dctx->shash, 0, GHASH_DIGEST_SIZE);
- dctx->fallback_desc.tfm = ctx->fallback;
- dctx->fallback_desc.flags = desc->flags;
- return crypto_shash_init(&dctx->fallback_desc);
+ return 0;
}
static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
@@ -121,7 +67,51 @@ static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
disable_kernel_vsx();
pagefault_enable();
preempt_enable();
- return crypto_shash_setkey(ctx->fallback, key, keylen);
+
+ memcpy(&ctx->key, key, GHASH_BLOCK_SIZE);
+
+ return 0;
+}
+
+static inline void __ghash_block(struct p8_ghash_ctx *ctx,
+ struct p8_ghash_desc_ctx *dctx)
+{
+ if (!IN_INTERRUPT) {
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_vsx();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ dctx->buffer, GHASH_DIGEST_SIZE);
+ disable_kernel_vsx();
+ pagefault_enable();
+ preempt_enable();
+ } else {
+ crypto_xor((u8 *)dctx->shash, dctx->buffer, GHASH_BLOCK_SIZE);
+ gf128mul_lle((be128 *)dctx->shash, &ctx->key);
+ }
+}
+
+static inline void __ghash_blocks(struct p8_ghash_ctx *ctx,
+ struct p8_ghash_desc_ctx *dctx,
+ const u8 *src, unsigned int srclen)
+{
+ if (!IN_INTERRUPT) {
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_vsx();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ src, srclen);
+ disable_kernel_vsx();
+ pagefault_enable();
+ preempt_enable();
+ } else {
+ while (srclen >= GHASH_BLOCK_SIZE) {
+ crypto_xor((u8 *)dctx->shash, src, GHASH_BLOCK_SIZE);
+ gf128mul_lle((be128 *)dctx->shash, &ctx->key);
+ srclen -= GHASH_BLOCK_SIZE;
+ src += GHASH_BLOCK_SIZE;
+ }
+ }
}
static int p8_ghash_update(struct shash_desc *desc,
@@ -131,49 +121,33 @@ static int p8_ghash_update(struct shash_desc *desc,
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- if (IN_INTERRUPT) {
- return crypto_shash_update(&dctx->fallback_desc, src,
- srclen);
- } else {
- if (dctx->bytes) {
- if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
- memcpy(dctx->buffer + dctx->bytes, src,
- srclen);
- dctx->bytes += srclen;
- return 0;
- }
+ if (dctx->bytes) {
+ if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
memcpy(dctx->buffer + dctx->bytes, src,
- GHASH_DIGEST_SIZE - dctx->bytes);
- preempt_disable();
- pagefault_disable();
- enable_kernel_vsx();
- gcm_ghash_p8(dctx->shash, ctx->htable,
- dctx->buffer, GHASH_DIGEST_SIZE);
- disable_kernel_vsx();
- pagefault_enable();
- preempt_enable();
- src += GHASH_DIGEST_SIZE - dctx->bytes;
- srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
- dctx->bytes = 0;
- }
- len = srclen & ~(GHASH_DIGEST_SIZE - 1);
- if (len) {
- preempt_disable();
- pagefault_disable();
- enable_kernel_vsx();
- gcm_ghash_p8(dctx->shash, ctx->htable, src, len);
- disable_kernel_vsx();
- pagefault_enable();
- preempt_enable();
- src += len;
- srclen -= len;
- }
- if (srclen) {
- memcpy(dctx->buffer, src, srclen);
- dctx->bytes = srclen;
+ srclen);
+ dctx->bytes += srclen;
+ return 0;
}
- return 0;
+ memcpy(dctx->buffer + dctx->bytes, src,
+ GHASH_DIGEST_SIZE - dctx->bytes);
+
+ __ghash_block(ctx, dctx);
+
+ src += GHASH_DIGEST_SIZE - dctx->bytes;
+ srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
+ dctx->bytes = 0;
+ }
+ len = srclen & ~(GHASH_DIGEST_SIZE - 1);
+ if (len) {
+ __ghash_blocks(ctx, dctx, src, len);
+ src += len;
+ srclen -= len;
}
+ if (srclen) {
+ memcpy(dctx->buffer, src, srclen);
+ dctx->bytes = srclen;
+ }
+ return 0;
}
static int p8_ghash_final(struct shash_desc *desc, u8 *out)
@@ -182,25 +156,14 @@ static int p8_ghash_final(struct shash_desc *desc, u8 *out)
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- if (IN_INTERRUPT) {
- return crypto_shash_final(&dctx->fallback_desc, out);
- } else {
- if (dctx->bytes) {
- for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
- dctx->buffer[i] = 0;
- preempt_disable();
- pagefault_disable();
- enable_kernel_vsx();
- gcm_ghash_p8(dctx->shash, ctx->htable,
- dctx->buffer, GHASH_DIGEST_SIZE);
- disable_kernel_vsx();
- pagefault_enable();
- preempt_enable();
- dctx->bytes = 0;
- }
- memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
- return 0;
+ if (dctx->bytes) {
+ for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
+ dctx->buffer[i] = 0;
+ __ghash_block(ctx, dctx);
+ dctx->bytes = 0;
}
+ memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
+ return 0;
}
struct shash_alg p8_ghash_alg = {
@@ -215,11 +178,9 @@ struct shash_alg p8_ghash_alg = {
.cra_name = "ghash",
.cra_driver_name = "p8_ghash",
.cra_priority = 1000,
- .cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_NEED_FALLBACK,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = GHASH_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct p8_ghash_ctx),
.cra_module = THIS_MODULE,
- .cra_init = p8_ghash_init_tfm,
- .cra_exit = p8_ghash_exit_tfm,
},
};
--
2.19.1
^ permalink raw reply related
* [PATCH BACKPORT 4.4] crypto: vmx - ghash: do nosimd fallback manually
From: Daniel Axtens @ 2019-05-31 6:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Herbert Xu, stable, Daniel Axtens
VMX ghash was using a fallback that did not support interleaving simd
and nosimd operations, leading to failures in the extended test suite.
If I understood correctly, Eric's suggestion was to use the same
data format that the generic code uses, allowing us to call into it
with the same contexts. I wasn't able to get that to work - I think
there's a very different key structure and data layout being used.
So instead steal the arm64 approach and perform the fallback
operations directly if required.
Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: stable@vger.kernel.org # v4.1+
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(backported from commit 357d065a44cdd77ed5ff35155a989f2a763e96ef)
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
drivers/crypto/vmx/ghash.c | 218 +++++++++++++++----------------------
1 file changed, 89 insertions(+), 129 deletions(-)
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index 84b9389bf1ed..d6b68cf7bba7 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -1,22 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
/**
* GHASH routines supporting VMX instructions on the Power 8
*
- * Copyright (C) 2015 International Business Machines Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 only.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * Copyright (C) 2015, 2019 International Business Machines Inc.
*
* Author: Marcelo Henrique Cerri <mhcerri@br.ibm.com>
+ *
+ * Extended by Daniel Axtens <dja@axtens.net> to replace the fallback
+ * mechanism. The new approach is based on arm64 code, which is:
+ * Copyright (C) 2014 - 2018 Linaro Ltd. <ard.biesheuvel@linaro.org>
*/
#include <linux/types.h>
@@ -39,71 +31,25 @@ void gcm_ghash_p8(u64 Xi[2], const u128 htable[16],
const u8 *in, size_t len);
struct p8_ghash_ctx {
+ /* key used by vector asm */
u128 htable[16];
- struct crypto_shash *fallback;
+ /* key used by software fallback */
+ be128 key;
};
struct p8_ghash_desc_ctx {
u64 shash[2];
u8 buffer[GHASH_DIGEST_SIZE];
int bytes;
- struct shash_desc fallback_desc;
};
-static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
-{
- const char *alg = "ghash-generic";
- struct crypto_shash *fallback;
- struct crypto_shash *shash_tfm = __crypto_shash_cast(tfm);
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
-
- fallback = crypto_alloc_shash(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
- if (IS_ERR(fallback)) {
- printk(KERN_ERR
- "Failed to allocate transformation for '%s': %ld\n",
- alg, PTR_ERR(fallback));
- return PTR_ERR(fallback);
- }
-
- crypto_shash_set_flags(fallback,
- crypto_shash_get_flags((struct crypto_shash
- *) tfm));
-
- /* Check if the descsize defined in the algorithm is still enough. */
- if (shash_tfm->descsize < sizeof(struct p8_ghash_desc_ctx)
- + crypto_shash_descsize(fallback)) {
- printk(KERN_ERR
- "Desc size of the fallback implementation (%s) does not match the expected value: %lu vs %u\n",
- alg,
- shash_tfm->descsize - sizeof(struct p8_ghash_desc_ctx),
- crypto_shash_descsize(fallback));
- return -EINVAL;
- }
- ctx->fallback = fallback;
-
- return 0;
-}
-
-static void p8_ghash_exit_tfm(struct crypto_tfm *tfm)
-{
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
-
- if (ctx->fallback) {
- crypto_free_shash(ctx->fallback);
- ctx->fallback = NULL;
- }
-}
-
static int p8_ghash_init(struct shash_desc *desc)
{
- struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
dctx->bytes = 0;
memset(dctx->shash, 0, GHASH_DIGEST_SIZE);
- dctx->fallback_desc.tfm = ctx->fallback;
- dctx->fallback_desc.flags = desc->flags;
- return crypto_shash_init(&dctx->fallback_desc);
+ return 0;
}
static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
@@ -122,7 +68,53 @@ static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
gcm_init_p8(ctx->htable, (const u64 *) key);
pagefault_enable();
preempt_enable();
- return crypto_shash_setkey(ctx->fallback, key, keylen);
+
+ memcpy(&ctx->key, key, GHASH_BLOCK_SIZE);
+
+ return 0;
+}
+
+static inline void __ghash_block(struct p8_ghash_ctx *ctx,
+ struct p8_ghash_desc_ctx *dctx)
+{
+ if (!IN_INTERRUPT) {
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
+ enable_kernel_vsx();
+ enable_kernel_fp();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ dctx->buffer, GHASH_DIGEST_SIZE);
+ pagefault_enable();
+ preempt_enable();
+ } else {
+ crypto_xor((u8 *)dctx->shash, dctx->buffer, GHASH_BLOCK_SIZE);
+ gf128mul_lle((be128 *)dctx->shash, &ctx->key);
+ }
+}
+
+static inline void __ghash_blocks(struct p8_ghash_ctx *ctx,
+ struct p8_ghash_desc_ctx *dctx,
+ const u8 *src, unsigned int srclen)
+{
+ if (!IN_INTERRUPT) {
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
+ enable_kernel_vsx();
+ enable_kernel_fp();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ src, srclen);
+ pagefault_enable();
+ preempt_enable();
+ } else {
+ while (srclen >= GHASH_BLOCK_SIZE) {
+ crypto_xor((u8 *)dctx->shash, src, GHASH_BLOCK_SIZE);
+ gf128mul_lle((be128 *)dctx->shash, &ctx->key);
+ srclen -= GHASH_BLOCK_SIZE;
+ src += GHASH_BLOCK_SIZE;
+ }
+ }
}
static int p8_ghash_update(struct shash_desc *desc,
@@ -132,51 +124,33 @@ static int p8_ghash_update(struct shash_desc *desc,
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- if (IN_INTERRUPT) {
- return crypto_shash_update(&dctx->fallback_desc, src,
- srclen);
- } else {
- if (dctx->bytes) {
- if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
- memcpy(dctx->buffer + dctx->bytes, src,
- srclen);
- dctx->bytes += srclen;
- return 0;
- }
+ if (dctx->bytes) {
+ if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
memcpy(dctx->buffer + dctx->bytes, src,
- GHASH_DIGEST_SIZE - dctx->bytes);
- preempt_disable();
- pagefault_disable();
- enable_kernel_altivec();
- enable_kernel_vsx();
- enable_kernel_fp();
- gcm_ghash_p8(dctx->shash, ctx->htable,
- dctx->buffer, GHASH_DIGEST_SIZE);
- pagefault_enable();
- preempt_enable();
- src += GHASH_DIGEST_SIZE - dctx->bytes;
- srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
- dctx->bytes = 0;
- }
- len = srclen & ~(GHASH_DIGEST_SIZE - 1);
- if (len) {
- preempt_disable();
- pagefault_disable();
- enable_kernel_altivec();
- enable_kernel_vsx();
- enable_kernel_fp();
- gcm_ghash_p8(dctx->shash, ctx->htable, src, len);
- pagefault_enable();
- preempt_enable();
- src += len;
- srclen -= len;
- }
- if (srclen) {
- memcpy(dctx->buffer, src, srclen);
- dctx->bytes = srclen;
+ srclen);
+ dctx->bytes += srclen;
+ return 0;
}
- return 0;
+ memcpy(dctx->buffer + dctx->bytes, src,
+ GHASH_DIGEST_SIZE - dctx->bytes);
+
+ __ghash_block(ctx, dctx);
+
+ src += GHASH_DIGEST_SIZE - dctx->bytes;
+ srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
+ dctx->bytes = 0;
+ }
+ len = srclen & ~(GHASH_DIGEST_SIZE - 1);
+ if (len) {
+ __ghash_blocks(ctx, dctx, src, len);
+ src += len;
+ srclen -= len;
}
+ if (srclen) {
+ memcpy(dctx->buffer, src, srclen);
+ dctx->bytes = srclen;
+ }
+ return 0;
}
static int p8_ghash_final(struct shash_desc *desc, u8 *out)
@@ -185,26 +159,14 @@ static int p8_ghash_final(struct shash_desc *desc, u8 *out)
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- if (IN_INTERRUPT) {
- return crypto_shash_final(&dctx->fallback_desc, out);
- } else {
- if (dctx->bytes) {
- for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
- dctx->buffer[i] = 0;
- preempt_disable();
- pagefault_disable();
- enable_kernel_altivec();
- enable_kernel_vsx();
- enable_kernel_fp();
- gcm_ghash_p8(dctx->shash, ctx->htable,
- dctx->buffer, GHASH_DIGEST_SIZE);
- pagefault_enable();
- preempt_enable();
- dctx->bytes = 0;
- }
- memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
- return 0;
+ if (dctx->bytes) {
+ for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
+ dctx->buffer[i] = 0;
+ __ghash_block(ctx, dctx);
+ dctx->bytes = 0;
}
+ memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
+ return 0;
}
struct shash_alg p8_ghash_alg = {
@@ -219,11 +181,9 @@ struct shash_alg p8_ghash_alg = {
.cra_name = "ghash",
.cra_driver_name = "p8_ghash",
.cra_priority = 1000,
- .cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_NEED_FALLBACK,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = GHASH_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct p8_ghash_ctx),
.cra_module = THIS_MODULE,
- .cra_init = p8_ghash_init_tfm,
- .cra_exit = p8_ghash_exit_tfm,
},
};
--
2.19.1
^ permalink raw reply related
* Re: [PATCH BACKPORT 4.19, 5.0, 5.1] crypto: vmx - ghash: do nosimd fallback manually
From: Christophe Leroy @ 2019-05-31 8:36 UTC (permalink / raw)
To: Daniel Axtens; +Cc: linuxppc-dev, Herbert Xu, stable
In-Reply-To: <20190531062853.30957-1-dja@axtens.net>
Daniel Axtens <dja@axtens.net> a écrit :
Hi
I think you have to mention the upstream commit Id when submitting a
patch to stable, see
https://elixir.bootlin.com/linux/v5.2-rc1/source/Documentation/process/stable-kernel-rules.rst
Christophe
> VMX ghash was using a fallback that did not support interleaving simd
> and nosimd operations, leading to failures in the extended test suite.
>
> If I understood correctly, Eric's suggestion was to use the same
> data format that the generic code uses, allowing us to call into it
> with the same contexts. I wasn't able to get that to work - I think
> there's a very different key structure and data layout being used.
>
> So instead steal the arm64 approach and perform the fallback
> operations directly if required.
>
> Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
> Cc: stable@vger.kernel.org # v4.1+
> Reported-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> (backported from commit 357d065a44cdd77ed5ff35155a989f2a763e96ef)
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> ---
> drivers/crypto/vmx/ghash.c | 212 +++++++++++++++----------------------
> 1 file changed, 86 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
> index dd8b8716467a..2d1a8cd35509 100644
> --- a/drivers/crypto/vmx/ghash.c
> +++ b/drivers/crypto/vmx/ghash.c
> @@ -1,22 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0
> /**
> * GHASH routines supporting VMX instructions on the Power 8
> *
> - * Copyright (C) 2015 International Business Machines Inc.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; version 2 only.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + * Copyright (C) 2015, 2019 International Business Machines Inc.
> *
> * Author: Marcelo Henrique Cerri <mhcerri@br.ibm.com>
> + *
> + * Extended by Daniel Axtens <dja@axtens.net> to replace the fallback
> + * mechanism. The new approach is based on arm64 code, which is:
> + * Copyright (C) 2014 - 2018 Linaro Ltd. <ard.biesheuvel@linaro.org>
> */
>
> #include <linux/types.h>
> @@ -39,71 +31,25 @@ void gcm_ghash_p8(u64 Xi[2], const u128 htable[16],
> const u8 *in, size_t len);
>
> struct p8_ghash_ctx {
> + /* key used by vector asm */
> u128 htable[16];
> - struct crypto_shash *fallback;
> + /* key used by software fallback */
> + be128 key;
> };
>
> struct p8_ghash_desc_ctx {
> u64 shash[2];
> u8 buffer[GHASH_DIGEST_SIZE];
> int bytes;
> - struct shash_desc fallback_desc;
> };
>
> -static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
> -{
> - const char *alg = "ghash-generic";
> - struct crypto_shash *fallback;
> - struct crypto_shash *shash_tfm = __crypto_shash_cast(tfm);
> - struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - fallback = crypto_alloc_shash(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> - if (IS_ERR(fallback)) {
> - printk(KERN_ERR
> - "Failed to allocate transformation for '%s': %ld\n",
> - alg, PTR_ERR(fallback));
> - return PTR_ERR(fallback);
> - }
> -
> - crypto_shash_set_flags(fallback,
> - crypto_shash_get_flags((struct crypto_shash
> - *) tfm));
> -
> - /* Check if the descsize defined in the algorithm is still enough. */
> - if (shash_tfm->descsize < sizeof(struct p8_ghash_desc_ctx)
> - + crypto_shash_descsize(fallback)) {
> - printk(KERN_ERR
> - "Desc size of the fallback implementation (%s) does not
> match the expected value: %lu vs %u\n",
> - alg,
> - shash_tfm->descsize - sizeof(struct p8_ghash_desc_ctx),
> - crypto_shash_descsize(fallback));
> - return -EINVAL;
> - }
> - ctx->fallback = fallback;
> -
> - return 0;
> -}
> -
> -static void p8_ghash_exit_tfm(struct crypto_tfm *tfm)
> -{
> - struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - if (ctx->fallback) {
> - crypto_free_shash(ctx->fallback);
> - ctx->fallback = NULL;
> - }
> -}
> -
> static int p8_ghash_init(struct shash_desc *desc)
> {
> - struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
> struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
>
> dctx->bytes = 0;
> memset(dctx->shash, 0, GHASH_DIGEST_SIZE);
> - dctx->fallback_desc.tfm = ctx->fallback;
> - dctx->fallback_desc.flags = desc->flags;
> - return crypto_shash_init(&dctx->fallback_desc);
> + return 0;
> }
>
> static int p8_ghash_setkey(struct crypto_shash *tfm, const u8 *key,
> @@ -121,7 +67,51 @@ static int p8_ghash_setkey(struct crypto_shash
> *tfm, const u8 *key,
> disable_kernel_vsx();
> pagefault_enable();
> preempt_enable();
> - return crypto_shash_setkey(ctx->fallback, key, keylen);
> +
> + memcpy(&ctx->key, key, GHASH_BLOCK_SIZE);
> +
> + return 0;
> +}
> +
> +static inline void __ghash_block(struct p8_ghash_ctx *ctx,
> + struct p8_ghash_desc_ctx *dctx)
> +{
> + if (!IN_INTERRUPT) {
> + preempt_disable();
> + pagefault_disable();
> + enable_kernel_vsx();
> + gcm_ghash_p8(dctx->shash, ctx->htable,
> + dctx->buffer, GHASH_DIGEST_SIZE);
> + disable_kernel_vsx();
> + pagefault_enable();
> + preempt_enable();
> + } else {
> + crypto_xor((u8 *)dctx->shash, dctx->buffer, GHASH_BLOCK_SIZE);
> + gf128mul_lle((be128 *)dctx->shash, &ctx->key);
> + }
> +}
> +
> +static inline void __ghash_blocks(struct p8_ghash_ctx *ctx,
> + struct p8_ghash_desc_ctx *dctx,
> + const u8 *src, unsigned int srclen)
> +{
> + if (!IN_INTERRUPT) {
> + preempt_disable();
> + pagefault_disable();
> + enable_kernel_vsx();
> + gcm_ghash_p8(dctx->shash, ctx->htable,
> + src, srclen);
> + disable_kernel_vsx();
> + pagefault_enable();
> + preempt_enable();
> + } else {
> + while (srclen >= GHASH_BLOCK_SIZE) {
> + crypto_xor((u8 *)dctx->shash, src, GHASH_BLOCK_SIZE);
> + gf128mul_lle((be128 *)dctx->shash, &ctx->key);
> + srclen -= GHASH_BLOCK_SIZE;
> + src += GHASH_BLOCK_SIZE;
> + }
> + }
> }
>
> static int p8_ghash_update(struct shash_desc *desc,
> @@ -131,49 +121,33 @@ static int p8_ghash_update(struct shash_desc *desc,
> struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
> struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
>
> - if (IN_INTERRUPT) {
> - return crypto_shash_update(&dctx->fallback_desc, src,
> - srclen);
> - } else {
> - if (dctx->bytes) {
> - if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
> - memcpy(dctx->buffer + dctx->bytes, src,
> - srclen);
> - dctx->bytes += srclen;
> - return 0;
> - }
> + if (dctx->bytes) {
> + if (dctx->bytes + srclen < GHASH_DIGEST_SIZE) {
> memcpy(dctx->buffer + dctx->bytes, src,
> - GHASH_DIGEST_SIZE - dctx->bytes);
> - preempt_disable();
> - pagefault_disable();
> - enable_kernel_vsx();
> - gcm_ghash_p8(dctx->shash, ctx->htable,
> - dctx->buffer, GHASH_DIGEST_SIZE);
> - disable_kernel_vsx();
> - pagefault_enable();
> - preempt_enable();
> - src += GHASH_DIGEST_SIZE - dctx->bytes;
> - srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
> - dctx->bytes = 0;
> - }
> - len = srclen & ~(GHASH_DIGEST_SIZE - 1);
> - if (len) {
> - preempt_disable();
> - pagefault_disable();
> - enable_kernel_vsx();
> - gcm_ghash_p8(dctx->shash, ctx->htable, src, len);
> - disable_kernel_vsx();
> - pagefault_enable();
> - preempt_enable();
> - src += len;
> - srclen -= len;
> - }
> - if (srclen) {
> - memcpy(dctx->buffer, src, srclen);
> - dctx->bytes = srclen;
> + srclen);
> + dctx->bytes += srclen;
> + return 0;
> }
> - return 0;
> + memcpy(dctx->buffer + dctx->bytes, src,
> + GHASH_DIGEST_SIZE - dctx->bytes);
> +
> + __ghash_block(ctx, dctx);
> +
> + src += GHASH_DIGEST_SIZE - dctx->bytes;
> + srclen -= GHASH_DIGEST_SIZE - dctx->bytes;
> + dctx->bytes = 0;
> + }
> + len = srclen & ~(GHASH_DIGEST_SIZE - 1);
> + if (len) {
> + __ghash_blocks(ctx, dctx, src, len);
> + src += len;
> + srclen -= len;
> }
> + if (srclen) {
> + memcpy(dctx->buffer, src, srclen);
> + dctx->bytes = srclen;
> + }
> + return 0;
> }
>
> static int p8_ghash_final(struct shash_desc *desc, u8 *out)
> @@ -182,25 +156,14 @@ static int p8_ghash_final(struct shash_desc
> *desc, u8 *out)
> struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(desc->tfm));
> struct p8_ghash_desc_ctx *dctx = shash_desc_ctx(desc);
>
> - if (IN_INTERRUPT) {
> - return crypto_shash_final(&dctx->fallback_desc, out);
> - } else {
> - if (dctx->bytes) {
> - for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
> - dctx->buffer[i] = 0;
> - preempt_disable();
> - pagefault_disable();
> - enable_kernel_vsx();
> - gcm_ghash_p8(dctx->shash, ctx->htable,
> - dctx->buffer, GHASH_DIGEST_SIZE);
> - disable_kernel_vsx();
> - pagefault_enable();
> - preempt_enable();
> - dctx->bytes = 0;
> - }
> - memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
> - return 0;
> + if (dctx->bytes) {
> + for (i = dctx->bytes; i < GHASH_DIGEST_SIZE; i++)
> + dctx->buffer[i] = 0;
> + __ghash_block(ctx, dctx);
> + dctx->bytes = 0;
> }
> + memcpy(out, dctx->shash, GHASH_DIGEST_SIZE);
> + return 0;
> }
>
> struct shash_alg p8_ghash_alg = {
> @@ -215,11 +178,8 @@ struct shash_alg p8_ghash_alg = {
> .cra_name = "ghash",
> .cra_driver_name = "p8_ghash",
> .cra_priority = 1000,
> - .cra_flags = CRYPTO_ALG_NEED_FALLBACK,
> .cra_blocksize = GHASH_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct p8_ghash_ctx),
> .cra_module = THIS_MODULE,
> - .cra_init = p8_ghash_init_tfm,
> - .cra_exit = p8_ghash_exit_tfm,
> },
> };
> --
> 2.19.1
^ permalink raw reply
* Re: [RFC] mm: Generalize notify_page_fault()
From: Anshuman Khandual @ 2019-05-31 8:47 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mark Rutland, Michal Hocko, linux-ia64, linux-sh, Catalin Marinas,
Will Deacon, linux-mm, Paul Mackerras, sparclinux, linux-s390,
Yoshinori Sato, Russell King, Fenghua Yu, Stephen Rothwell,
Andrey Konovalov, linux-arm-kernel, Tony Luck, Heiko Carstens,
linux-kernel, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20190530133954.GA2024@bombadil.infradead.org>
On 05/30/2019 07:09 PM, Matthew Wilcox wrote:
> On Thu, May 30, 2019 at 05:31:15PM +0530, Anshuman Khandual wrote:
>> On 05/30/2019 04:36 PM, Matthew Wilcox wrote:
>>> The two handle preemption differently. Why is x86 wrong and this one
>>> correct?
>>
>> Here it expects context to be already non-preemptible where as the proposed
>> generic function makes it non-preemptible with a preempt_[disable|enable]()
>> pair for the required code section, irrespective of it's present state. Is
>> not this better ?
>
> git log -p arch/x86/mm/fault.c
>
> search for 'kprobes'.
>
> tell me what you think.
>
Are you referring to these following commits
a980c0ef9f6d ("x86/kprobes: Refactor kprobes_fault() like kprobe_exceptions_notify()")
b506a9d08bae ("x86: code clarification patch to Kprobes arch code")
In particular the later one (b506a9d08bae). It explains how the invoking context
in itself should be non-preemptible for the kprobes processing context irrespective
of whether kprobe_running() or perhaps smp_processor_id() is safe or not. Hence it
does not make much sense to continue when original invoking context is preemptible.
Instead just bail out earlier. This seems to be making more sense than preempt
disable-enable pair. If there are no concerns about this change from other platforms,
I will change the preemption behavior in proposed generic function next time around.
^ permalink raw reply
* Re: [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options
From: Leizhen (ThunderTown) @ 2019-05-31 10:03 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Linuxarm, Hanjun Guo
In-Reply-To: <645bd526-4eb0-4a36-2dda-023f009247ab@huawei.com>
On 2019/5/30 20:20, John Garry wrote:
> On 30/05/2019 04:48, Zhen Lei wrote:
>> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
>> opportunity to set {lazy|strict} mode as default at build time. Then put
>> the three config options in an choice, make people can only choose one of
>> the three at a time.
>>
>
> Since this was not picked up, but modulo (somtimes same) comments below:
>
> Reviewed-by: John Garry <john.garry@huawei.com>
>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> drivers/iommu/Kconfig | 42 +++++++++++++++++++++++++++++++++++-------
>> drivers/iommu/iommu.c | 3 ++-
>> 2 files changed, 37 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index 83664db5221df02..d6a1a45f80ffbf5 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -75,17 +75,45 @@ config IOMMU_DEBUGFS
>> debug/iommu directory, and then populate a subdirectory with
>> entries as required.
>>
>> -config IOMMU_DEFAULT_PASSTHROUGH
>> - bool "IOMMU passthrough by default"
>> +choice
>> + prompt "IOMMU default DMA mode"
>> depends on IOMMU_API
>> - help
>> - Enable passthrough by default, removing the need to pass in
>> - iommu.passthrough=on or iommu=pt through command line. If this
>> - is enabled, you can still disable with iommu.passthrough=off
>> - or iommu=nopt depending on the architecture.
>> + default IOMMU_DEFAULT_STRICT
>> + help
>> + This option allows IOMMU DMA mode to be chose at build time, to
>
> As before:
> /s/chose/chosen/, /s/allows IOMMU/allows an IOMMU/
I'm sorry that the previous version was not modified.
>
>> + override the default DMA mode of each ARCHs, removing the need to
>
> Again, as before:
> ARCHs should be singular
OK
>
>> + pass in kernel parameters through command line. You can still use
>> + ARCHs specific boot options to override this option again.
>> +
>> +config IOMMU_DEFAULT_PASSTHROUGH
>> + bool "passthrough"
>> + help
>> + In this mode, the DMA access through IOMMU without any addresses
>> + translation. That means, the wrong or illegal DMA access can not
>> + be caught, no error information will be reported.
>>
>> If unsure, say N here.
>>
>> +config IOMMU_DEFAULT_LAZY
>> + bool "lazy"
>> + help
>> + Support lazy mode, where for every IOMMU DMA unmap operation, the
>> + flush operation of IOTLB and the free operation of IOVA are deferred.
>> + They are only guaranteed to be done before the related IOVA will be
>> + reused.
>
> why no advisory on how to set if unsure?
Because the LAZY and STRICT have their own advantages and disadvantages.
Should I say: If unsure, keep the default。
>
>> +
>> +config IOMMU_DEFAULT_STRICT
>> + bool "strict"
>> + help
>> + For every IOMMU DMA unmap operation, the flush operation of IOTLB and
>> + the free operation of IOVA are guaranteed to be done in the unmap
>> + function.
>> +
>> + This mode is safer than the two above, but it maybe slower in some
>> + high performace scenarios.
>
> and here?
>
>> +
>> +endchoice
>> +
>> config OF_IOMMU
>> def_bool y
>> depends on OF && IOMMU_API
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 67ee6623f9b2a4d..56bce221285b15f 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -43,7 +43,8 @@
>> #else
>> static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
>> #endif
>> -static bool iommu_dma_strict __read_mostly = true;
>> +static bool iommu_dma_strict __read_mostly =
>> + IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
>>
>> struct iommu_group {
>> struct kobject kobj;
>>
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options
From: John Garry @ 2019-05-31 10:42 UTC (permalink / raw)
To: Leizhen (ThunderTown), Jean-Philippe Brucker, Robin Murphy,
Will Deacon, Joerg Roedel, Jonathan Corbet, linux-doc,
Sebastian Ott, Gerald Schaefer, Martin Schwidefsky,
Heiko Carstens, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Tony Luck, Fenghua Yu, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, David Woodhouse,
iommu, linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Linuxarm, Hanjun Guo
In-Reply-To: <030bafab-58f5-8bb1-0533-2977d6e138b2@huawei.com>
>>> -config IOMMU_DEFAULT_PASSTHROUGH
>>> - bool "IOMMU passthrough by default"
>>> +choice
>>> + prompt "IOMMU default DMA mode"
>>> depends on IOMMU_API
>>> - help
>>> - Enable passthrough by default, removing the need to pass in
>>> - iommu.passthrough=on or iommu=pt through command line. If this
>>> - is enabled, you can still disable with iommu.passthrough=off
>>> - or iommu=nopt depending on the architecture.
>>> + default IOMMU_DEFAULT_STRICT
>>> + help
>>> + This option allows IOMMU DMA mode to be chose at build time, to
>>
>> As before:
>> /s/chose/chosen/, /s/allows IOMMU/allows an IOMMU/
> I'm sorry that the previous version was not modified.
>
>>
>>> + override the default DMA mode of each ARCHs, removing the need to
>>
>> Again, as before:
>> ARCHs should be singular
> OK
>
>>
>>> + pass in kernel parameters through command line. You can still use
>>> + ARCHs specific boot options to override this option again.
*
>>> +
>>> +config IOMMU_DEFAULT_PASSTHROUGH
>>> + bool "passthrough"
>>> + help
>>> + In this mode, the DMA access through IOMMU without any addresses
>>> + translation. That means, the wrong or illegal DMA access can not
>>> + be caught, no error information will be reported.
>>>
>>> If unsure, say N here.
>>>
>>> +config IOMMU_DEFAULT_LAZY
>>> + bool "lazy"
>>> + help
>>> + Support lazy mode, where for every IOMMU DMA unmap operation, the
>>> + flush operation of IOTLB and the free operation of IOVA are deferred.
>>> + They are only guaranteed to be done before the related IOVA will be
>>> + reused.
>>
>> why no advisory on how to set if unsure?
> Because the LAZY and STRICT have their own advantages and disadvantages.
>
> Should I say: If unsure, keep the default。
Maybe. So you could put this in the help for the choice, * above, and
remove the advisory on IOMMU_DEFAULT_PASSTHROUGH.
However the maintainer may have a different view.
Thanks,
John
>
>>
>>> +
>>> +config IOMMU_DEFAULT_STRICT
>>> + bool "strict"
>>> + help
>>> + For every IOMMU DMA unmap operation, the flush operation of IOTLB and
>>> + the free operation of IOVA are guaranteed to be done in the unmap
>>> + function.
>>> +
>>> + This mode is safer than the two above, but it maybe slower in some
>>> + high performace scenarios.
>>
>> and here?
^ permalink raw reply
* [next-20190530] Boot failure on PowerPC
From: Sachin Sant @ 2019-05-31 13:00 UTC (permalink / raw)
To: linuxppc-dev, linux-next
Latest next fails to boot with a kernel panic on POWER9.
[ 33.689332] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: write_irq_affinity.isra.5+0x15c/0x160
[ 33.689346] CPU: 35 PID: 4907 Comm: irqbalance Not tainted 5.2.0-rc2-next-20190530-autotest-autotest #1
[ 33.689352] Call Trace:
[ 33.689356] [c0000018d974bab0] [c000000000b5328c] dump_stack+0xb0/0xf4 (unreliable)
[ 33.689364] [c0000018d974baf0] [c000000000120694] panic+0x16c/0x408
[ 33.689370] [c0000018d974bb80] [c00000000012010c] __stack_chk_fail+0x2c/0x30
[ 33.689376] [c0000018d974bbe0] [c0000000001b859c] write_irq_affinity.isra.5+0x15c/0x160
[ 33.689383] [c0000018d974bd30] [c0000000004d6f30] proc_reg_write+0x90/0x110
[ 33.689388] [c0000018d974bd60] [c00000000041453c] __vfs_write+0x3c/0x70
[ 33.689394] [c0000018d974bd80] [c000000000418650] vfs_write+0xd0/0x250
[ 33.689399] [c0000018d974bdd0] [c000000000418a2c] ksys_write+0x7c/0x130
[ 33.689405] [c0000018d974be20] [c00000000000b688] system_call+0x5c/0x70
Machine boots till login prompt and then panics few seconds later.
Last known next build was May 24th. Will attempt few builds till May 30 to
narrow down this problem.
Thanks
-Sachin
^ permalink raw reply
* RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: Laurentiu Tudor @ 2019-05-31 13:09 UTC (permalink / raw)
To: David Miller
Cc: Madalin-cristian Bucur, netdev@vger.kernel.org, Roy Pledge,
linux-kernel@vger.kernel.org, Leo Li,
iommu@lists.linux-foundation.org, Camelia Alexandra Groza,
u.kleine-koenig@pengutronix.de, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190530.150844.1826796344374758568.davem@davemloft.net>
Hello,
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Friday, May 31, 2019 1:09 AM
>
> From: laurentiu.tudor@nxp.com
> Date: Thu, 30 May 2019 17:19:45 +0300
>
> > Depends on this pull request:
> >
> >
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
>
> I'm not sure how you want me to handle this.
Dave, would it make sense / be possible to also pick Leo's PR through your tree?
---
Thanks & Best Regards, Laurentiu
^ permalink raw reply
* Re: [next-20190530] Boot failure on PowerPC
From: Michael Ellerman @ 2019-05-31 13:52 UTC (permalink / raw)
To: Sachin Sant, linuxppc-dev, linux-next
In-Reply-To: <79EEB945-661A-41AD-8B26-2FD3B3F84697@linux.vnet.ibm.com>
Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
> Latest next fails to boot with a kernel panic on POWER9.
>
> [ 33.689332] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: write_irq_affinity.isra.5+0x15c/0x160
> [ 33.689346] CPU: 35 PID: 4907 Comm: irqbalance Not tainted 5.2.0-rc2-next-20190530-autotest-autotest #1
> [ 33.689352] Call Trace:
> [ 33.689356] [c0000018d974bab0] [c000000000b5328c] dump_stack+0xb0/0xf4 (unreliable)
> [ 33.689364] [c0000018d974baf0] [c000000000120694] panic+0x16c/0x408
> [ 33.689370] [c0000018d974bb80] [c00000000012010c] __stack_chk_fail+0x2c/0x30
> [ 33.689376] [c0000018d974bbe0] [c0000000001b859c] write_irq_affinity.isra.5+0x15c/0x160
> [ 33.689383] [c0000018d974bd30] [c0000000004d6f30] proc_reg_write+0x90/0x110
> [ 33.689388] [c0000018d974bd60] [c00000000041453c] __vfs_write+0x3c/0x70
> [ 33.689394] [c0000018d974bd80] [c000000000418650] vfs_write+0xd0/0x250
> [ 33.689399] [c0000018d974bdd0] [c000000000418a2c] ksys_write+0x7c/0x130
> [ 33.689405] [c0000018d974be20] [c00000000000b688] system_call+0x5c/0x70
>
> Machine boots till login prompt and then panics few seconds later.
>
> Last known next build was May 24th. Will attempt few builds till May 30 to
> narrow down this problem.
My CI was fine with next-20190529 (9a15d2e3fd03e3).
cheers
^ permalink raw reply
* Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Michael Ellerman @ 2019-05-31 15:13 UTC (permalink / raw)
To: Jonathan Corbet, Bhupesh Sharma
Cc: Arnd Bergmann, linux-doc, Linux Kernel Mailing List,
Paul Mackerras, Bhupesh SHARMA, linuxppc-dev
In-Reply-To: <20190530081358.650930ad@lwn.net>
Jonathan Corbet <corbet@lwn.net> writes:
> On Thu, 30 May 2019 18:37:46 +0530
> Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
>> > This should probably go via the documentation tree?
>> >
>> > Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>>
>> Thanks for the review Michael.
>> I am ok with this going through the documentation tree as well.
>
> Works for me too, but I don't seem to find the actual patch anywhere I
> look. Can you send me a copy?
You can get it from lore:
https://lore.kernel.org/linuxppc-dev/1559212177-7072-1-git-send-email-bhsharma@redhat.com/raw
Or patchwork (automatically adds my ack):
https://patchwork.ozlabs.org/patch/1107706/mbox/
Or Bhupesh can send it to you :)
cheers
^ permalink raw reply
* Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: Andreas Färber @ 2019-05-31 16:15 UTC (permalink / raw)
To: laurentiu.tudor
Cc: madalin.bucur, netdev, roy.pledge, linux-kernel, leoyang.li,
iommu, camelia.groza, Mian Yousaf Kaukab, linuxppc-dev, davem,
linux-arm-kernel
In-Reply-To: <20190530141951.6704-1-laurentiu.tudor@nxp.com>
Hi Laurentiu,
Am 30.05.19 um 16:19 schrieb laurentiu.tudor@nxp.com:
> This patch series contains several fixes in preparation for SMMU
> support on NXP LS1043A and LS1046A chips. Once these get picked up,
> I'll submit the actual SMMU enablement patches consisting in the
> required device tree changes.
Have you thought through what will happen if this patch ordering is not
preserved? In particular, a user installing a future U-Boot update with
the DTB bits but booting a stable kernel without this patch series -
wouldn't that regress dpaa then for our customers?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
From: Christoph Hellwig @ 2019-05-31 16:32 UTC (permalink / raw)
To: laurentiu.tudor
Cc: madalin.bucur, netdev, roy.pledge, linux-kernel, leoyang.li,
iommu, camelia.groza, linuxppc-dev, davem, linux-arm-kernel
In-Reply-To: <20190530141951.6704-6-laurentiu.tudor@nxp.com>
On Thu, May 30, 2019 at 05:19:50PM +0300, laurentiu.tudor@nxp.com wrote:
> +static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv,
> + dma_addr_t addr)
> +{
> + return priv->domain ? iommu_iova_to_phys(priv->domain, addr) : addr;
> +}
Again, a driver using the iommu API must not call iommu_* APIs.
This chane is not acceptable.
^ permalink raw reply
* Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: Christoph Hellwig @ 2019-05-31 16:33 UTC (permalink / raw)
To: David Miller
Cc: madalin.bucur, netdev, roy.pledge, linux-kernel, leoyang.li,
iommu, camelia.groza, linuxppc-dev, linux-arm-kernel,
laurentiu.tudor
In-Reply-To: <20190530.150844.1826796344374758568.davem@davemloft.net>
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
> From: laurentiu.tudor@nxp.com
> Date: Thu, 30 May 2019 17:19:45 +0300
>
> > Depends on this pull request:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
>
> I'm not sure how you want me to handle this.
The thing needs to be completely redone as it abuses parts of the
iommu API in a completely unacceptable way.
^ permalink raw reply
* RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: Laurentiu Tudor @ 2019-05-31 16:46 UTC (permalink / raw)
To: Andreas Färber
Cc: Madalin-cristian Bucur, netdev@vger.kernel.org, Roy Pledge,
linux-kernel@vger.kernel.org, Leo Li,
iommu@lists.linux-foundation.org, Camelia Alexandra Groza,
Mian Yousaf Kaukab, linuxppc-dev@lists.ozlabs.org,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <d086216f-f3fc-c88a-3891-81e84e8bdb01@suse.de>
Hello Andreas,
> -----Original Message-----
> From: Andreas Färber <afaerber@suse.de>
> Sent: Friday, May 31, 2019 7:15 PM
>
> Hi Laurentiu,
>
> Am 30.05.19 um 16:19 schrieb laurentiu.tudor@nxp.com:
> > This patch series contains several fixes in preparation for SMMU
> > support on NXP LS1043A and LS1046A chips. Once these get picked up,
> > I'll submit the actual SMMU enablement patches consisting in the
> > required device tree changes.
>
> Have you thought through what will happen if this patch ordering is not
> preserved? In particular, a user installing a future U-Boot update with
> the DTB bits but booting a stable kernel without this patch series -
> wouldn't that regress dpaa then for our customers?
>
These are fixes for issues that popped out after enabling SMMU.
I do not expect them to break anything.
---
Best Regards, Laurentiu
^ permalink raw reply
* RE: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
From: Laurentiu Tudor @ 2019-05-31 16:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Madalin-cristian Bucur, netdev@vger.kernel.org, Roy Pledge,
linux-kernel@vger.kernel.org, Leo Li,
iommu@lists.linux-foundation.org, Camelia Alexandra Groza,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190531163229.GA8708@infradead.org>
Hi Christoph,
> -----Original Message-----
> From: Christoph Hellwig <hch@infradead.org>
> Sent: Friday, May 31, 2019 7:32 PM
>
> On Thu, May 30, 2019 at 05:19:50PM +0300, laurentiu.tudor@nxp.com wrote:
> > +static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv,
> > + dma_addr_t addr)
> > +{
> > + return priv->domain ? iommu_iova_to_phys(priv->domain, addr) : addr;
> > +}
>
> Again, a driver using the iommu API must not call iommu_* APIs.
>
> This chane is not acceptable.
Unfortunately due to our hardware particularities we do not have alternatives. This is also the case for our next generation of ethernet drivers [1]. I'll let my colleagues that work on the ethernet drivers to comment more on this.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c#n37
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
From: Christoph Hellwig @ 2019-05-31 16:55 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: Madalin-cristian Bucur, netdev@vger.kernel.org, Roy Pledge,
linux-kernel@vger.kernel.org, Leo Li, Christoph Hellwig,
iommu@lists.linux-foundation.org, Camelia Alexandra Groza,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB5134F5E31B993B2DC5275BB3EC190@VI1PR04MB5134.eurprd04.prod.outlook.com>
On Fri, May 31, 2019 at 04:53:16PM +0000, Laurentiu Tudor wrote:
> Unfortunately due to our hardware particularities we do not have alternatives. This is also the case for our next generation of ethernet drivers [1]. I'll let my colleagues that work on the ethernet drivers to comment more on this.
Then you need to enhance the DMA API to support your use case instead
of using an API only supported for two specific IOMMU implementations.
Remember in Linux you can should improve core code and not hack around
it in crappy ways making lots of assumptions in your drivers.
^ permalink raw reply
* RE: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
From: Laurentiu Tudor @ 2019-05-31 17:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Madalin-cristian Bucur, netdev@vger.kernel.org, Roy Pledge,
linux-kernel@vger.kernel.org, Leo Li,
iommu@lists.linux-foundation.org, Camelia Alexandra Groza,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190531165530.GA16487@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig <hch@infradead.org>
> Sent: Friday, May 31, 2019 7:56 PM
>
> On Fri, May 31, 2019 at 04:53:16PM +0000, Laurentiu Tudor wrote:
> > Unfortunately due to our hardware particularities we do not have
> alternatives. This is also the case for our next generation of ethernet
> drivers [1]. I'll let my colleagues that work on the ethernet drivers to
> comment more on this.
>
> Then you need to enhance the DMA API to support your use case instead
> of using an API only supported for two specific IOMMU implementations.
>
> Remember in Linux you can should improve core code and not hack around
> it in crappy ways making lots of assumptions in your drivers.
Alright, I'm ok with that. I'll try to come up with something, will keep you in the loop.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: Robin Murphy @ 2019-05-31 17:03 UTC (permalink / raw)
To: Christoph Hellwig, David Miller
Cc: madalin.bucur, netdev, roy.pledge, linux-kernel, leoyang.li,
iommu, camelia.groza, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190531163350.GB8708@infradead.org>
On 31/05/2019 17:33, Christoph Hellwig wrote:
> On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
>> From: laurentiu.tudor@nxp.com
>> Date: Thu, 30 May 2019 17:19:45 +0300
>>
>>> Depends on this pull request:
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
>>
>> I'm not sure how you want me to handle this.
>
> The thing needs to be completely redone as it abuses parts of the
> iommu API in a completely unacceptable way.
`git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
:(
I guess one alternative is for the offending drivers to maintain their
own lookup tables of mapped DMA addresses - I think at least some of
these things allow storing some kind of token in a descriptor, which
even if it's not big enough for a virtual address might be sufficient
for an index.
Robin.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox