From: Dmitrii Banshchikov <me@ubique.spb.ru>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
syzbot <syzbot+43fd005b5a1b4d10781e@syzkaller.appspotmail.com>,
John Stultz <john.stultz@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
sboyd@kernel.org,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
Peter Zijlstra <peterz@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Steven Rostedt <rosted@goodmis.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>, bpf <bpf@vger.kernel.org>
Subject: Re: [syzbot] possible deadlock in ktime_get_coarse_ts64
Date: Sun, 7 Nov 2021 17:51:15 +0400 [thread overview]
Message-ID: <20211107135115.tqqx62sxsfeuzslb@amnesia> (raw)
In-Reply-To: <87zgqg2r4o.ffs@tglx>
On Sun, Nov 07, 2021 at 11:32:07AM +0100, Thomas Gleixner wrote:
> > 2) bpf_spin_lock/unlock have notrace attribute set.
>
> How is that supposed to help?
>
> You cannot take a spinlock from NMI context if that same lock can be
> taken by other contexts as well.
>
> Also notrace on the public function is not guaranteeing that the inlines
> (as defined) are not traceable and it does not exclude it from being
> kprobed.
>
> > 3) bpf_timer_* helpers fail early if they are in NMI.
> >
> > Why they have to be excluded?
>
> Because timers take locks and you can just end up in the very same
> situation that you create invers lock dependencies or deadlocks when you
> use that from a tracepoint.
>
> hrtimer_start()
> lock_base();
> trace_hrtimer...()
> perf_event()
> bpf_run()
> bpf_timer_start()
> hrtimer_start()
> lock_base() <- DEADLOCK
>
> Tracepoints and perf events are very limited in what they can actually
> do. Just because it's BPF these rules are not magically going away.
>
Thanks for the clarification.
--
Dmitrii Banshchikov
prev parent reply other threads:[~2021-11-07 13:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 16:18 [syzbot] possible deadlock in ktime_get_coarse_ts64 syzbot
2021-11-05 13:10 ` Thomas Gleixner
2021-11-05 13:21 ` Steven Rostedt
2021-11-05 15:53 ` Alexei Starovoitov
2021-11-05 17:03 ` Dmitrii Banshchikov
2021-11-05 17:24 ` Thomas Gleixner
2021-11-06 20:07 ` Dmitrii Banshchikov
2021-11-07 10:32 ` Thomas Gleixner
2021-11-07 13:51 ` Dmitrii Banshchikov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211107135115.tqqx62sxsfeuzslb@amnesia \
--to=me@ubique.spb.ru \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=rosted@goodmis.org \
--cc=sboyd@kernel.org \
--cc=syzbot+43fd005b5a1b4d10781e@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.