[v6.1] INFO: rcu detected stall in call_usermodehelper_exec_async

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 88690811da69 Linux 6.1.92
git tree: linux-6.1.y
console output: https://syzkaller.appspot.com/x/log.txt?x=124ee6f6980000
kernel config: https://syzkaller.appspot.com/x/.config?x=f084fbeeff2de042
dashboard link: https://syzkaller.appspot.com/bug?extid=5333e941b2bdc3dd40a9
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: arm64

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/9040ec940045/disk-88690811.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/dc70128611fd/vmlinux-88690811.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f05abc0b618b/Image-88690811.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5333e9...@syzkaller.appspotmail.com

rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6500/1:b..l
(detected by 0, t=10502 jiffies, g=14053, q=285 ncpus=2)
task:kworker/u4:9 state:R running task stack:0 pid:6500 ppid:4722 flags:0x00000008
Call trace:
__switch_to+0x320/0x754 arch/arm64/kernel/process.c:553
context_switch kernel/sched/core.c:5245 [inline]
__schedule+0xee4/0x1c98 kernel/sched/core.c:6558
preempt_schedule_irq+0x8c/0x1b8 kernel/sched/core.c:6870
arm64_preempt_schedule_irq arch/arm64/kernel/entry-common.c:265 [inline]
__el1_irq arch/arm64/kernel/entry-common.c:474 [inline]
el1_interrupt+0x4c/0x68 arch/arm64/kernel/entry-common.c:486
el1h_64_irq_handler+0x18/0x24 arch/arm64/kernel/entry-common.c:491
el1h_64_irq+0x64/0x68 arch/arm64/kernel/entry.S:581
arch_local_irq_restore arch/arm64/include/asm/irqflags.h:122 [inline]
seqcount_lockdep_reader_access include/linux/seqlock.h:104 [inline]
read_seqbegin include/linux/seqlock.h:836 [inline]
read_seqbegin_or_lock+0x160/0x250 include/linux/seqlock.h:1140
prepend_path+0x1a8/0xb48 fs/d_path.c:165
d_absolute_path+0x13c/0x27c fs/d_path.c:233
d_namespace_path security/apparmor/path.c:125 [inline]
aa_path_name+0x128/0xa98 security/apparmor/path.c:201
profile_transition+0x198/0xe40 security/apparmor/domain.c:639
apparmor_bprm_creds_for_exec+0x814/0x37ec security/apparmor/domain.c:898
security_bprm_creds_for_exec+0x6c/0xa4 security/security.c:857
bprm_execve+0x524/0x162c fs/exec.c:1843
kernel_execve+0x718/0x7f0 fs/exec.c:2012
call_usermodehelper_exec_async+0x21c/0x3c0 kernel/umh.c:113
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:864
rcu: rcu_preempt kthread starved for 10500 jiffies! g14053 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:0 pid:16 ppid:2 flags:0x00000008
Call trace:
__switch_to+0x320/0x754 arch/arm64/kernel/process.c:553
context_switch kernel/sched/core.c:5245 [inline]
__schedule+0xee4/0x1c98 kernel/sched/core.c:6558
schedule+0xc4/0x170 kernel/sched/core.c:6634
schedule_timeout+0x1d8/0x344 kernel/time/timer.c:1965
rcu_gp_fqs_loop+0x2cc/0x1538 kernel/rcu/tree.c:1706
rcu_gp_kthread+0xc0/0x308 kernel/rcu/tree.c:1905
kthread+0x250/0x2d8 kernel/kthread.c:376
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:864
rcu: Stack dump where RCU GP kthread last ran:
Task dump for CPU 1:
task:syz-executor.4 state:R running task stack:0 pid:6498 ppid:4248 flags:0x00000000
Call trace:
__switch_to+0x320/0x754 arch/arm64/kernel/process.c:553
0xffff700003df6e38


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup