linux-kernel - Re: [syzbot] [mm?] possible deadlock in __mmap_lock_do_trace_start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sun, 16 Jun 2024 12:05:40 -0400
From: Waiman Long <longman@...hat.com>
To: syzbot <syzbot+6ff90931779bcdfc840c@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, cgroups@...r.kernel.org, hannes@...xchg.org,
 hawk@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-trace-kernel@...r.kernel.org, lizefan.x@...edance.com,
 mathieu.desnoyers@...icios.com, mhiramat@...nel.org, netdev@...r.kernel.org,
 rostedt@...dmis.org, syzkaller-bugs@...glegroups.com, tj@...nel.org
Subject: Re: [syzbot] [mm?] possible deadlock in
 __mmap_lock_do_trace_start_locking

On 6/16/24 10:05, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 21c38a3bd4ee3fb7337d013a638302fb5e5f9dc2
> Author: Jesper Dangaard Brouer <hawk@...nel.org>
> Date:   Wed May 1 14:04:11 2024 +0000
>
>      cgroup/rstat: add cgroup_rstat_cpu_lock helpers and tracepoints
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16695261980000
> start commit:   36534d3c5453 tcp: use signed arithmetic in tcp_rtx_probe0_..
> git tree:       bpf
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=15695261980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=11695261980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=333ebe38d43c42e2
> dashboard link: https://syzkaller.appspot.com/bug?extid=6ff90931779bcdfc840c
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1585acfa980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17bdb7ee980000
>
> Reported-by: syzbot+6ff90931779bcdfc840c@...kaller.appspotmail.com
> Fixes: 21c38a3bd4ee ("cgroup/rstat: add cgroup_rstat_cpu_lock helpers and tracepoints")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
+static __always_inline
+unsigned long _cgroup_rstat_cpu_lock(raw_spinlock_t *cpu_lock, int cpu,
+                                    struct cgroup *cgrp, const bool 
fast_path)
+{
+       unsigned long flags;
+       bool contended;
+
+       /*
+        * The _irqsave() is needed because cgroup_rstat_lock is
+        * spinlock_t which is a sleeping lock on PREEMPT_RT. Acquiring
+        * this lock with the _irq() suffix only disables interrupts on
+        * a non-PREEMPT_RT kernel. The raw_spinlock_t below disables
+        * interrupts on both configurations. The _irqsave() ensures
+        * that interrupts are always disabled and later restored.
+        */
+       contended = !raw_spin_trylock_irqsave(cpu_lock, flags);
+       if (contended) {
+               if (fast_path)
+ trace_cgroup_rstat_cpu_lock_contended_fastpath(cgrp, cp>
+               else
+                       trace_cgroup_rstat_cpu_lock_contended(cgrp, cpu, 
conten>
+
+               raw_spin_lock_irqsave(cpu_lock, flags);
+       }

I believe the problem may be caused by the fact that 
trace_cgroup_rstat_cpu_lock_contended*() can be called with IRQ enabled. 
I had suggested before IRQ should be disabled first before doing any 
trace operation. See

https://lore.kernel.org/linux-mm/203fdb35-f4cf-4754-9709-3c024eecade9@redhat.com/

Doing so may be able to resolve this possible deadlock.

Cheers,
Longman