kernel/linux.git/drivers/s390/crypto/ap_queue.c, branch v7.2-rc6

s390/ap: Fix locking issue in SE bind and associate sysfs functions

2026-06-09T17:33:00+00:00

Revisit and reorganize the locking and lock coverage of the ap->lock spinlock as used in the two sysfs functions se_bind_store() and se_associate_store(). A kernel run reported a possible deadlock situation, caused by holding the spinlock (ap->lock) while triggering a uevent. The fix rearranges the code protected by the spinlock by excluding the uevent invocation, which does not require protection. Additionally, the start of the protected region is moved earlier to cover more lines, ensuring a consistent view of the AP queue state between reading and updating its struct fields. ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 7.1.0-20260601.rc6.git12.516b5dbd4d4a.300.fc44.s390x+debug #1 Not tainted ----------------------------------------------------- setupseguest.sh/11034 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire: 000001c991f498e8 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x5a/0x6d0 and this task is already holding: 000000c4a1a12378 (&aq->lock){+.-.}-{2:2}, at: se_bind_store+0x96/0x3a0 which would create a new lock dependency: (&aq->lock){+.-.}-{2:2} -> (fs_reclaim){+.+.}-{0:0} but this new dependency connects a SOFTIRQ-irq-safe lock: (&aq->lock){+.-.}-{2:2} ... which became SOFTIRQ-irq-safe at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_tasklet_fn+0x72/0xd0 tasklet_action_common+0x174/0x1b0 handle_softirqs+0x180/0x5c0 irq_exit_rcu+0x196/0x200 do_ext_irq+0x12a/0x4d0 ext_int_handler+0xc6/0xf0 folio_zero_user+0x1c6/0x240 folio_zero_user+0x182/0x240 vma_alloc_anon_folio_pmd+0xa0/0x1d0 __do_huge_pmd_anonymous_page+0x3a/0x200 __handle_mm_fault+0x56c/0x590 handle_mm_fault+0xa2/0x370 do_exception+0x292/0x590 __do_pgm_check+0x136/0x3e0 pgm_check_handler+0x114/0x160 to a SOFTIRQ-irq-unsafe lock: (fs_reclaim){+.+.}-{0:0} ... which became SOFTIRQ-irq-unsafe at: ... __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); local_irq_disable(); lock(&aq->lock); lock(fs_reclaim); lock(&aq->lock); *** DEADLOCK *** 4 locks held by setupseguest.sh/11034: #0: 000000c485d01440 (sb_writers#4){.+.+}-{0:0}, at: vfs_write+0x2fc/0x380 #1: 000000c4d2283288 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x12a0x270 #2: 000000c4a1830e48 (kn->active#172){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x1e/0x270 #3: 000000c4a1a12378 (&aq->lock){+.-.}-{2:2}, at: se_bind_store+0x96/0x3a0 the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&aq->lock){+.-.}-{2:2} { HARDIRQ-ON-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_queue_init_state+0x2e/0x50 ap_scan_domains+0x5d6/0x620 ap_scan_adapter+0x4c0/0x810 ap_scan_bus+0x70/0x350 ap_scan_bus_wq_callback+0x56/0x80 process_one_work+0x2ba/0x820 worker_thread+0x21a/0x400 kthread+0x164/0x190 __ret_from_fork+0x4c/0x340 ret_from_fork+0xa/0x30 IN-SOFTIRQ-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_tasklet_fn+0x72/0xd0 tasklet_action_common+0x174/0x1b0 handle_softirqs+0x180/0x5c0 irq_exit_rcu+0x196/0x200 do_ext_irq+0x12a/0x4d0 ext_int_handler+0xc6/0xf0 folio_zero_user+0x1c6/0x240 folio_zero_user+0x182/0x240 vma_alloc_anon_folio_pmd+0xa0/0x1d0 __do_huge_pmd_anonymous_page+0x3a/0x200 __handle_mm_fault+0x56c/0x590 handle_mm_fault+0xa2/0x370 do_exception+0x292/0x590 __do_pgm_check+0x136/0x3e0 pgm_check_handler+0x114/0x160 INITIAL USE at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_queue_init_state+0x2e/0x50 ap_scan_domains+0x5d6/0x620 ap_scan_adapter+0x4c0/0x810 ap_scan_bus+0x70/0x350 ap_scan_bus_wq_callback+0x56/0x80 process_one_work+0x2ba/0x820 worker_thread+0x21a/0x400 kthread+0x164/0x190 __ret_from_fork+0x4c/0x340 ret_from_fork+0xa/0x30 } ... key at: [<000001c9936e8aa0>] __key.7+0x0/0x10 the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock: -> (fs_reclaim){+.+.}-{0:0} { HARDIRQ-ON-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 SOFTIRQ-ON-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 INITIAL USE at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 } ... key at: [<000001c991f498e8>] __fs_reclaim_map+0x0/0x30 ... acquired at: check_prev_add+0x178/0xf40 __lock_acquire+0x12aa/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 __kmalloc_cache_noprof+0x5a/0x6d0 kobject_uevent_env+0xd4/0x420 ap_send_se_bind_uevent+0x48/0x70 se_bind_store+0x146/0x3a0 kernfs_fop_write_iter+0x18c/0x270 vfs_write+0x23c/0x380 ksys_write+0x88/0x120 __do_syscall+0x170/0x750 system_call+0x72/0x90 stack backtrace: CPU: 6 UID: 0 PID: 11034 Comm: setupseguest.sh Not tainted 7.1.0-20260601.rc6.git2.516b5dbd4d4a.300.fc44.s390x+debug #1 PREEMPT Hardware name: IBM 9175 ME1 701 (KVM/Linux) Call Trace: [<000001c98ffa0a7e>] dump_stack_lvl+0xae/0x108 [<000001c9900a6d7a>] print_bad_irq_dependency+0x47a/0x480 [<000001c9900a7184>] check_irq_usage+0x404/0x4c0 [<000001c9900a73b8>] check_prev_add+0x178/0xf40 [<000001c9900aaf1a>] __lock_acquire+0x12aa/0x15a0 [<000001c9900ab35c>] lock_acquire+0x14c/0x400 [<000001c9903be454>] __fs_reclaim_acquire+0x44/0x50 [<000001c9903be51e>] fs_reclaim_acquire+0xbe/0x100 [<000001c9903cf4ca>] __kmalloc_cache_noprof+0x5a/0x6d0 [<000001c9910ca9d4>] kobject_uevent_env+0xd4/0x420 [<000001c990d84098>] ap_send_se_bind_uevent+0x48/0x70 [<000001c990d87416>] se_bind_store+0x146/0x3a0 [<000001c99057da7c>] kernfs_fop_write_iter+0x18c/0x270 [<000001c99047712c>] vfs_write+0x23c/0x380 [<000001c990477438>] ksys_write+0x88/0x120 [<000001c9910f64e0>] __do_syscall+0x170/0x750 [<000001c99110a412>] system_call+0x72/0x90 INFO: lockdep is turned off. Fixes: 4179c3984227 ("s390/ap: Implement SE bind and associate uevents") Reported-by: Ingo Franzki Suggested-by: Finn Callies Reviewed-by: Finn Callies Signed-off-by: Harald Freudenberger Signed-off-by: Alexander Gordeev

s390/ap: Implement SE bind and associate uevents

2026-05-11T14:42:31+00:00

Notify userspace about two important events on AP queues when run within Secure Execution (SE) environment: - Send AP CHANGE uevent with "SE_BIND=1" on successful bind operation on this AP queue device. - Send AP CHANGE uevent with "SE_ASSOC=" on successful association operation with the secret of the reported index on this AP queue device. Note there is no SE unbind/unassociate event. Unbind/unassociate can have different triggers and technically there is no signaling done which the AP code could catch. A user space application can, if this information is crucial, query the sysfs attribute se_bind on the AP queue which runs a synchronous TAPQ. If the attribute returns with "unbound" a reset took place and SE bind and associate states are unbound and unassociated. Suggested-by: Marc Hartmayer mhartmay@linux.ibm.com Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev

s390/ap: use generic driver_override infrastructure

2026-04-03T22:49:22+00:00

When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released. This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() that may free the old string, resulting in a potential UAF. Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock. Note that unlike most other buses, the AP bus does not check driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead. Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store(). Fixes: d38a87d7c064 ("s390/ap: Support driver_override for AP queue devices") Tested-by: Holger Dengler Reviewed-by: Holger Dengler Reviewed-by: Harald Freudenberger Link: https://patch.msgid.link/20260324005919.2408620-11-dakr@kernel.org Signed-off-by: Danilo Krummrich

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

s390/ap: Fix wrong APQN fill calculation

2026-01-20T13:33:42+00:00

The upper limit of the firmware queue fill state for each APQN is reported by the hwinfo.qd field. This field shows the numbers 0-7 for 1-8 queue spaces available. But the exploiting code assumed the real boundary is stored there and thus stoppes queuing in messages one tick too early. Correct the limit calculation and thus offer a boost of 12.5% performance for high traffic on one APQN. Fixes: d4c53ae8e4948 ("s390/ap: store TAPQ hwinfo in struct ap_card") Cc: stable@vger.kernel.org Reported-by: Ingo Franzki Reviewed-by: Ingo Franzki Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens

s390: Remove KMSG_COMPONENT macro

2025-11-24T10:45:21+00:00

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

s390/ap: Restrict driver_override versus apmask and aqmask use

2025-11-24T10:43:06+00:00

Introduce a restriction for the driver_override feature versus apmask and aqmask: - driver_override is only allowed when the apmask and aqmask values both are default (=0xffff..ffff). - apmask and aqmask modifications are only allowed when there is no driver_override on any AP device active. So in the end the user is restricted to choose to either use apmask/apmask to divide the AP devices into host owned and vfio owned or use the driver_override feature but not mix these two approaches. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

s390/ap: Support driver_override for AP queue devices

2025-11-24T10:43:05+00:00

Add a new sysfs attribute driver_override the AP queue's directory. Writing in a string overrides the default driver determination and the drivers are matched against this string instead. This overrules the driver binding determined by the apmask/aqmask bitmask fields. According to the common understanding of how the driver_override behavior shall work, there is no further checking done. Neither about the string which is given as override driver nor if this device is currently in use by an mdev device. Another patch may limit this behavior to refuse a mixed usage of the driver_override and apmask/aqmask feature. As there exists some tooling for this kind of driver_override (see package driverctl) the AP bus behavior for re-binding should be compatible to this. The steps for a driver_override are: 1) unbind the current driver from the device. For example echo "17.0005" > /sys/devices/ap/card17/17.0005/driver/unbind 2) set the new driver for this device in the sysfs driver_override attribute. For example echo "vfio_ap" > /sys//devices/ap/card17/17.0005/driver_override 3) trigger a bus reprobe of this device. For example echo "17.0005" > /sys/bus/ap/drivers_probe With the driverctl package this is more comfortable and the settings get persisted: driverctl -b ap set-override 17.0005 vfio_ap and unset with driverctl -b ap unset-override 17.0005 Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

s390/ap: Introduce new AP nqap and dqap trace events

2025-10-21T09:09:21+00:00

Introduce two new AP bus related tracepoint events: - There is a tracepoint s390_ap_nqap event immediately after a request has been pushed into the AP firmware queue with the NQAP AP command. - The other tracepoint s390_ap_dqap event fires immediately after a reply has been pulled out of the AP firmware queue via DQAP AP command. Both events are triggered unconditional and may need filtering. Filtering can be done based on the status value which is part of the nqap and dqap trace. So for example a echo "!(status & 0x00ff0000)" >.../s390_ap_dqap/filter filters out all trace events which have a response_code != 0 leaving just the successful nqap and dqap invocations. The idea of these two trace events focuses on performance to measure the runtime of a crypto request/reply as close as possible at the firmware level. In combination with the two zcrypt tracepoints (see the zcrypt.h trace event definition file) this gives measurement data about the runtime of a request/reply within the zcrpyt and AP bus layer. However, with having the status of these AP commands in hand also other usage may be possible. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens