[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-10-13 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Released
Status in linux source package in Groovy:
  Fix Released

Bug description:
  SRU Justification:
  ==

  [Impact]

  * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
  s390x, it can be detected as an entry in CLP List PCI functions and
  via the hot-plug event.

  * (This is basically equivalent to boot time probing on other
  architectures.)

  * In such a case the hot-plug event will be stale, but Linux still
  tries to add and enable the device which leads to:

  * a) a duplicate entry in zPCI internal device list

  * b) an attempt to enable the device with a stale function handle

  * In case b) the device will be placed in error state which makes it
  unusable.

  [Fix]

  * b76fee1bc56c31a9d2a49592810eba30cc06d61a b76fee1bc56c "s390/pci:
  ignore stale configuration request event"

  [Test Case]

  * Setup an Ubuntu Server 20.04 (focal) Linux operating system on an
  IBM Z or LinuxONE III LPAR.

  * It's now easiest to test on KVM using virtio-pci (on s390x).

  * Start a test virtual machine: sudo virsh start 

  * Attach and hotplug a virtio-pci device: sudo virsh attach-device
   hotplug_pci_block.xml

  * Where hotplug_pci_block.xml looks like:
 


   



 

  [Regression Potential]

  * The regression risk is moderate, since the modification is very
  limited and therefore manageable (additional if statement - two lines
  of code) and easily testable on KVM using virtio-pci.

  * The changes are in the zPCI event code, so in worst-case it can
  happen that the event handling get harmed which may break zPCI
  entirely, affecting all PCI devices incl. virtio-pci (on s390x).

  * A bug in PCI 'availability' handling also just lead to wrong states
  of PCI devices which make them unavailable, hence unusable.

  * Notice that zPCI is the s390x-specific PCI implementation,
  modifications here do not affect any other architecture.

  * And zPCI devices are less wide-spread compared to ccw devices on
  s390x.

  * On top a test kernel was build and made available for further
  testing atesting can be easily done with virtio-pci on KVM.

  [Other]

  * The fix/patch got upstream accepted with kernel v5.9-rc2.

  * But it landed already in groovy's proposed kernel 5.8
  (Ubuntu-5.8.0-18.19), due to 'Groovy update: v5.8.4 upstream stable
  release' that is handled in LP 1893048.

  * Hence this fix/patch need to be applied to focal only.

  __

  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-10-13 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.4.0-51.56

---
linux (5.4.0-51.56) focal; urgency=medium

  * Packaging resync (LP: #1786013)
- update dkms package versions

linux (5.4.0-50.55) focal; urgency=medium

  * CVE-2020-16119
- SAUCE: dccp: avoid double free of ccid on child socket

  * CVE-2020-16120
- Revert "UBUNTU: SAUCE: overlayfs: ensure mounter privileges when reading
  directories"
- ovl: pass correct flags for opening real directory
- ovl: switch to mounter creds in readdir
- ovl: verify permissions in ovl_path_open()
- ovl: call secutiry hook in ovl_real_ioctl()
- ovl: check permission to open real file

linux (5.4.0-49.53) focal; urgency=medium

  * focal/linux: 5.4.0-49.53 -proposed tracker (LP: #1896007)

  * Comet Lake PCH-H RAID not support on Ubuntu20.04 (LP: #1892288)
- ahci: Add Intel Comet Lake PCH-H PCI ID

  * Novalink (mkvterm command failure) (LP: #1892546)
- tty: hvcs: Don't NULL tty->driver_data until hvcs_cleanup()

  * Oops and hang when starting LVM snapshots on 5.4.0-47 (LP: #1894780)
- SAUCE: Revert "mm: memcg/slab: fix memory leak at non-root kmem_cache
  destroy"

  * Intel x710 LOMs do not work on Focal (LP: #1893956)
- i40e: Fix LED blinking flow for X710T*L devices
- i40e: enable X710 support

  * Add/Backport EPYC-v3 and EPYC-Rome CPU model (LP: #1887490)
- kvm: svm: Update svm_xsaves_supported

  * Fix non-working NVMe after S3 (LP: #1895718)
- SAUCE: PCI: Enable ACS quirk on CML root port

  * Focal update: v5.4.65 upstream stable release (LP: #1895881)
- ipv4: Silence suspicious RCU usage warning
- ipv6: Fix sysctl max for fib_multipath_hash_policy
- netlabel: fix problems with mapping removal
- net: usb: dm9601: Add USB ID of Keenetic Plus DSL
- sctp: not disable bh in the whole sctp_get_port_local()
- taprio: Fix using wrong queues in gate mask
- tipc: fix shutdown() of connectionless socket
- net: disable netpoll on fresh napis
- Linux 5.4.65

  * Focal update: v5.4.64 upstream stable release (LP: #1895880)
- HID: quirks: Always poll three more Lenovo PixArt mice
- drm/msm/dpu: Fix scale params in plane validation
- tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setup
- drm/msm: add shutdown support for display platform_driver
- hwmon: (applesmc) check status earlier.
- nvmet: Disable keep-alive timer when kato is cleared to 0h
- drm/msm: enable vblank during atomic commits
- habanalabs: validate FW file size
- habanalabs: check correct vmalloc return code
- drm/msm/a6xx: fix gmu start on newer firmware
- ceph: don't allow setlease on cephfs
- drm/omap: fix incorrect lock state
- cpuidle: Fixup IRQ state
- nbd: restore default timeout when setting it to zero
- s390: don't trace preemption in percpu macros
- drm/amd/display: Reject overlay plane configurations in multi-display
  scenarios
- drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in
  amdgpu_dm_update_backlight_caps
- drm/amd/display: Retry AUX write when fail occurs
- drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
- xen/xenbus: Fix granting of vmalloc'd memory
- fsldma: fix very broken 32-bit ppc ioread64 functionality
- dmaengine: of-dma: Fix of_dma_router_xlate's of_dma_xlate handling
- batman-adv: Avoid uninitialized chaddr when handling DHCP
- batman-adv: Fix own OGM check in aggregated OGMs
- batman-adv: bla: use netif_rx_ni when not in interrupt context
- dmaengine: at_hdmac: check return value of of_find_device_by_node() in
  at_dma_xlate()
- rxrpc: Keep the ACK serial in a var in rxrpc_input_ack()
- rxrpc: Make rxrpc_kernel_get_srtt() indicate validity
- MIPS: mm: BMIPS5000 has inclusive physical caches
- MIPS: BMIPS: Also call bmips_cpu_setup() for secondary cores
- mmc: sdhci-acpi: Fix HS400 tuning for AMDI0040
- netfilter: nf_tables: add NFTA_SET_USERDATA if not null
- netfilter: nf_tables: incorrect enum nft_list_attributes definition
- netfilter: nf_tables: fix destination register zeroing
- net: hns: Fix memleak in hns_nic_dev_probe
- net: systemport: Fix memleak in bcm_sysport_probe
- ravb: Fixed to be able to unload modules
- net: arc_emac: Fix memleak in arc_mdio_probe
- dmaengine: pl330: Fix burst length if burst size is smaller than bus width
- gtp: add GTPA_LINK info to msg sent to userspace
- net: ethernet: ti: cpsw: fix clean up of vlan mc entries for host port
- bnxt_en: Don't query FW when netif_running() is false.
- bnxt_en: Check for zero dir entries in NVRAM.
- bnxt_en: Fix PCI AER error recovery flow
- bnxt_en: Fix possible crash in bnxt_fw_reset_task().
- bnxt_en: fix HWRM error when querying VF temperature
- xfs: fix boundary test in xfs_attr_shortform_verify
- bnxt: don't enable NAPI until rings are ready
  

[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-22 Thread Frank Heimes
Thx Niklas for the verification - updating tags ...

** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  Fix Released

Bug description:
  SRU Justification:
  ==

  [Impact]

  * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
  s390x, it can be detected as an entry in CLP List PCI functions and
  via the hot-plug event.

  * (This is basically equivalent to boot time probing on other
  architectures.)

  * In such a case the hot-plug event will be stale, but Linux still
  tries to add and enable the device which leads to:

  * a) a duplicate entry in zPCI internal device list

  * b) an attempt to enable the device with a stale function handle

  * In case b) the device will be placed in error state which makes it
  unusable.

  [Fix]

  * b76fee1bc56c31a9d2a49592810eba30cc06d61a b76fee1bc56c "s390/pci:
  ignore stale configuration request event"

  [Test Case]

  * Setup an Ubuntu Server 20.04 (focal) Linux operating system on an
  IBM Z or LinuxONE III LPAR.

  * It's now easiest to test on KVM using virtio-pci (on s390x).

  * Start a test virtual machine: sudo virsh start 

  * Attach and hotplug a virtio-pci device: sudo virsh attach-device
   hotplug_pci_block.xml

  * Where hotplug_pci_block.xml looks like:
 


   



 

  [Regression Potential]

  * The regression risk is moderate, since the modification is very
  limited and therefore manageable (additional if statement - two lines
  of code) and easily testable on KVM using virtio-pci.

  * The changes are in the zPCI event code, so in worst-case it can
  happen that the event handling get harmed which may break zPCI
  entirely, affecting all PCI devices incl. virtio-pci (on s390x).

  * A bug in PCI 'availability' handling also just lead to wrong states
  of PCI devices which make them unavailable, hence unusable.

  * Notice that zPCI is the s390x-specific PCI implementation,
  modifications here do not affect any other architecture.

  * And zPCI devices are less wide-spread compared to ccw devices on
  s390x.

  * On top a test kernel was build and made available for further
  testing atesting can be easily done with virtio-pci on KVM.

  [Other]

  * The fix/patch got upstream accepted with kernel v5.9-rc2.

  * But it landed already in groovy's proposed kernel 5.8
  (Ubuntu-5.8.0-18.19), due to 'Groovy update: v5.8.4 upstream stable
  release' that is handled in LP 1893048.

  * Hence this fix/patch need to be applied to focal only.

  __

  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-21 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
focal' to 'verification-done-focal'. If the problem still exists, change
the tag 'verification-needed-focal' to 'verification-failed-focal'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  Fix Released

Bug description:
  SRU Justification:
  ==

  [Impact]

  * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
  s390x, it can be detected as an entry in CLP List PCI functions and
  via the hot-plug event.

  * (This is basically equivalent to boot time probing on other
  architectures.)

  * In such a case the hot-plug event will be stale, but Linux still
  tries to add and enable the device which leads to:

  * a) a duplicate entry in zPCI internal device list

  * b) an attempt to enable the device with a stale function handle

  * In case b) the device will be placed in error state which makes it
  unusable.

  [Fix]

  * b76fee1bc56c31a9d2a49592810eba30cc06d61a b76fee1bc56c "s390/pci:
  ignore stale configuration request event"

  [Test Case]

  * Setup an Ubuntu Server 20.04 (focal) Linux operating system on an
  IBM Z or LinuxONE III LPAR.

  * It's now easiest to test on KVM using virtio-pci (on s390x).

  * Start a test virtual machine: sudo virsh start 

  * Attach and hotplug a virtio-pci device: sudo virsh attach-device
   hotplug_pci_block.xml

  * Where hotplug_pci_block.xml looks like:
 


   



 

  [Regression Potential]

  * The regression risk is moderate, since the modification is very
  limited and therefore manageable (additional if statement - two lines
  of code) and easily testable on KVM using virtio-pci.

  * The changes are in the zPCI event code, so in worst-case it can
  happen that the event handling get harmed which may break zPCI
  entirely, affecting all PCI devices incl. virtio-pci (on s390x).

  * A bug in PCI 'availability' handling also just lead to wrong states
  of PCI devices which make them unavailable, hence unusable.

  * Notice that zPCI is the s390x-specific PCI implementation,
  modifications here do not affect any other architecture.

  * And zPCI devices are less wide-spread compared to ccw devices on
  s390x.

  * On top a test kernel was build and made available for further
  testing atesting can be easily done with virtio-pci on KVM.

  [Other]

  * The fix/patch got upstream accepted with kernel v5.9-rc2.

  * But it landed already in groovy's proposed kernel 5.8
  (Ubuntu-5.8.0-18.19), due to 'Groovy update: v5.8.4 upstream stable
  release' that is handled in LP 1893048.

  * Hence this fix/patch need to be applied to focal only.

  __

  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : 

[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-15 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  Fix Released

Bug description:
  SRU Justification:
  ==

  [Impact]

  * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
  s390x, it can be detected as an entry in CLP List PCI functions and
  via the hot-plug event.

  * (This is basically equivalent to boot time probing on other
  architectures.)

  * In such a case the hot-plug event will be stale, but Linux still
  tries to add and enable the device which leads to:

  * a) a duplicate entry in zPCI internal device list

  * b) an attempt to enable the device with a stale function handle

  * In case b) the device will be placed in error state which makes it
  unusable.

  [Fix]

  * b76fee1bc56c31a9d2a49592810eba30cc06d61a b76fee1bc56c "s390/pci:
  ignore stale configuration request event"

  [Test Case]

  * Setup an Ubuntu Server 20.04 (focal) Linux operating system on an
  IBM Z or LinuxONE III LPAR.

  * It's now easiest to test on KVM using virtio-pci (on s390x).

  * Start a test virtual machine: sudo virsh start 

  * Attach and hotplug a virtio-pci device: sudo virsh attach-device
   hotplug_pci_block.xml

  * Where hotplug_pci_block.xml looks like:
 


   



 

  [Regression Potential]

  * The regression risk is moderate, since the modification is very
  limited and therefore manageable (additional if statement - two lines
  of code) and easily testable on KVM using virtio-pci.

  * The changes are in the zPCI event code, so in worst-case it can
  happen that the event handling get harmed which may break zPCI
  entirely, affecting all PCI devices incl. virtio-pci (on s390x).

  * A bug in PCI 'availability' handling also just lead to wrong states
  of PCI devices which make them unavailable, hence unusable.

  * Notice that zPCI is the s390x-specific PCI implementation,
  modifications here do not affect any other architecture.

  * And zPCI devices are less wide-spread compared to ccw devices on
  s390x.

  * On top a test kernel was build and made available for further
  testing atesting can be easily done with virtio-pci on KVM.

  [Other]

  * The fix/patch got upstream accepted with kernel v5.9-rc2.

  * But it landed already in groovy's proposed kernel 5.8
  (Ubuntu-5.8.0-18.19), due to 'Groovy update: v5.8.4 upstream stable
  release' that is handled in LP 1893048.

  * Hence this fix/patch need to be applied to focal only.

  __

  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-15 Thread Khaled El Mously
** Changed in: linux (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  Fix Released

Bug description:
  SRU Justification:
  ==

  [Impact]

  * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
  s390x, it can be detected as an entry in CLP List PCI functions and
  via the hot-plug event.

  * (This is basically equivalent to boot time probing on other
  architectures.)

  * In such a case the hot-plug event will be stale, but Linux still
  tries to add and enable the device which leads to:

  * a) a duplicate entry in zPCI internal device list

  * b) an attempt to enable the device with a stale function handle

  * In case b) the device will be placed in error state which makes it
  unusable.

  [Fix]

  * b76fee1bc56c31a9d2a49592810eba30cc06d61a b76fee1bc56c "s390/pci:
  ignore stale configuration request event"

  [Test Case]

  * Setup an Ubuntu Server 20.04 (focal) Linux operating system on an
  IBM Z or LinuxONE III LPAR.

  * It's now easiest to test on KVM using virtio-pci (on s390x).

  * Start a test virtual machine: sudo virsh start 

  * Attach and hotplug a virtio-pci device: sudo virsh attach-device
   hotplug_pci_block.xml

  * Where hotplug_pci_block.xml looks like:
 


   



 

  [Regression Potential]

  * The regression risk is moderate, since the modification is very
  limited and therefore manageable (additional if statement - two lines
  of code) and easily testable on KVM using virtio-pci.

  * The changes are in the zPCI event code, so in worst-case it can
  happen that the event handling get harmed which may break zPCI
  entirely, affecting all PCI devices incl. virtio-pci (on s390x).

  * A bug in PCI 'availability' handling also just lead to wrong states
  of PCI devices which make them unavailable, hence unusable.

  * Notice that zPCI is the s390x-specific PCI implementation,
  modifications here do not affect any other architecture.

  * And zPCI devices are less wide-spread compared to ccw devices on
  s390x.

  * On top a test kernel was build and made available for further
  testing atesting can be easily done with virtio-pci on KVM.

  [Other]

  * The fix/patch got upstream accepted with kernel v5.9-rc2.

  * But it landed already in groovy's proposed kernel 5.8
  (Ubuntu-5.8.0-18.19), due to 'Groovy update: v5.8.4 upstream stable
  release' that is handled in LP 1893048.

  * Hence this fix/patch need to be applied to focal only.

  __

  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-03 Thread Frank Heimes
Kernel SRU request submitted:
https://lists.ubuntu.com/archives/kernel-team/2020-September/thread.html#113190
Updating status to 'In Progress'.

** Changed in: linux (Ubuntu Focal)
   Status: New => In Progress

** Changed in: ubuntu-z-systems
   Status: New => In Progress

** Description changed:

+ SRU Justification:
+ ==
+ 
+ [Impact]
+ 
+ * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
+ s390x, it can be detected as an entry in CLP List PCI functions and via
+ the hot-plug event.
+ 
+ * (This is basically equivalent to boot time probing on other
+ architectures.)
+ 
+ * In such a case the hot-plug event will be stale, but Linux still tries
+ to add and enable the device which leads to:
+ 
+ * a) a duplicate entry in zPCI internal device list
+ 
+ * b) an attempt to enable the device with a stale function handle
+ 
+ * In case b) the device will be placed in error state which makes it
+ unusable.
+ 
+ [Fix]
+ 
+ * b76fee1bc56c31a9d2a49592810eba30cc06d61a b76fee1bc56c "s390/pci:
+ ignore stale configuration request event"
+ 
+ [Test Case]
+ 
+ * Setup an Ubuntu Server 20.04 (focal) Linux operating system on an IBM
+ Z or LinuxONE III LPAR.
+ 
+ * It's now easiest to test on KVM using virtio-pci (on s390x).
+ 
+ * Start a test virtual machine: sudo virsh start 
+ 
+ * Attach and hotplug a virtio-pci device: sudo virsh attach-device
+  hotplug_pci_block.xml
+ 
+ * Where hotplug_pci_block.xml looks like:
+
+   
+   
+  
+   
+   
+   
+
+ 
+ [Regression Potential]
+ 
+ * The regression risk is moderate, since the modification is very
+ limited and therefore manageable (additional if statement - two lines of
+ code) and easily testable on KVM using virtio-pci.
+ 
+ * The changes are in the zPCI event code, so in worst-case it can happen
+ that the event handling get harmed which may break zPCI entirely,
+ affecting all PCI devices incl. virtio-pci (on s390x).
+ 
+ * A bug in PCI 'availability' handling also just lead to wrong states of
+ PCI devices which make them unavailable, hence unusable.
+ 
+ * Notice that zPCI is the s390x-specific PCI implementation,
+ modifications here do not affect any other architecture.
+ 
+ * And zPCI devices are less wide-spread compared to ccw devices on
+ s390x.
+ 
+ * On top a test kernel was build and made available for further testing
+ atesting can be easily done with virtio-pci on KVM.
+ 
+ [Other]
+ 
+ * The fix/patch got upstream accepted with kernel v5.9-rc2.
+ 
+ * But it landed already in groovy's proposed kernel 5.8
+ (Ubuntu-5.8.0-18.19), due to 'Groovy update: v5.8.4 upstream stable
+ release' that is handled in LP 1893048.
+ 
+ * Hence this fix/patch need to be applied to focal only.
+ 
+ __
+ 
  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading
  
- a) to a duplicate entry in zPCI internal device list 
+ a) to a duplicate entry in zPCI internal device list
  b) an attempt to enable the device witha stale function handle
  
  Part b) would lead to the device being place in the error state
  and make it unusable.
  
  This can most easily be reproduced using KVM and doing
  
  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml
  
  Where hotplug_pci_block.xml looks like the following:
  
  
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
  
- 
  
  The problem is fixed with the 3-line upstream commit
  
  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event
  
  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  In Progress
Status in linux source package in Groovy:
  Fix Released

Bug description:
  SRU Justification:
  ==

  [Impact]

  * If a PCI device (incl. virtio-pci) is hot-plugged during boot-up on
  s390x, it can be detected as an entry in CLP List PCI functions and
  via the hot-plug event.

  * (This is basically equivalent to boot time probing on other
  architectures.)

  * In such a case the hot-plug event will be stale, but Linux still
  tries to add and enable the device which leads to:

  * a) a duplicate 

[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-03 Thread Frank Heimes
While working on this SRU a set of patched kernel packages was created that 
were now made available here for further testing:
https://people.canonical.com/~fheimes/lp1893778/

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  New
Status in linux source package in Groovy:
  Fix Released

Bug description:
  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list 
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  
  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-01 Thread Frank Heimes
** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Frank Heimes (fheimes)

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  New
Status in linux source package in Groovy:
  Fix Released

Bug description:
  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list 
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  
  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1893778] Re: [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable device

2020-09-01 Thread Frank Heimes
The commit mentioned got upstream accepted with v5.9-rc2, but already landed in 
groovy via Groovy update: v5.8.4 upstream stable release of LP 1893048.
Hence only SRU to Focal is needed.

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Groovy)
   Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
   Status: New

** Changed in: linux (Ubuntu Groovy)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1893778

Title:
  [UBUNTU 20.04] zPCI device hot-plug during boot may result in unusable
  device

Status in Ubuntu on IBM z Systems:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  New
Status in linux source package in Groovy:
  Fix Released

Bug description:
  When a PCI device (including virtio-pci for which this is easiest to test)
  is hot-plugged while Linux is still booting, it can be detected as
  an entry in CLP List PCI Functions (basically equivalent to boot time probing
  on other architectures) and with the hot-plug event.
  In this case the hot-plug event will be stale but Linux still
  tried to add and enable the device leading

  a) to a duplicate entry in zPCI internal device list 
  b) an attempt to enable the device witha stale function handle

  Part b) would lead to the device being place in the error state
  and make it unusable.

  This can most easily be reproduced using KVM and doing

  # sudo virsh start myguest && sudo virsh attach-device myguest
  hotplug_pci_block.xml

  Where hotplug_pci_block.xml looks like the following:

  
  
  
  
  
  
  
  

  
  The problem is fixed with the 3-line upstream commit

  b76fee1bc56c31a9d2a49592810eba30cc06d61a s390/pci: ignore stale
  configuration request event

  I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
  cherry-picks cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp