February 2021 - Linux-stable-mirror

[PATCH] Revert "dts: phy: add GPIO number and active state used for phy reset"

by Palmer Dabbelt

From: Palmer Dabbelt <palmerdabbelt(a)google.com> VSC8541 phys need a special reset sequence, which the driver doesn't currentlny support. As a result enabling the reset via GPIO essentially guarnteees that the device won't work correctly. This reverts commit a0fa9d727043da2238432471e85de0bdb8a8df65. Fixes: a0fa9d727043 ("dts: phy: add GPIO number and active state used for phy reset") Cc: stable(a)vger.kernel.org Signed-off-by: Palmer Dabbelt <palmerdabbelt(a)google.com> --- arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts index 24d75a146e02..60846e88ae4b 100644 --- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts +++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts @@ -90,7 +90,6 @@ &eth0 { phy0: ethernet-phy@0 { compatible = "ethernet-phy-id0007.0771"; reg = <0>; - reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>; }; }; -- 2.30.0.478.g8a0d178c01-goog

3 years, 8 months

2
2
0 0

FAILED: patch "[PATCH] usb: dwc3: ulpi: Replace CPU-based busyloop with" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fca3f138105727c3a22edda32d02f91ce1bf11c9 Mon Sep 17 00:00:00 2001 From: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Date: Thu, 10 Dec 2020 11:50:07 +0300 Subject: [PATCH] usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one Originally the procedure of the ULPI transaction finish detection has been developed as a simple busy-loop with just decrementing counter and no delays. It's wrong since on different systems the loop will take a different time to complete. So if the system bus and CPU are fast enough to overtake the ULPI bus and the companion PHY reaction, then we'll get to take a false timeout error. Fix this by converting the busy-loop procedure to take the standard bus speed, address value and the registers access mode into account for the busy-loop delay calculation. Here is the way the fix works. It's known that the ULPI bus is clocked with 60MHz signal. In accordance with [1] the ULPI bus protocol is created so to spend 5 and 6 clock periods for immediate register write and read operations respectively, and 6 and 7 clock periods - for the extended register writes and reads. Based on that we can easily pre-calculate the time which will be needed for the controller to perform a requested IO operation. Note we'll still preserve the attempts counter in case if the DWC USB3 controller has got some internals delays. [1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1, October 20, 2004, pp. 30 - 36. Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support") Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-3-Sergey.Semin@baikalelectro… Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c index 3cc4f4970c05..54c877f7b51d 100644 --- a/drivers/usb/dwc3/ulpi.c +++ b/drivers/usb/dwc3/ulpi.c @@ -7,6 +7,8 @@ * Author: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> */ +#include <linux/delay.h> +#include <linux/time64.h> #include <linux/ulpi/regs.h> #include "core.h" @@ -17,12 +19,22 @@ DWC3_GUSB2PHYACC_ADDR(ULPI_ACCESS_EXTENDED) | \ DWC3_GUSB2PHYACC_EXTEND_ADDR(a) : DWC3_GUSB2PHYACC_ADDR(a)) -static int dwc3_ulpi_busyloop(struct dwc3 *dwc) +#define DWC3_ULPI_BASE_DELAY DIV_ROUND_UP(NSEC_PER_SEC, 60000000L) + +static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr, bool read) { + unsigned long ns = 5L * DWC3_ULPI_BASE_DELAY; unsigned int count = 1000; u32 reg; + if (addr >= ULPI_EXT_VENDOR_SPECIFIC) + ns += DWC3_ULPI_BASE_DELAY; + + if (read) + ns += DWC3_ULPI_BASE_DELAY; + while (count--) { + ndelay(ns); reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYACC(0)); if (reg & DWC3_GUSB2PHYACC_DONE) return 0; @@ -47,7 +59,7 @@ static int dwc3_ulpi_read(struct device *dev, u8 addr) reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr); dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg); - ret = dwc3_ulpi_busyloop(dwc); + ret = dwc3_ulpi_busyloop(dwc, addr, true); if (ret) return ret; @@ -71,7 +83,7 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 val) reg |= DWC3_GUSB2PHYACC_WRITE | val; dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg); - return dwc3_ulpi_busyloop(dwc); + return dwc3_ulpi_busyloop(dwc, addr, false); } static const struct ulpi_ops dwc3_ulpi_ops = {

3 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] usb: dwc3: ulpi: Replace CPU-based busyloop with" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fca3f138105727c3a22edda32d02f91ce1bf11c9 Mon Sep 17 00:00:00 2001 From: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Date: Thu, 10 Dec 2020 11:50:07 +0300 Subject: [PATCH] usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one Originally the procedure of the ULPI transaction finish detection has been developed as a simple busy-loop with just decrementing counter and no delays. It's wrong since on different systems the loop will take a different time to complete. So if the system bus and CPU are fast enough to overtake the ULPI bus and the companion PHY reaction, then we'll get to take a false timeout error. Fix this by converting the busy-loop procedure to take the standard bus speed, address value and the registers access mode into account for the busy-loop delay calculation. Here is the way the fix works. It's known that the ULPI bus is clocked with 60MHz signal. In accordance with [1] the ULPI bus protocol is created so to spend 5 and 6 clock periods for immediate register write and read operations respectively, and 6 and 7 clock periods - for the extended register writes and reads. Based on that we can easily pre-calculate the time which will be needed for the controller to perform a requested IO operation. Note we'll still preserve the attempts counter in case if the DWC USB3 controller has got some internals delays. [1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1, October 20, 2004, pp. 30 - 36. Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support") Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-3-Sergey.Semin@baikalelectro… Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c index 3cc4f4970c05..54c877f7b51d 100644 --- a/drivers/usb/dwc3/ulpi.c +++ b/drivers/usb/dwc3/ulpi.c @@ -7,6 +7,8 @@ * Author: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> */ +#include <linux/delay.h> +#include <linux/time64.h> #include <linux/ulpi/regs.h> #include "core.h" @@ -17,12 +19,22 @@ DWC3_GUSB2PHYACC_ADDR(ULPI_ACCESS_EXTENDED) | \ DWC3_GUSB2PHYACC_EXTEND_ADDR(a) : DWC3_GUSB2PHYACC_ADDR(a)) -static int dwc3_ulpi_busyloop(struct dwc3 *dwc) +#define DWC3_ULPI_BASE_DELAY DIV_ROUND_UP(NSEC_PER_SEC, 60000000L) + +static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr, bool read) { + unsigned long ns = 5L * DWC3_ULPI_BASE_DELAY; unsigned int count = 1000; u32 reg; + if (addr >= ULPI_EXT_VENDOR_SPECIFIC) + ns += DWC3_ULPI_BASE_DELAY; + + if (read) + ns += DWC3_ULPI_BASE_DELAY; + while (count--) { + ndelay(ns); reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYACC(0)); if (reg & DWC3_GUSB2PHYACC_DONE) return 0; @@ -47,7 +59,7 @@ static int dwc3_ulpi_read(struct device *dev, u8 addr) reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr); dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg); - ret = dwc3_ulpi_busyloop(dwc); + ret = dwc3_ulpi_busyloop(dwc, addr, true); if (ret) return ret; @@ -71,7 +83,7 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 val) reg |= DWC3_GUSB2PHYACC_WRITE | val; dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg); - return dwc3_ulpi_busyloop(dwc); + return dwc3_ulpi_busyloop(dwc, addr, false); } static const struct ulpi_ops dwc3_ulpi_ops = {

3 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] usb: dwc3: ulpi: Replace CPU-based busyloop with" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fca3f138105727c3a22edda32d02f91ce1bf11c9 Mon Sep 17 00:00:00 2001 From: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Date: Thu, 10 Dec 2020 11:50:07 +0300 Subject: [PATCH] usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one Originally the procedure of the ULPI transaction finish detection has been developed as a simple busy-loop with just decrementing counter and no delays. It's wrong since on different systems the loop will take a different time to complete. So if the system bus and CPU are fast enough to overtake the ULPI bus and the companion PHY reaction, then we'll get to take a false timeout error. Fix this by converting the busy-loop procedure to take the standard bus speed, address value and the registers access mode into account for the busy-loop delay calculation. Here is the way the fix works. It's known that the ULPI bus is clocked with 60MHz signal. In accordance with [1] the ULPI bus protocol is created so to spend 5 and 6 clock periods for immediate register write and read operations respectively, and 6 and 7 clock periods - for the extended register writes and reads. Based on that we can easily pre-calculate the time which will be needed for the controller to perform a requested IO operation. Note we'll still preserve the attempts counter in case if the DWC USB3 controller has got some internals delays. [1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1, October 20, 2004, pp. 30 - 36. Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support") Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-3-Sergey.Semin@baikalelectro… Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c index 3cc4f4970c05..54c877f7b51d 100644 --- a/drivers/usb/dwc3/ulpi.c +++ b/drivers/usb/dwc3/ulpi.c @@ -7,6 +7,8 @@ * Author: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> */ +#include <linux/delay.h> +#include <linux/time64.h> #include <linux/ulpi/regs.h> #include "core.h" @@ -17,12 +19,22 @@ DWC3_GUSB2PHYACC_ADDR(ULPI_ACCESS_EXTENDED) | \ DWC3_GUSB2PHYACC_EXTEND_ADDR(a) : DWC3_GUSB2PHYACC_ADDR(a)) -static int dwc3_ulpi_busyloop(struct dwc3 *dwc) +#define DWC3_ULPI_BASE_DELAY DIV_ROUND_UP(NSEC_PER_SEC, 60000000L) + +static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr, bool read) { + unsigned long ns = 5L * DWC3_ULPI_BASE_DELAY; unsigned int count = 1000; u32 reg; + if (addr >= ULPI_EXT_VENDOR_SPECIFIC) + ns += DWC3_ULPI_BASE_DELAY; + + if (read) + ns += DWC3_ULPI_BASE_DELAY; + while (count--) { + ndelay(ns); reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYACC(0)); if (reg & DWC3_GUSB2PHYACC_DONE) return 0; @@ -47,7 +59,7 @@ static int dwc3_ulpi_read(struct device *dev, u8 addr) reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr); dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg); - ret = dwc3_ulpi_busyloop(dwc); + ret = dwc3_ulpi_busyloop(dwc, addr, true); if (ret) return ret; @@ -71,7 +83,7 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 val) reg |= DWC3_GUSB2PHYACC_WRITE | val; dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg); - return dwc3_ulpi_busyloop(dwc); + return dwc3_ulpi_busyloop(dwc, addr, false); } static const struct ulpi_ops dwc3_ulpi_ops = {

3 years, 8 months

2
1
0 0

[PATCH v5] tpm_tis: Add missing tpm_request/relinquish_locality() calls

by Lukasz Majczak

There are missing calls to tpm_request_locality() before the calls to the tpm_get_timeouts() and tpm_tis_probe_irq_single() - both functions internally send commands to the tpm using tpm_tis_send_data() which in turn, at the very beginning, calls the tpm_tis_status(). This one tries to read TPM_STS register, what fails and propagates this error upward. The read fails due to lack of acquired locality, as it is described in TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality. The described situation manifests itself with the following warning trace: [ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f Tested on Samsung Chromebook Pro (Caroline), TPM 1.2 (SLB 9670) Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> --- Hi I have tried to clean all the pointed issues, but decided to stay with tpm_request/relinquish_locality() calls instead of using tpm_chip_start/stop(), the rationale behind this is that, in this case only locality is requested, there is no need to enable/disable the clock, the similar case is present in the probe_itpm() function. One more clarification is that, the TPM present on my test machine is the SLB 9670 (not Cr50). Best regards, Lukasz Changes: v4->v5: * Fixed style, typos, clarified commit message drivers/char/tpm/tpm-chip.c | 6 ++++-- drivers/char/tpm/tpm-interface.c | 13 ++++++++++--- drivers/char/tpm/tpm.h | 2 ++ drivers/char/tpm/tpm_tis_core.c | 14 +++++++++++--- 4 files changed, 27 insertions(+), 8 deletions(-) diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index ddaeceb7e109..ce9c2650fbe5 100644 --- a/drivers/char/tpm/tpm-chip.c +++ b/drivers/char/tpm/tpm-chip.c @@ -32,7 +32,7 @@ struct class *tpm_class; struct class *tpmrm_class; dev_t tpm_devt; -static int tpm_request_locality(struct tpm_chip *chip) +int tpm_request_locality(struct tpm_chip *chip) { int rc; @@ -46,8 +46,9 @@ static int tpm_request_locality(struct tpm_chip *chip) chip->locality = rc; return 0; } +EXPORT_SYMBOL_GPL(tpm_request_locality); -static void tpm_relinquish_locality(struct tpm_chip *chip) +void tpm_relinquish_locality(struct tpm_chip *chip) { int rc; @@ -60,6 +61,7 @@ static void tpm_relinquish_locality(struct tpm_chip *chip) chip->locality = -1; } +EXPORT_SYMBOL_GPL(tpm_relinquish_locality); static int tpm_cmd_ready(struct tpm_chip *chip) { diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 1621ce818705..2a9001d329f2 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -241,10 +241,17 @@ int tpm_get_timeouts(struct tpm_chip *chip) if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS) return 0; - if (chip->flags & TPM_CHIP_FLAG_TPM2) + if (chip->flags & TPM_CHIP_FLAG_TPM2) { return tpm2_get_timeouts(chip); - else - return tpm1_get_timeouts(chip); + } else { + ssize_t ret = tpm_request_locality(chip); + + if (ret) + return ret; + ret = tpm1_get_timeouts(chip); + tpm_relinquish_locality(chip); + return ret; + } } EXPORT_SYMBOL_GPL(tpm_get_timeouts); diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index 947d1db0a5cc..8c13008437dd 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -193,6 +193,8 @@ static inline void tpm_msleep(unsigned int delay_msec) int tpm_chip_start(struct tpm_chip *chip); void tpm_chip_stop(struct tpm_chip *chip); +int tpm_request_locality(struct tpm_chip *chip); +void tpm_relinquish_locality(struct tpm_chip *chip); struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip); __must_check int tpm_try_get_ops(struct tpm_chip *chip); void tpm_put_ops(struct tpm_chip *chip); diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index 431919d5f48a..d4f381d6356e 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -708,11 +708,19 @@ static int tpm_tis_gen_interrupt(struct tpm_chip *chip) u32 cap2; cap_t cap; - if (chip->flags & TPM_CHIP_FLAG_TPM2) + if (chip->flags & TPM_CHIP_FLAG_TPM2) { return tpm2_get_tpm_pt(chip, 0x100, &cap2, desc); - else - return tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, desc, + } else { + ssize_t ret = tpm_request_locality(chip); + + if (ret) + return ret; + ret = tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, desc, 0); + tpm_relinquish_locality(chip); + return ret; + } + } /* Register the IRQ and issue a command that will cause an interrupt. If an -- 2.25.1

3 years, 8 months

3
2
0 0

[PATCH v2 1/1] s390/vfio-ap: fix circular lockdep when setting/clearing crypto masks

by Tony Krowiak

This patch fixes a circular locking dependency in the CI introduced by commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated"). The lockdep only occurs when starting a Secure Execution guest. Crypto virtualization (vfio_ap) is not yet supported for SE guests; however, in order to avoid CI errors, this fix is being provided. The circular lockdep was introduced when the masks in the guest's APCB were taken under the matrix_dev->lock. While the lock is definitely needed to protect the setting/unsetting of the KVM pointer, it is not necessarily critical for setting the masks, so this will not be done under protection of the matrix_dev->lock. Fixes: f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated") Cc: stable(a)vger.kernel.org Signed-off-by: Tony Krowiak <akrowiak(a)linux.ibm.com> --- drivers/s390/crypto/vfio_ap_ops.c | 78 +++++++++++++++++++------------ 1 file changed, 48 insertions(+), 30 deletions(-) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index 41fc2e4135fe..bba0f64aa1f7 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -1028,7 +1028,10 @@ static const struct attribute_group *vfio_ap_mdev_attr_groups[] = { * @kvm: reference to KVM instance * * Verifies no other mediated matrix device has @kvm and sets a reference to - * it in @matrix_mdev->kvm. + * it in @matrix_mdev->kvm. The matrix_dev->lock must be taken prior to calling + * this function; however, the lock will be temporarily released while updating + * the guest's APCB to avoid a potential circular lock dependency with other + * asynchronous processes. * * Return 0 if no other mediated matrix device has a reference to @kvm; * otherwise, returns an -EPERM. @@ -1043,10 +1046,19 @@ static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev, return -EPERM; } - matrix_mdev->kvm = kvm; kvm_get_kvm(kvm); + matrix_mdev->kvm = kvm; kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook; + if (matrix_mdev->kvm && matrix_mdev->kvm->arch.crypto.crycbd) { + mutex_unlock(&matrix_dev->lock); + kvm_arch_crypto_set_masks(kvm, + matrix_mdev->matrix.apm, + matrix_mdev->matrix.aqm, + matrix_mdev->matrix.adm); + mutex_lock(&matrix_dev->lock); + } + return 0; } @@ -1079,13 +1091,34 @@ static int vfio_ap_mdev_iommu_notifier(struct notifier_block *nb, return NOTIFY_DONE; } +/** + * vfio_ap_mdev_unset_kvm + * + * @matrix_mdev: a matrix mediated device + * + * Clears the masks in the guest's APCB as well as the reference to KVM from + * @matrix_mdev. The matrix_dev->lock must be taken prior to calling this + * function; however, the lock will be temporarily released while updating + * the guest's APCB to avoid a potential circular lock dependency with other + * asynchronous processes. + */ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev) { - kvm_arch_crypto_clear_masks(matrix_mdev->kvm); - matrix_mdev->kvm->arch.crypto.pqap_hook = NULL; - vfio_ap_mdev_reset_queues(matrix_mdev->mdev); - kvm_put_kvm(matrix_mdev->kvm); - matrix_mdev->kvm = NULL; + struct kvm *kvm; + + if (matrix_mdev->kvm) { + kvm = matrix_mdev->kvm; + kvm_get_kvm(kvm); + kvm->arch.crypto.pqap_hook = NULL; + mutex_unlock(&matrix_dev->lock); + kvm_arch_crypto_clear_masks(kvm); + mutex_lock(&matrix_dev->lock); + kvm_put_kvm(kvm); + vfio_ap_mdev_reset_queues(matrix_mdev->mdev); + if (matrix_mdev->kvm) + kvm_put_kvm(matrix_mdev->kvm); + matrix_mdev->kvm = NULL; + } } static int vfio_ap_mdev_group_notifier(struct notifier_block *nb, @@ -1097,33 +1130,19 @@ static int vfio_ap_mdev_group_notifier(struct notifier_block *nb, if (action != VFIO_GROUP_NOTIFY_SET_KVM) return NOTIFY_OK; - matrix_mdev = container_of(nb, struct ap_matrix_mdev, group_notifier); mutex_lock(&matrix_dev->lock); + matrix_mdev = container_of(nb, struct ap_matrix_mdev, group_notifier); - if (!data) { - if (matrix_mdev->kvm) - vfio_ap_mdev_unset_kvm(matrix_mdev); - goto notify_done; - } - - ret = vfio_ap_mdev_set_kvm(matrix_mdev, data); - if (ret) { - notify_rc = NOTIFY_DONE; - goto notify_done; - } + if (!data) + vfio_ap_mdev_unset_kvm(matrix_mdev); + else + ret = vfio_ap_mdev_set_kvm(matrix_mdev, data); - /* If there is no CRYCB pointer, then we can't copy the masks */ - if (!matrix_mdev->kvm->arch.crypto.crycbd) { + if (ret) notify_rc = NOTIFY_DONE; - goto notify_done; - } - - kvm_arch_crypto_set_masks(matrix_mdev->kvm, matrix_mdev->matrix.apm, - matrix_mdev->matrix.aqm, - matrix_mdev->matrix.adm); -notify_done: mutex_unlock(&matrix_dev->lock); + return notify_rc; } @@ -1258,8 +1277,7 @@ static void vfio_ap_mdev_release(struct mdev_device *mdev) struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); mutex_lock(&matrix_dev->lock); - if (matrix_mdev->kvm) - vfio_ap_mdev_unset_kvm(matrix_mdev); + vfio_ap_mdev_unset_kvm(matrix_mdev); mutex_unlock(&matrix_dev->lock); vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY, -- 2.21.1

3 years, 8 months

2
1
0 0

[PATCH] powerpc/pseries: Don't enforce MSI affinity with kdump

by Greg Kurz

Depending on the number of online CPUs in the original kernel, it is likely for CPU #0 to be offline in a kdump kernel. The associated IRQs in the affinity mappings provided by irq_create_affinity_masks() are thus not started by irq_startup(), as per-design with managed IRQs. This can be a problem with multi-queue block devices driven by blk-mq : such a non-started IRQ is very likely paired with the single queue enforced by blk-mq during kdump (see blk_mq_alloc_tag_set()). This causes the device to remain silent and likely hangs the guest at some point. This is a regression caused by commit 9ea69a55b3b9 ("powerpc/pseries: Pass MSI affinity to irq_create_mapping()"). Note that this only happens with the XIVE interrupt controller because XICS has a workaround to bypass affinity, which is activated during kdump with the "noirqdistrib" kernel parameter. The issue comes from a combination of factors: - discrepancy between the number of queues detected by the multi-queue block driver, that was used to create the MSI vectors, and the single queue mode enforced later on by blk-mq because of kdump (i.e. keeping all queues fixes the issue) - CPU#0 offline (i.e. kdump always succeed with CPU#0) Given that I couldn't reproduce on x86, which seems to always have CPU#0 online even during kdump, I'm not sure where this should be fixed. Hence going for another approach : fine-grained affinity is for performance and we don't really care about that during kdump. Simply revert to the previous working behavior of ignoring affinity masks in this case only. Fixes: 9ea69a55b3b9 ("powerpc/pseries: Pass MSI affinity to irq_create_mapping()") Cc: lvivier(a)redhat.com Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kurz <groug(a)kaod.org> --- arch/powerpc/platforms/pseries/msi.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c index b3ac2455faad..29d04b83288d 100644 --- a/arch/powerpc/platforms/pseries/msi.c +++ b/arch/powerpc/platforms/pseries/msi.c @@ -458,8 +458,28 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type) return hwirq; } - virq = irq_create_mapping_affinity(NULL, hwirq, - entry->affinity); + /* + * Depending on the number of online CPUs in the original + * kernel, it is likely for CPU #0 to be offline in a kdump + * kernel. The associated IRQs in the affinity mappings + * provided by irq_create_affinity_masks() are thus not + * started by irq_startup(), as per-design for managed IRQs. + * This can be a problem with multi-queue block devices driven + * by blk-mq : such a non-started IRQ is very likely paired + * with the single queue enforced by blk-mq during kdump (see + * blk_mq_alloc_tag_set()). This causes the device to remain + * silent and likely hangs the guest at some point. + * + * We don't really care for fine-grained affinity when doing + * kdump actually : simply ignore the pre-computed affinity + * masks in this case and let the default mask with all CPUs + * be used when creating the IRQ mappings. + */ + if (is_kdump_kernel()) + virq = irq_create_mapping(NULL, hwirq); + else + virq = irq_create_mapping_affinity(NULL, hwirq, + entry->affinity); if (!virq) { pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq); -- 2.26.2

3 years, 8 months

4
3
0 0

[PATCH] arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page

by Catalin Marinas

The ptrace(PTRACE_PEEKMTETAGS) implementation checks whether the user page has valid tags (mapped with PROT_MTE) by testing the PG_mte_tagged page flag. If this bit is cleared, ptrace(PTRACE_PEEKMTETAGS) returns -EIO. A newly created (PROT_MTE) mapping points to the zero page which had its tags zeroed during cpu_enable_mte(). If there were no prior writes to this mapping, ptrace(PTRACE_PEEKMTETAGS) fails with -EIO since the zero page does not have the PG_mte_tagged flag set. Set PG_mte_tagged on the zero page when its tags are cleared during boot. In addition, to avoid ptrace(PTRACE_PEEKMTETAGS) succeeding on !PROT_MTE mappings pointing to the zero page, change the __access_remote_tags() check to (vm_flags & VM_MTE) instead of PG_mte_tagged. Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE") Cc: <stable(a)vger.kernel.org> # 5.10.x Cc: Will Deacon <will(a)kernel.org> Reported-by: Luis Machado <luis.machado(a)linaro.org> --- The fix is actually checking VM_MTE instead of PG_mte_tagged in __access_remote_tags() but I added the WARN_ON(!PG_mte_tagged) and setting the flag on the zero page in case we break this assumption in the future. arch/arm64/kernel/cpufeature.c | 6 +----- arch/arm64/kernel/mte.c | 3 ++- 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index e99eddec0a46..3e6331b64932 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -1701,16 +1701,12 @@ static void bti_enable(const struct arm64_cpu_capabilities *__unused) #ifdef CONFIG_ARM64_MTE static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) { - static bool cleared_zero_page = false; - /* * Clear the tags in the zero page. This needs to be done via the * linear map which has the Tagged attribute. */ - if (!cleared_zero_page) { - cleared_zero_page = true; + if (!test_and_set_bit(PG_mte_tagged, &ZERO_PAGE(0)->flags)) mte_clear_page_tags(lm_alias(empty_zero_page)); - } kasan_init_hw_tags_cpu(); } diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c index dc9ada64feed..80b62fe49dcf 100644 --- a/arch/arm64/kernel/mte.c +++ b/arch/arm64/kernel/mte.c @@ -329,11 +329,12 @@ static int __access_remote_tags(struct mm_struct *mm, unsigned long addr, * would cause the existing tags to be cleared if the page * was never mapped with PROT_MTE. */ - if (!test_bit(PG_mte_tagged, &page->flags)) { + if (!(vma->vm_flags & VM_MTE)) { ret = -EOPNOTSUPP; put_page(page); break; } + WARN_ON_ONCE(!test_bit(PG_mte_tagged, &page->flags)); /* limit access to the end of the page */ offset = offset_in_page(addr);

3 years, 8 months

3
4
0 0

[PATCH 4.19 00/24] 4.19.176-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.176 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 13 Feb 2021 15:01:39 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.176-r… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.19.176-rc1 Phillip Lougher <phillip(a)squashfs.org.uk> squashfs: add more sanity checks in xattr id lookup Phillip Lougher <phillip(a)squashfs.org.uk> squashfs: add more sanity checks in inode lookup Phillip Lougher <phillip(a)squashfs.org.uk> squashfs: add more sanity checks in id lookup Ming Lei <ming.lei(a)redhat.com> blk-mq: don't hold q->sysfs_lock in blk_mq_map_swqueue Ming Lei <ming.lei(a)redhat.com> block: don't hold q->sysfs_lock in elevator_init_mq Peter Gonda <pgonda(a)google.com> Fix unsynchronized access to sev members through svm_register_enc_region Theodore Ts'o <tytso(a)mit.edu> memcg: fix a crash in wb_workfn when a device disappears Qian Cai <cai(a)lca.pw> include/trace/events/writeback.h: fix -Wstringop-truncation warnings Tobin C. Harding <tobin(a)kernel.org> lib/string: Add strscpy_pad() function Dave Wysochanski <dwysocha(a)redhat.com> SUNRPC: Handle 0 length opaque XDR object data properly Dave Wysochanski <dwysocha(a)redhat.com> SUNRPC: Move simple_get_bytes and simple_get_netobj into private header Johannes Berg <johannes.berg(a)intel.com> iwlwifi: mvm: guard against device removal in reprobe Johannes Berg <johannes.berg(a)intel.com> iwlwifi: pcie: fix context info memory leak Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap Johannes Berg <johannes.berg(a)intel.com> iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time() Trond Myklebust <trond.myklebust(a)hammerspace.com> pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process() Pan Bian <bianpan2016(a)163.com> chtls: Fix potential resource leak David Collins <collinsd(a)codeaurora.org> regulator: core: avoid regulator_resolve_supply() race condition Cong Wang <cong.wang(a)bytedance.com> af_key: relax availability checks for skb size calculation Sibi Sankar <sibis(a)codeaurora.org> remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load Sibi Sankar <sibis(a)codeaurora.org> remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load Steven Rostedt (VMware) <rostedt(a)goodmis.org> fgraph: Initialize tracing_graph_pause at task creation zhengbin <zhengbin13(a)huawei.com> block: fix NULL pointer dereference in register_disk Masami Hiramatsu <mhiramat(a)kernel.org> tracing/kprobe: Fix to support kretprobe events on unloaded modules ------------- Diffstat: Makefile | 4 +- arch/x86/kvm/svm.c | 18 +++--- block/blk-mq.c | 7 --- block/elevator.c | 14 ++--- block/genhd.c | 10 ++-- drivers/crypto/chelsio/chtls/chtls_cm.c | 7 +-- .../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 3 + drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +- .../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 11 +++- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 5 ++ drivers/regulator/core.c | 39 +++++++++---- drivers/remoteproc/qcom_q6v5_pil.c | 11 +++- fs/fs-writeback.c | 2 +- fs/nfs/pnfs.c | 8 ++- fs/squashfs/export.c | 41 +++++++++++--- fs/squashfs/id.c | 40 ++++++++++--- fs/squashfs/squashfs_fs_sb.h | 1 + fs/squashfs/super.c | 6 +- fs/squashfs/xattr.h | 10 +++- fs/squashfs/xattr_id.c | 66 +++++++++++++++++++--- include/linux/backing-dev.h | 10 ++++ include/linux/kprobes.h | 2 +- include/linux/string.h | 4 ++ include/linux/sunrpc/xdr.h | 3 +- include/trace/events/writeback.h | 35 ++++++------ init/init_task.c | 3 +- kernel/kprobes.c | 34 ++++++++--- kernel/trace/ftrace.c | 2 - kernel/trace/trace_kprobe.c | 4 +- lib/string.c | 47 ++++++++++++--- mm/backing-dev.c | 1 + net/key/af_key.c | 6 +- net/sunrpc/auth_gss/auth_gss.c | 30 +--------- net/sunrpc/auth_gss/auth_gss_internal.h | 45 +++++++++++++++ net/sunrpc/auth_gss/gss_krb5_mech.c | 31 +--------- 35 files changed, 379 insertions(+), 184 deletions(-)

3 years, 8 months

5
33
0 0

stable-rc/linux-4.19.y baseline: 80 runs, 1 regressions (v4.19.175-28-g7a5acd93ed02)

by kernelci.org bot

stable-rc/linux-4.19.y baseline: 80 runs, 1 regressions (v4.19.175-28-g7a5acd93ed02) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.17… Test: baseline Tree: stable-rc Branch: linux-4.19.y Describe: v4.19.175-28-g7a5acd93ed02 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 7a5acd93ed02982be8ee91127bad4f85473b3c1a Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/602642908c24bfec063abec0 Results: 4 PASS, 1 FAIL, 0 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.175-28-g7a5acd93… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.175-28-g7a5acd93… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/602642908c24bfec063abec7 failing since 3 days (last pass: v4.19.174, first fail: v4.19.174-39-g69312fa72410) 2 lines 2021-02-12 08:55:39.811000+00:00 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/104 2021-02-12 08:55:39.820000+00:00 kern :emerg : lock: emif_lock+0x0/0xffffed34 [emif], .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1

3 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2021