- 17 Mar, 2024 4 commits
-
-
Sven Schnelle authored
With the current implementation, there are some cornercases where a host fault would be treated as a guest fault, for example when the sie instruction causes a program check. Therefore store the gmap asce in ptregs, and use that to compare the primary asce from the fault instead of matching instruction addresses. Suggested-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Sven Schnelle authored
With only one OUTSIDE user left, remove the macro and move the code directly to the machine check handler. This has the advantage that it is much easier to determine which registers are used. Signed-off-by:
-
Sven Schnelle authored
When a program check, interrupt or machine check is triggered, the PSW address is compared to a certain range of the sie64a() function to figure out whether SIE was interrupted and a cleanup of SIE is needed. This doesn't work with kprobes: If kprobes probes an instruction, it copies the instruction to the kprobes instruction page and overwrites the original instruction with an undefind instruction (Opcode 00). When this instruction is hit later, kprobes single-steps the instruction on the kprobes_instruction page. However, if this instruction is a relative branch instruction it will now point to a different location in memory due to being moved to the kprobes instruction page. If the new branch target points into sie64a() the kernel assumes it interrupted SIE when processing the breakpoint and will crash trying to access the SIE control block. Instead of comparing the address, introduce a new CIF_SIE flag which indicates whether SIE was interrupted. Signed-off-by:
-
Andy Shevchenko authored
Use more natural while (i--) pattern to clean up allocated resources. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Link: https://lore.kernel.org/r/20240222134501.236871-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
- 13 Mar, 2024 36 commits
-
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the class3270 structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
"Ricardo B. Marliere" <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240305-class_cleanup-s390-v1-6-c4ff1ec49ffd@marliere.netSigned-off-by:
-
Ricardo B. Marliere authored
Instead of checking if rc is 0, check whether it is non-zero and return early if so. The call to class_create() can fail, so add a check to it and move it out of the mutex region. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the tape_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the vmlogrdr_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the vmur_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the zcrypt_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20240305-class_cleanup-s390-v1-1-c4ff1ec49ffd@marliere.netSigned-off-by:
-
Heiko Carstens authored
Provide a very simple ARCH_HAS_DEBUG_VIRTUAL implementation. For now errors are only reported for the following cases: - Trying to translate a vmalloc or module address to a physical address - Translating a supposed to be ZONE_DMA virtual address into a physical address, and the resulting physical address is larger than two GiB Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Use virt_to_dma64() and friends to properly convert virtual to physical and hysical to virtual addresses so that "make C=1" does not generate any warnings anymore. Reviewed-by:
Eric Farman <farman@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma64() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma64() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Reviewed-by:
Steffen Maier <maier@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Fix virtual vs physical address confusion and use new dma types and helper functions to allow for type checking. This does not fix a bug since virtual and physical address spaces are currently the same. Tested-by:
Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by:
-
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma64() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Signed-off-by: -
Heiko Carstens authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Signed-off-by: -
Heiko Carstens authored
Only the last 12 bits of virtual / physical addresses are used when masking with IDA_BLOCK_SIZE - 1. Given that the bits are the same regardless of virtual or physical address, remove the virtual to physical address conversion. Signed-off-by: -
Heiko Carstens authored
Adjust coding style, partially refactor code, and use kcalloc() instead of kmalloc() to allocate an idaw array. Signed-off-by: -
Heiko Carstens authored
Use virt_to_dma32() and friends to properly convert virtual to physical and physical to virtual addresses so that "make C=1" does not generate any warnings anymore. Reviewed-by:
Stefan Haberland <sth@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Only the last 12 bits of virtual / physical addresses are used when masking with IDA_BLOCK_SIZE - 1. Given that the bits are the same regardless of virtual or physical address, remove the virtual to physical address conversion. Reviewed-by:
-
Halil Pasic authored
Instead of converting virtual to physical addresses with the virt_to_dma*() functions, use dma addresses as provided by DMA API and only add offsets to these addresses. This makes sure that address conversion is only done by the DMA API. Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reviewed-by:
-
Halil Pasic authored
Change and use ccw_device_dma_zalloc() so it returns a virtual address like before, which can be used to access data. However also pass a new dma32_t pointer type handle, which correlates to the returned virtual address. This pointer is used to directly pass/set the DMA handle as returned by the DMA API. Signed-off-by:
-
Halil Pasic authored
Fix virtual vs physical address confusion and use new dma types and helper functions to allow for type checking. This does not fix a bug since virtual and physical address spaces are currently the same. Signed-off-by:
-
Heiko Carstens authored
Change types of I/O structure members which contain physical addresses to dma32_t and dma64_t bitwise types. This allows to make use of sparse (aka "make C=1") to find incorrect usage of physical addresses. Signed-off-by: -
Halil Pasic authored
Introduce dma32_t and dma64_t bitwise types, which are supposed to be used for 31 and 64 bit DMA capable addresses. This allows to use sparse (make C=1) for type checking, so that incorrect usages can be easily found. Also add a couple of helper functions which - convert virtual to DMA addresses and vice versa - allow for simple logical and arithmetic operations on DMA addresses - convert DMA addresses to plain u32 and u64 values All helper functions exist to avoid excessive casting in C code. Signed-off-by:
-
Heiko Carstens authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Reviewed-by:
-
Heiko Carstens authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Signed-off-by: -
Heiko Carstens authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Reviewed-by:
-
Gerald Schaefer authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. dax_direct_access() should receive a virtual kernel address in kaddr. Reviewed-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by:
-
Alexander Gordeev authored
Fix IUCV_IPBUFLST-type buffers virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
Harald Freudenberger authored
Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use. This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: [<00000000c9b919dc>] ext4_htree_fill_tree+0x134/0x400 kernel: [<00000000c9b4b3d0>] ext4_dx_readdir+0x160/0x2f0 kernel: [<00000000c9b4bedc>] ext4_readdir+0x5f4/0x760 kernel: [<00000000c9a7efc4>] iterate_dir+0xb4/0x280 kernel: [<00000000c9a7f1ea>] __do_sys_getdents64+0x5a/0x120 kernel: [<00000000ca5d6946>] __do_syscall+0x256/0x310 kernel: [<00000000ca5eea10>] system_call+0x70/0x98 kernel: INFO: lockdep is turned off. kernel: FIX kmalloc-96: Restoring Poison 0x00000000885a7512-0x00000000885a7513=0x6b kernel: FIX kmalloc-96: Marking all objects used The fix is simple: Before use of the queue not only the queue object but also the card object needs to increase it's reference count with a call to zcrypt_card_get(). Similar after use of the queue not only the queue but also the card object's reference count is decreased with zcrypt_card_put(). Signed-off-by:Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Mete Durlu authored
Current average steal timer calculation produces volatile and inflated values. The only user of this value is KVM so far and it uses that to decide whether or not to yield the vCPU which is seeing steal time. KVM compares average steal timer to a threshold and if the threshold is past then it does not allow CPU polling and yields it to host, else it keeps the CPU by polling. Since KVM's steal time threshold is very low by default (%10) it most likely is not effected much by the bloated average steal timer values because the operating region is pretty small. However there might be new users in the future who might rely on this number. Fix average steal timer calculation by changing the formula from: avg_steal_timer = avg_steal_timer / 2 + steal_timer; to the following: avg_steal_timer = (avg_steal_timer + steal_timer) / 2; This ensures that avg_steal_timer is actually a naive average of steal timer values. It now closely follows steal timer values but of course in a smoother manner. Fixes: 152e9b86 ("s390/vtime: steal time exponential moving average") Signed-off-by:
Mete Durlu <meted@linux.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by:
-
