aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-04-12s390/pci: use mutex not spinlock for zbus listNiklas Schnelle1-7/+7
In a later change we will first collect all PCI functions from the CLP List PCI functions call, then register them to/creating the relevant zbus. Then only after we've created our virtual bus structure will we scan all zbusses iterating over the zbus list. Since scanning is relatively slow a spinlock is a bad fit for protecting the loop over the devices on the zbus. Furthermore doing the probing on the bus we need to use pci_lock_rescan_remove() as devices are added to the PCI subsystem and that is a mutex which can't be locked nested inside a spinlock section. Note that the contention of this lock should be very low either way as zbusses are only added/removed concurrently on hotplug events. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: separate zbus creation from scanningNiklas Schnelle4-97/+177
In the existing code the creation of the PCI bus and the scanning of function zero all happens in zpci_scan_bus(). This in turn requires functions to be enabled and their resources to be available before the PCI bus is even created. This not only means that functions are enabled long before they are actually made available to the common PCI subsystem. In case of functions with non-zero devfn which appeared before the function with devfn zero they can wait arbitrarily long in this enabled but not scanned state. Fix this by separating the creation of the PCI bus from scanning it and only prepare, that is enable and setup MMIO bus resources, functions just before they are scanned. As they may be scanned multiple times track if we already created resources in the zdev. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: do more bus setup in zpci_bus_scan()Niklas Schnelle1-13/+20
Pull setting the maximum bus speed and multifunction attribute into zpci_bus_scan() in preparation for handling bus creation separately from scanning the bus. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: introduce zpci_bus_scan_device()Niklas Schnelle3-17/+28
To match zpci_bus_scan_device() and the PCI common code terminology and to remove some code duplication, we pull the multiple uses of pci_scan_single_device() into a function. For now this has the side effect of adding each device to the PCI bus separately and locking and unlocking the rescan/remove lock for each instead of just once per bus. This is clearly less efficient but provides a correct intermediate behavior until a follow on change does both the adding and scanning only once per bus. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/traps: convert pgm_check.S to CHeiko Carstens5-181/+59
Convert the program check table to C. Which allows to get rid of yet another assembler file, and also enables proper type checking for the table. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/cio: use DECLARE_WAIT_QUEUE_HEAD for static work_queue_head_tVineeth Vijayan1-2/+1
Use DECLARE_WAIT_QUEUE_HEAD to declare and statically initialize the work_queue_head_t. Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/protvirt: fix error return code in uv_info_init()zhongbaisong1-1/+3
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com> Fixes: 37564ed834ac ("s390/uv: add prot virt guest/host indication files") Link: https://lore.kernel.org/r/2f7d62a4-3e75-b2b4-951b-75ef8ef59d16@huawei.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/entry: save the caller of psw_idleVasily Gorbik1-0/+1
Currently psw_idle does not allocate a stack frame and does not save its r14 and r15 into the save area. Even though this is valid from call ABI point of view, because psw_idle does not make any calls explicitly, in reality psw_idle is an entry point for controlled transition into serving interrupts. So, in practice, psw_idle stack frame is analyzed during stack unwinding. Depending on build options that r14 slot in the save area of psw_idle might either contain a value saved by previous sibling call or complete garbage. [task 0000038000003c28] do_ext_irq+0xd6/0x160 [task 0000038000003c78] ext_int_handler+0xba/0xe8 [task *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs ([task 0000038000003dd8] 0x0) [task 0000038000003e10] default_idle_call+0x42/0x148 [task 0000038000003e30] do_idle+0xce/0x160 [task 0000038000003e70] cpu_startup_entry+0x36/0x40 [task 0000038000003ea0] arch_call_rest_init+0x76/0x80 So, to make a stacktrace nicer and actually point for the real caller of psw_idle in this frequently occurring case, make psw_idle save its r14. [task 0000038000003c28] do_ext_irq+0xd6/0x160 [task 0000038000003c78] ext_int_handler+0xba/0xe8 [task *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs ([task 0000038000003dd8] arch_cpu_idle+0x3c/0xd0) [task 0000038000003e10] default_idle_call+0x42/0x148 [task 0000038000003e30] do_idle+0xce/0x160 [task 0000038000003e70] cpu_startup_entry+0x36/0x40 [task 0000038000003ea0] arch_call_rest_init+0x76/0x80 Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/entry: avoid setting up backchain in ext|io handlersVasily Gorbik1-4/+2
Currently when interrupt arrives to cpu while in kernel context INT_HANDLER macro (used for ext_int_handler and io_int_handler) allocates new stack frame and pt_regs on the kernel stack and sets up the backchain to jump over the pt_regs to the frame which has been interrupted. This is not ideal to two reasons: 1. This hides the fact that kernel stack contains interrupt frame in it and hence breaks arch_stack_walk_reliable(), which needs to know that to guarantee "reliability" and checks that there are no pt_regs on the way. 2. It breaks the backchain unwinder logic, which assumes that the next stack frame after an interrupt frame is reliable, while it is not. In some cases (when r14 contains garbage) this leads to early unwinding termination with an error, instead of marking frame as unreliable and continuing. To address that, only set backchain to 0. Fixes: 56e62a737028 ("s390: convert to generic entry") Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-07s390/sclp: use LIST_HEAD for InitializationVineeth Vijayan4-16/+8
For static initialization of list_head variable, use LIST_HEAD instead of INIT_LIST_HEAD function. Suggested-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-07s390: use DEFINE_SPINLOCK for initializationVineeth Vijayan4-8/+4
For static initialization of spinlock_t variable, use DEFINE_SPINLOCK instead of explicitly calling spin_lock_init(). Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-07s390/setup: use memblock_free_late() to free old stackHeiko Carstens1-1/+1
Use memblock_free_late() to free the old machine check stack to the buddy allocator instead of leaking it. Fixes: b61b1595124a ("s390: add stack for machine check handler") Cc: Vasily Gorbik <gor@linux.ibm.com> Acked-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/mm: fix phys vs virt confusion in mark_kernel_pXd() functions familyAlexander Gordeev1-4/+4
Due to historical reasons mark_kernel_pXd() functions misuse the notion of physical vs virtual addresses difference. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/vfio-ap: fix circular lockdep when setting/clearing crypto masksTony Krowiak2-95/+215
This patch fixes a lockdep splat introduced by commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated"). The lockdep splat only occurs when starting a Secure Execution guest. Crypto virtualization (vfio_ap) is not yet supported for SE guests; however, in order to avoid this problem when support becomes available, this fix is being provided. The circular locking dependency was introduced when the setting of the masks in the guest's APCB was executed while holding the matrix_dev->lock. While the lock is definitely needed to protect the setting/unsetting of the matrix_mdev->kvm pointer, it is not necessarily critical for setting the masks; so, the matrix_dev->lock will be released while the masks are being set or cleared. Keep in mind, however, that another process that takes the matrix_dev->lock can get control while the masks in the guest's APCB are being set or cleared as a result of the driver being notified that the KVM pointer has been set or unset. This could result in invalid access to the matrix_mdev->kvm pointer by the intervening process. To avoid this scenario, two new fields are being added to the ap_matrix_mdev struct: struct ap_matrix_mdev { ... bool kvm_busy; wait_queue_head_t wait_for_kvm; ... }; The functions that handle notification that the KVM pointer value has been set or cleared will set the kvm_busy flag to true until they are done processing at which time they will set it to false and wake up the tasks on the matrix_mdev->wait_for_kvm wait queue. Functions that require access to matrix_mdev->kvm will sleep on the wait queue until they are awakened at which time they can safely access the matrix_mdev->kvm field. Fixes: f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated") Cc: stable@vger.kernel.org Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cio: remove duplicate struct ccw1 declarationWan Jiabing1-3/+0
struct ccw1 is declared twice. One has been declared at 21st line. Remove the duplicate. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cio: use DECLARE_WAIT_QUEUE_HEAD() for wait_queueShixin Liu1-2/+1
wait_queue_head_t can be initialized automatically with DECLARE_WAIT_QUEUE_HEAD() rather than explicitly calling init_waitqueue_head(). Signed-off-by: Shixin Liu <liushixin2@huawei.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cio: use DEFINE_SPINLOCK() for spinlockShixin Liu1-2/+1
static spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by: Shixin Liu <liushixin2@huawei.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/pci: expose UID uniqueness guaranteeNiklas Schnelle2-3/+20
On s390 each PCI device has a user-defined ID (UID) exposed under /sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI device's primary index and to match the device within Linux to the device configured in the hypervisor. To serve as a primary identifier the UID must be unique within the Linux instance, this is guaranteed by the platform if and only if the UID Uniqueness Checking flag is set within the CLP List PCI Functions response. While the UID has been exposed to userspace since commit ac4995b9d570 ("s390/pci: add some new arch specific pci attributes") whether or not the platform guarantees its uniqueness for the lifetime of the Linux instance while defined is not visible from userspace. Remedy this by exposing this as a per device attribute at /sys/bus/pci/devices/<dev>/uid_is_unique Keeping this a per device attribute allows for maximum flexibility if we ever end up with some devices not having a UID or not enjoying the guaranteed uniqueness. Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/irq: fix reading of ext_params2 field from lowcoreHeiko Carstens1-1/+1
The contents of the ext_params2 field of the lowcore should just be copied to the pt_regs structure, not dereferenced. Fixes crashes / program check loops like this: Krnl PSW : 0404c00180000000 00000000d6d02b3c (do_ext_irq+0x74/0x170) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 80000000000b974e 00000000d71abee0 00000000d71abee0 0000000080030000 000000000000000f 0000000000000000 0000000000000000 0000000000000001 00000380000bf918 00000000d73ef780 00000380000bf518 0000000080348000 00000000d6d13350 00000000d6d02b1e 00000380000bf428 Krnl Code: 00000000d6d02b2e: 58100080 l %r1,128 00000000d6d02b32: 5010b0a4 st %r1,164(%r11) #00000000d6d02b36: e31001b80104 lg %r1,4536 >00000000d6d02b3c: e31010000004 lg %r1,0(%r1) 00000000d6d02b42: e310b0a80024 stg %r1,168(%r11) 00000000d6d02b48: c01000242270 larl %r1,00000000d7187028 00000000d6d02b4e: d5071000b010 clc 0(8,%r1),16(%r11) 00000000d6d02b54: a784001b brc 8,00000000d6d02b8a Call Trace: [<00000000d6d02b3c>] do_ext_irq+0x74/0x170 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4 [<00000000d621d266>] die+0x106/0x188 [<00000000d62305b8>] do_no_context+0xc8/0x100 [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0 [<00000000d6d0e950>] pgm_check_handler+0x118/0x160 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4 [<00000000d621d266>] die+0x106/0x188 [<00000000d62305b8>] do_no_context+0xc8/0x100 [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0 [<00000000d6d0e950>] pgm_check_handler+0x118/0x160 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4 [<0000000000000000>] 0x0 [<00000000d6d0e57a>] default_idle_call+0x42/0x110 [<00000000d629856e>] do_idle+0xce/0x160 [<00000000d62987be>] cpu_startup_entry+0x36/0x40 [<00000000d621f2f2>] smp_start_secondary+0x82/0x88 Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Fixes: 56e62a737028 ("s390: convert to generic entry") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/unwind: add machine check handler stackVasily Gorbik2-1/+12
Fixes: b61b1595124a ("s390: add stack for machine check handler") Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cpcmd: fix inline assembly register clobberingAlexander Gordeev1-2/+4
Register variables initialized using arithmetic. That leads to kasan instrumentaton code corrupting the registers contents. Follow GCC guidlines and use temporary variables for assigning init values to register variables. Fixes: 94c12cc7d196 ("[S390] Inline assembly cleanup.") Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-28s390/pci: fix DMA cleanup on hard deconfigureNiklas Schnelle1-6/+5
In commit dee60c0dbc83 ("s390/pci: add zpci_event_hard_deconfigured()") we added a zdev_enabled() check to what was previously an uncoditional call to zpci_disable_device(). There are two problems with that. Firstly zpci_had_deconfigured() is only called on event 0x0304 for which the device is always already disabled by the platform so it is always false. Secondly zpci_disable_device() not only disables the device but also calls zpci_dma_exit_device() which is thus not called and we leak the DMA tables. Fix this by calling zpci_disable_device() unconditionally to perform Linux side cleanup including the freeing of DMA tables. Fixes: dee60c0dbc83 ("s390/pci: add zpci_event_hard_deconfigured()") Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-28s390/spinlock: remove align attribute from arch_spinlock_tHeiko Carstens1-1/+1
No need to add an align attribute for an integer. The alignment is correct anyway. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-28MAINTAINERS: add backups for s390 vfio driversMatthew Rosato1-1/+3
Add a backup for s390 vfio-pci, an additional backup for vfio-ccw and replace the backup for vfio-ap as Pierre is focusing on other areas. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Eric Farman <farman@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Jason J. Herne <jjherne@linux.ibm.com> Link: https://lore.kernel.org/r/1616679712-7139-1-git-send-email-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: fix initializing and updating of vdso_dataHeiko Carstens1-3/+8
Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns incorrect values when time is provided via vdso instead of system call: vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vdso_ts.tv_nsec = 380985507 sys_ts_nsec = 1446923235377, sys_ts.tv_sec = 1446, sys_ts.tv_nsec = 923235377 Within the s390 specific vdso function __arch_get_hw_counter() reads tod clock steering values from the arch_data member of the passed in vdso_data structure. Problem is that only for the CS_HRES_COARSE vdso_data arch_data is initialized and gets updated. The CS_RAW specific vdso_data does not contain any valid tod_clock_steering information, which explains the different values. Fix this by initializing and updating all vdso_datas. Reported-by: Li Wang <liwang@redhat.com> Tested-by: Li Wang <liwang@redhat.com> Fixes: 1ba2d6c0fd4e ("s390/vdso: simplify __arch_get_hw_counter()") Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osiris Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: fix tod_steering_delta typeHeiko Carstens1-1/+1
The s390 specific vdso function __arch_get_hw_counter() is supposed to consider tod clock steering. If a tod clock steering event happens and the tod clock is set to a new value __arch_get_hw_counter() will not return the real tod clock value but slowly drift it from the old delta until the returned value finally matches the real tod clock value again. Unfortunately the type of tod_steering_delta unsigned while it is supposed to be signed. It depends on if tod_steering_delta is negative or positive in which direction the vdso code drifts the clock value. Worst case is now that instead of drifting the clock slowly it will jump into the opposite direction by a factor of two. Fix this by simply making tod_steering_delta signed. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: <stable@vger.kernel.org> # 5.10 Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: copy tod_steering_delta value to vdso_data pageHeiko Carstens1-0/+1
When converting the vdso assembler code to C it was forgotten to actually copy the tod_steering_delta value to vdso_data page. Which in turn means that tod clock steering will not work correctly. Fix this by simply copying the value whenever it is updated. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: <stable@vger.kernel.org> # 5.10 Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-24s390/crc32-vx: couple of typo fixesBhaskar Chowdhury1-2/+2
s/defintions/definitions/ s/intermedate/intermediate/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210322130533.3805976-1-unixbhaskar@gmail.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-24s390/uv: fix prot virt host indication compilationJanosch Frank1-1/+7
prot_virt_host is only available if CONFIG_KVM is enabled. So lets use a variable initialized to zero and overwrite it when that config option is set with prot_virt_host. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Fixes: 37564ed834ac ("s390/uv: add prot virt guest/host indication files") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/kernel: fix a typoBhaskar Chowdhury1-1/+1
s/struture/structure/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/20210322062500.3109603-1-unixbhaskar@gmail.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/qdio: let driver manage the QAOBJulian Wiedmann7-190/+66
We are spending way too much effort on qdio-internal bookkeeping for QAOB management & caching, and it's still not robust. Once qdio's TX path has detached the QAOB from a PENDING buffer, we lost all track of it until it shows up in a CQ notification again. So if the device is torn down before that notification arrives, we leak the QAOB. Just have the driver take care of it, and simply pass down a QAOB if they want a TX with async-completion capability. For a buffer in PENDING state that requires the QAOB for final completion, qeth can now also try to recycle the buffer's QAOB rather than unconditionally freeing it. This also eliminates the qdio_outbuf_state array, which was only needed to transfer the aob->user1 tag from the driver to the qdio layer. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Acked-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/pci: move zpci_remove_device() to bus codeNiklas Schnelle5-37/+38
The zpci_remove_device() function removes the device from the PCI common code core which is an operation dealing primarily with the zbus and PCI bus code. With that and to match an upcoming refactoring of the symmetric scanning part move it to the bus code. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/pci: unify de-/configure for slots and eventsNiklas Schnelle4-88/+100
A zPCI event with PEC 0x0301 for an existing zPCI device goes through the same actions as enable_slot(). Similarly a zPCI event with PEC 0x0303 does the same steps as disable_slot(). We can thus unify both actions as zpci_configure_device() respectively zpci_deconfigure_device(). Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/cio: add CRW inject functionalityVineeth Vijayan6-1/+222
This patch introduces the mechanism to inject artificial events to the CIO layer. One of the main-event type which triggers the CommonIO operations are Channel Report events. When a malfunction or other condition affecting channel-subsystem operation is recognized, a Channel Report Word (consisting of one or more CRWs) describing the condition is made pending for retrieval and analysis by the program. The CRW contains information concerning the identity and state of a facility following the detection of the malfunction or other condition. The patch introduces two debugfs interfaces which can be used to inject 'artificial' events from the userspace. It is intended to provide an easy means to increase the test coverage for CIO code. And this functionality can be enabled via a new configuration option CONFIG_CIO_INJECT. The newly introduces debugfs interfaces can be used as mentioned below to generate different fake-events. To use the crw_inject, first we should enable it by using enable_inject interface. i.e echo 1 > /sys/kernel/debug/s390/cio/enable_inject After the first step, user can simulate CRW as follows: echo <solicited> <overflow> <chaining> <rsc> <ancillary> <erc> <rsid> \ > /sys/kernel/debug/s390/cio/crw_inject Example: A permanent error ERC on CHPID 0x60 would look like this: echo 0 0 0 4 0 6 0x60 > /sys/kernel/debug/s390/cio/crw_inject and an initialized ERC on the same CHPID: echo 0 0 0 4 0 2 0x60 > /sys/kernel/debug/s390/cio/crw_inject Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/cio: introduce CIO debugfs directoryVineeth Vijayan3-1/+27
This patch introduces an s390 Common I/O layer debugfs directory that is intended to provide access to debugging-related CIO functions and data. The directory is created as /sys/kernel/debug/s390/cio Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/pci: add zpci_event_hard_deconfigured()Niklas Schnelle1-15/+24
Extract the handling of PEC 0x0304 into a function and make sure we only attempt to disable the function if it is enabled. Also check for errors returned by zpci_disable_device() and leave the function alone if there are any. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/pci: deconfigure device on releaseNiklas Schnelle1-0/+5
When zpci_release_device() is called on a zPCI function that is still configured it would not be deconfigured. Until now this hasn't caused any problems because zpci_zdev_put() is only ever called for devices in Standby or Reserved. Fix it by adding sclp_pci_deconfigure() to the switch when in Configured state. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/pci: refactor zpci function statesNiklas Schnelle3-14/+5
The current zdev->state mixes the configuration states supported by CLP with an additional Online state which is used inconsistently to include enabled zPCI functions which are not yet visible to the common PCI subsytem. In preparation for a clean separation between architected configuration states and fine grained function states remove the Online function state. Where we previously checked for Online it is more accurate to check if the function is enabled to avoid an edge case where a disabled device was still treated as Online. This also simplifies checks whether a function is configured as this is now directly reflected by its function state. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/sclp: increase sclp console line lengthPeter Oberparleiter2-22/+6
Kernel and console/TTY messages written to the SCLP line mode console are wrapped at 80 characters per line by the associated SCLP driver. This makes long lines of output difficult to read, and requires editing of wrapped lines copied from the output device. Neither the firmware interface used to access the SCLP console, nor the HMC "Operating System Messages" web interface that displays these messages require such a length limit. Also other operating systems such as z/VM do not impose similar limits on messages they emit to the same console device. This patch therefore increases the limit to 320 characters per line to make SCLP line mode console output more readable. As a result 99% of lines written during a typical boot will not be wrapped, compared to about 50% wrapped lines at 80 characters per line. Another positive side-effect of this change is that the HMC console interface is able to keep more messages in its history buffer due to fewer line-breaks being generated. In a worst case scenario this means that a 4k console buffer is emitted with the last ~400 bytes empty (320 text + 78 headers). This is more than offset by the fact that each line that is not truncated saves 78 header bytes in the buffer. As a result the actual number of emitted buffers should be about the same as with the 80 character limit. This patch also removes the differentiation between line lengths of SCLP line mode output on z/VM and non-z/VM systems. While the z/VM hypervisor adds a prefix in front of each line ('xx: ' where xx is the number of the CPU issuing the message), adjusting Linux line lengths did not significantly increase readability of console output, and makes even less of a difference with longer lines. Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-22s390/uv: add prot virt guest/host indication filesJanosch Frank1-1/+36
Let's export the prot_virt_guest and prot_virt_host variables into the UV sysfs firmware interface to make them easily consumable by administrators. prot_virt_host being 1 indicates that we did the UV initialization (opt-in) prot_virt_guest being 1 indicates that the UV indicates the share and unshare ultravisor calls which is an indication that we are running as a protected guest. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-21Linux 5.12-rc4Linus Torvalds1-1/+1
2021-03-21io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALLStefan Metzmacher1-4/+20
Without that it's not safe to use them in a linked combination with others. Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE should be possible. We already handle short reads and writes for the following opcodes: - IORING_OP_READV - IORING_OP_READ_FIXED - IORING_OP_READ - IORING_OP_WRITEV - IORING_OP_WRITE_FIXED - IORING_OP_WRITE - IORING_OP_SPLICE - IORING_OP_TEE Now we have it for these as well: - IORING_OP_SENDMSG - IORING_OP_SEND - IORING_OP_RECVMSG - IORING_OP_RECV For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC flags in order to call req_set_fail_links(). There might be applications arround depending on the behavior that even short send[msg]()/recv[msg]() retuns continue an IOSQE_IO_LINK chain. It's very unlikely that such applications pass in MSG_WAITALL, which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'. It's expected that the low level sock_sendmsg() call just ignores MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set SO_ZEROCOPY. We also expect the caller to know about the implicit truncation to MAX_RW_COUNT, which we don't detect. cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/c4e1a4cc0d905314f4d5dc567e65a7b09621aab3.1615908477.git.metze@samba.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-21io-wq: ensure task is running before processing task_workJens Axboe1-2/+6
Mark the current task as running if we need to run task_work from the io-wq threads as part of work handling. If that is the case, then return as such so that the caller can appropriately loop back and reset if it was part of a going-to-sleep flush. Fixes: 3bfe6106693b ("io-wq: fork worker threads from original task") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-21signal: don't allow STOP on PF_IO_WORKER threadsEric W. Biederman1-1/+2
Just like we don't allow normal signals to IO threads, don't deliver a STOP to a task that has PF_IO_WORKER set. The IO threads don't take signals in general, and have no means of flushing out a stop either. Longer term, we may want to look into allowing stop of these threads, as it relates to eg process freezing. For now, this prevents a spin issue if a SIGSTOP is delivered to the parent task. Reported-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-03-21signal: don't allow sending any signals to PF_IO_WORKER threadsJens Axboe1-0/+3
They don't take signals individually, and even if they share signals with the parent task, don't allow them to be delivered through the worker thread. Linux does allow this kind of behavior for regular threads, but it's really a compatability thing that we need not care about for the IO threads. Reported-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-21ext4: initialize ret to suppress smatch warningTheodore Ts'o1-1/+1
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: stop inode update before returnPan Bian1-1/+3
The inode update should be stopped before returing the error code. Signed-off-by: Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/20210117085732.93788-1-bianpan2016@163.com Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@kernel.org Reviewed-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: fix rename whiteout with fast commitHarshad Shirwadkar3-2/+12
This patch adds rename whiteout support in fast commits. Note that the whiteout object that gets created is actually char device. Which imples, the function ext4_inode_journal_mode(struct inode *inode) would return "JOURNAL_DATA" for this inode. This has a consequence in fast commit code that it will make creation of the whiteout object a fast-commit ineligible behavior and thus will fall back to full commits. With this patch, this can be observed by running fast commits with rename whiteout and seeing the stats generated by ext4_fc_stats tracepoint as follows: ext4_fc_stats: dev 254:32 fc ineligible reasons: XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0, RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16; num_commits:6, ineligible: 6, numblks: 3 So in short, this patch guarantees that in case of rename whiteout, we fall back to full commits. Amir mentioned that instead of creating a new whiteout object for every rename, we can create a static whiteout object with irrelevant nlink. That will make fast commits to not fall back to full commit. But until this happens, this patch will ensure correctness by falling back to full commits. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@kernel.org Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: fix timer use-after-free on failed mountJan Kara1-1/+1
When filesystem mount fails because of corrupted filesystem we first cancel the s_err_report timer reminding fs errors every day and only then we flush s_error_work. However s_error_work may report another fs error and re-arm timer thus resulting in timer use-after-free. Fix the problem by first flushing the work and only after that canceling the s_err_report timer. Reported-by: syzbot+628472a2aac693ab0fcd@syzkaller.appspotmail.com Fixes: 2d01ddc86606 ("ext4: save error info to sb through journal if available") CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210315165906.2175-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: fix potential error in ext4_do_update_inodeShijie Luo1-4/+4
If set_large_file = 1 and errors occur in ext4_handle_dirty_metadata(), the error code will be overridden, go to out_brelse to avoid this situation. Signed-off-by: Shijie Luo <luoshijie1@huawei.com> Link: https://lore.kernel.org/r/20210312065051.36314-1-luoshijie1@huawei.com Cc: stable@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.