[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <139fd239-49e3-4591-965e-82c9f7d627e9@redhat.com>
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
Powered by blists - more mailing lists