kernel/drivers/pci/hotplug/s390_pci_hpc.c, branch linux-rolling-stable

s390: Remove KMSG_COMPONENT macro

2025-11-24T10:45:21Z

The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter Signed-off-by: Heiko Carstens

Merge tag 's390-6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

2025-05-26T21:36:05Z

Pull s390 updates from Heiko Carstens: - Large rework of the protected key crypto code to allow for asynchronous handling without memory allocation - Speed up system call entry/exit path by re-implementing lazy ASCE handling - Add module autoload support for the diag288_wdt watchdog device driver - Get rid of s390 specific strcpy() and strncpy() implementations, and switch all remaining users to strscpy() when possible - Various other small fixes and improvements * tag 's390-6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (51 commits) s390/pci: Serialize device addition and removal s390/pci: Allow re-add of a reserved but not yet removed device s390/pci: Prevent self deletion in disable_slot() s390/pci: Remove redundant bus removal and disable from zpci_release_device() s390/crypto: Extend protected key conversion retry loop s390/pci: Fix __pcilg_mio_inuser() inline assembly s390/ptrace: Always inline regs_get_kernel_stack_nth() and regs_get_register() s390/thread_info: Cleanup header includes s390/extmem: Add workaround for DCSS unload diag s390/crypto: Rework protected key AES for true asynch support s390/cpacf: Rework cpacf_pcc() to return condition code s390/mm: Fix potential use-after-free in __crst_table_upgrade() s390/mm: Add mmap_assert_write_locked() check to crst_table_upgrade() s390/string: Remove strcpy() implementation s390/con3270: Use strscpy() instead of strcpy() s390/boot: Use strspcy() instead of strcpy() s390: Simple strcpy() to strscpy() conversions s390/pkey/crypto: Introduce xflags param for pkey in-kernel API s390/pkey: Provide and pass xflags within pkey and zcrypt layers s390/uv: Remove uv_get_secret_metadata function ...

s390/pci: Prevent self deletion in disable_slot()

2025-05-22T14:12:41Z

As disable_slot() takes a struct zpci_dev from the Configured to the Standby state. In Standby there is still a hotplug slot so this is not usually a case of sysfs self deletion. This is important because self deletion gets very hairy in terms of locking (see for example recover_store() in arch/s390/pci/pci_sysfs.c). Because the pci_dev_put() is not within the critical section of the zdev->state_lock however, disable_slot() can turn into a case of self deletion if zPCI device event handling slips between the mutex_unlock() and the pci_dev_put(). If the latter is the last put and zpci_release_device() is called this then tries to remove the hotplug slot via zpci_exit_slot() which will try to remove the hotplug slot directory the disable_slot() is part of i.e. self deletion. Prevent this by widening the zdev->state_lock critical section to include the pci_dev_put() which is then guaranteed to happen with the struct zpci_dev still in Standby state ensuring it will not lead to a zpci_release_device() call as at least the zPCI event handling code still holds a reference. Cc: stable@vger.kernel.org Fixes: a46044a92add ("s390/pci: fix zpci_zdev_put() on reserve") Reviewed-by: Gerd Bayer Tested-by: Gerd Bayer Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens

s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs

2025-05-07T11:35:05Z

With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") the code to ignore power off of a PF that has child VFs was changed from a direct return to a goto to the unlock and pci_dev_put() section. The change however left the existing pci_dev_put() untouched resulting in a doubple put. This can subsequently cause a use after free if the struct pci_dev is released in an unexpected state. Fix this by removing the extra pci_dev_put(). Cc: stable@vger.kernel.org Fixes: bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") Signed-off-by: Niklas Schnelle Reviewed-by: Gerd Bayer Signed-off-by: Heiko Carstens

PCI: Fix typos

2024-09-19T19:24:00Z

Fix typos. Signed-off-by: Bjorn Helgaas

s390/pci: introduce lock to synchronize state of zpci_dev's

2024-02-20T13:37:32Z

There's a number of tasks that need the state of a zpci device to be stable. Other tasks need to be synchronized as they change the state. State changes could be generated by the system as availability or error events, or be requested by the user through manipulations in sysfs. Some other actions accessible through sysfs - like device resets - need the state to be stable. Unsynchronized state handling could lead to unusable devices. This has been observed in cases of concurrent state changes through systemd udev rules and DPM boot control. Some breakage can be provoked by artificial tests, e.g. through repetitively injecting "recover" on a PCI function through sysfs while running a "hotplug remove/add" in a loop through a PCI slot's "power" attribute in sysfs. After a few iterations this could result in a kernel oops. So introduce a new mutex "state_lock" to guard the state property of the struct zpci_dev. Acquire this lock in all task that modify the state: - hotplug add and remove, through the PCI hotplug slot entry, - avaiability events, as reported by the platform, - error events, as reported by the platform, - during device resets, explicit through sysfs requests or implict through the common PCI layer. Break out an inner _do_recover() routine out of recover_store() to separte the necessary synchronizations from the actual manipulations of the zpci_dev required for the reset. With the following changes I was able to run the inject loops for hours without hitting an error. Signed-off-by: Gerd Bayer Reviewed-by: Niklas Schnelle Signed-off-by: Heiko Carstens

s390/pci: implement reset_slot for hotplug slot

2021-11-08T13:17:49Z

This is done by adding a zpci_hot_reset_device() call which does a low level reset of the PCI function without changing its higher level function state. This way it can be used while the zPCI function is bound to a driver and with DMA tables being controlled either through the IOMMU or DMA APIs which is prohibited when using zpci_disable_device() as that drop existing DMA translations. As this reset, unlike a normal FLR, also calls zpci_clear_irq() we need to implement arch_restore_msi_irqs() and make sure we re-enable IRQs for the PCI function if they were previously disabled. Reviewed-by: Pierre Morel Reviewed-by: Matthew Rosato Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik

s390/pci: fix zpci_zdev_put() on reserve

2021-10-04T07:49:10Z

Since commit 2a671f77ee49 ("s390/pci: fix use after free of zpci_dev") the reference count of a zpci_dev is incremented between pcibios_add_device() and pcibios_release_device() which was supposed to prevent the zpci_dev from being freed while the common PCI code has access to it. It was missed however that the handling of zPCI availability events assumed that once zpci_zdev_put() was called no later availability event would still see the device. With the previously mentioned commit however this assumption no longer holds and we must make sure that we only drop the initial long-lived reference the zPCI subsystem holds exactly once. Do so by introducing a zpci_device_reserved() function that handles when a device is reserved. Here we make sure the zpci_dev will not be considered for further events by removing it from the zpci_list. This also means that the device actually stays in the ZPCI_FN_STATE_RESERVED state between the time we know it has been reserved and the final reference going away. We thus need to consider it a real state instead of just a conceptual state after the removal. The final cleanup of PCI resources, removal from zbus, and destruction of the IOMMU stays in zpci_release_device() to make sure holders of the reference do see valid data until the release. Fixes: 2a671f77ee49 ("s390/pci: fix use after free of zpci_dev") Cc: stable@vger.kernel.org Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik

s390/pci: rename zpci_configure_device()

2021-04-30T15:17:00Z

With zpci_configure_device() now always called on a device that has already been configured on the platform level its name has become misleading. Rename it to zpci_scan_configured_device() to signify that the function now only handles the correct scanning of a newly configured PCI function taking care of the special handling necessary for function 0 and functions parked waiting for a PCI bus that can't be created without first seeing function 0. Reviewed-by: Matthew Rosato Reviewed-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens

s390/pci: narrow scope of zpci_configure_device()

2021-04-12T10:46:42Z

Currently zpci_configure_device() can be called on a zPCI function in two completely different states. Either the underlying zPCI function has already been configured by the platform and we are only doing the scanning to get it usable by Linux drivers. Or the underlying function is in Standby and we first do an SCLP to get it configured. This makes zpci_configure_device() harder to reason about. Since calling zpci_configure_device() on a function in Standby only happens in enable_slot() simply pull out the SCLP call and setting of zdev->state and thus call zpci_configure_device() under the same circumstances as in the event handling code. Reviewed-by: Matthew Rosato Reviewed-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens