Message ID | 20200513162215.233019-1-frank.heimes@canonical.com |
---|---|
Headers | show |
Series | zpcictl --reset - contribution for kernel (LP: 1870320) | expand |
Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com> On Wed, May 13, 2020 at 06:22:13PM +0200, frank.heimes@canonical.com wrote: > Buglink: https://bugs.launchpad.net/bugs/1870320 > > SRU Justification: > > [Impact] > > * With zpci_disable() working, 'lockdep' detected a potential deadlock (in the s390x zPCI subsystem). > > * The deadlock is between recovering a PCI function via the /sys/bus/pci/devices/<dev>/recover attribute vs powering it off via /sys/bus/pci/slots/<slot>/power. > > [Fix] > > * Backport 1: https://launchpadlibrarian.net/479554961/0001-s390-pci-Recover-handle-in-clp_set_pci_fn.patch > > * Backport 2: https://launchpadlibrarian.net/478714295/0001-s390-pci-Fix-possible-deadlock-in-recover_store.patch > > [Test Case] > > * It's best to (re-)test using the kernel's locking validator, also known as 'lockdep'. > > * Since this potential deadlock was identified by lockdep. > > [Regression Potential] > > * The regression potential can be considered as moderate, since: > > * It is purely s390x specific code (arch/s390/include/asm/pci.h and arch/s390/pci/{pci.c,pci_clp.c,pci_sysfs.c}). > > * It only affects the zPCI, the s390x specific PCI code layer. > > * PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread. > > * The states between such a deadlock can happen (recover and power off) are non standard and usually undesired states. > > * The patches are upstream accepted since 5.6 and already landed in eoan and focal. > > [Other Info] > > * Patches 17cdec960cf7 "s390/pci: Recover handle in clp_set_pci_fn()" and 576c75e36c68 "s390/pci: Fix possible deadlock in recover_store()" are upstream accepted since kernel 5.6, but they don't apply cleanly on bionic master-next, hence backports are needed: > > * 0001-s390-pci-Recover-handle-in-clp_set_pci_fn.patch is a backport of 17cdec960cf776b20b1fb08c622221babe591d51 17cdec960cf7 "s390/pci: Recover handle in clp_set_pci_fn()" > > * 0001-s390-pci-Fix-possible-deadlock-in-recover_store.patch is a backport of 576c75e36c689bec6a940e807bae27291ab0c0de 576c75e36c68 "s390/pci: Fix possible deadlock in recover_store()" > > * Both patches/commits already landed in focal (with LP 1863768) and in eoan (with LP 1868324). > > Niklas Schnelle (2): > s390/pci: Recover handle in clp_set_pci_fn() > s390/pci: Fix possible deadlock in recover_store() > > arch/s390/include/asm/pci.h | 2 +- > arch/s390/pci/pci.c | 2 +- > arch/s390/pci/pci_clp.c | 46 ++++++++++++++------------- > arch/s390/pci/pci_sysfs.c | 63 ++++++++++++++++++++++++------------- > 4 files changed, 69 insertions(+), 44 deletions(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On 13.05.20 18:22, frank.heimes@canonical.com wrote: > Buglink: https://bugs.launchpad.net/bugs/1870320 > > SRU Justification: > > [Impact] > > * With zpci_disable() working, 'lockdep' detected a potential deadlock (in the s390x zPCI subsystem). > > * The deadlock is between recovering a PCI function via the /sys/bus/pci/devices/<dev>/recover attribute vs powering it off via /sys/bus/pci/slots/<slot>/power. > > [Fix] > > * Backport 1: https://launchpadlibrarian.net/479554961/0001-s390-pci-Recover-handle-in-clp_set_pci_fn.patch > > * Backport 2: https://launchpadlibrarian.net/478714295/0001-s390-pci-Fix-possible-deadlock-in-recover_store.patch > > [Test Case] > > * It's best to (re-)test using the kernel's locking validator, also known as 'lockdep'. > > * Since this potential deadlock was identified by lockdep. > > [Regression Potential] > > * The regression potential can be considered as moderate, since: > > * It is purely s390x specific code (arch/s390/include/asm/pci.h and arch/s390/pci/{pci.c,pci_clp.c,pci_sysfs.c}). > > * It only affects the zPCI, the s390x specific PCI code layer. > > * PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread. > > * The states between such a deadlock can happen (recover and power off) are non standard and usually undesired states. > > * The patches are upstream accepted since 5.6 and already landed in eoan and focal. > > [Other Info] > > * Patches 17cdec960cf7 "s390/pci: Recover handle in clp_set_pci_fn()" and 576c75e36c68 "s390/pci: Fix possible deadlock in recover_store()" are upstream accepted since kernel 5.6, but they don't apply cleanly on bionic master-next, hence backports are needed: > > * 0001-s390-pci-Recover-handle-in-clp_set_pci_fn.patch is a backport of 17cdec960cf776b20b1fb08c622221babe591d51 17cdec960cf7 "s390/pci: Recover handle in clp_set_pci_fn()" > > * 0001-s390-pci-Fix-possible-deadlock-in-recover_store.patch is a backport of 576c75e36c689bec6a940e807bae27291ab0c0de 576c75e36c68 "s390/pci: Fix possible deadlock in recover_store()" > > * Both patches/commits already landed in focal (with LP 1863768) and in eoan (with LP 1868324). > > Niklas Schnelle (2): > s390/pci: Recover handle in clp_set_pci_fn() > s390/pci: Fix possible deadlock in recover_store() > > arch/s390/include/asm/pci.h | 2 +- > arch/s390/pci/pci.c | 2 +- > arch/s390/pci/pci_clp.c | 46 ++++++++++++++------------- > arch/s390/pci/pci_sysfs.c | 63 ++++++++++++++++++++++++------------- > 4 files changed, 69 insertions(+), 44 deletions(-) > Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
On 2020-05-13 18:22:13 , frank.heimes@canonical.com wrote: > Buglink: https://bugs.launchpad.net/bugs/1870320 > > SRU Justification: > > [Impact] > > * With zpci_disable() working, 'lockdep' detected a potential deadlock (in the s390x zPCI subsystem). > > * The deadlock is between recovering a PCI function via the /sys/bus/pci/devices/<dev>/recover attribute vs powering it off via /sys/bus/pci/slots/<slot>/power. > > [Fix] > > * Backport 1: https://launchpadlibrarian.net/479554961/0001-s390-pci-Recover-handle-in-clp_set_pci_fn.patch > > * Backport 2: https://launchpadlibrarian.net/478714295/0001-s390-pci-Fix-possible-deadlock-in-recover_store.patch > > [Test Case] > > * It's best to (re-)test using the kernel's locking validator, also known as 'lockdep'. > > * Since this potential deadlock was identified by lockdep. > > [Regression Potential] > > * The regression potential can be considered as moderate, since: > > * It is purely s390x specific code (arch/s390/include/asm/pci.h and arch/s390/pci/{pci.c,pci_clp.c,pci_sysfs.c}). > > * It only affects the zPCI, the s390x specific PCI code layer. > > * PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread. > > * The states between such a deadlock can happen (recover and power off) are non standard and usually undesired states. > > * The patches are upstream accepted since 5.6 and already landed in eoan and focal. > > [Other Info] > > * Patches 17cdec960cf7 "s390/pci: Recover handle in clp_set_pci_fn()" and 576c75e36c68 "s390/pci: Fix possible deadlock in recover_store()" are upstream accepted since kernel 5.6, but they don't apply cleanly on bionic master-next, hence backports are needed: > > * 0001-s390-pci-Recover-handle-in-clp_set_pci_fn.patch is a backport of 17cdec960cf776b20b1fb08c622221babe591d51 17cdec960cf7 "s390/pci: Recover handle in clp_set_pci_fn()" > > * 0001-s390-pci-Fix-possible-deadlock-in-recover_store.patch is a backport of 576c75e36c689bec6a940e807bae27291ab0c0de 576c75e36c68 "s390/pci: Fix possible deadlock in recover_store()" > > * Both patches/commits already landed in focal (with LP 1863768) and in eoan (with LP 1868324). > > Niklas Schnelle (2): > s390/pci: Recover handle in clp_set_pci_fn() > s390/pci: Fix possible deadlock in recover_store() > > arch/s390/include/asm/pci.h | 2 +- > arch/s390/pci/pci.c | 2 +- > arch/s390/pci/pci_clp.c | 46 ++++++++++++++------------- > arch/s390/pci/pci_sysfs.c | 63 ++++++++++++++++++++++++------------- > 4 files changed, 69 insertions(+), 44 deletions(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team