All of
 help / color / mirror / Atom feed
From: Thomas Gleixner <>
To: Dmitrii Banshchikov <>
Cc: Alexei Starovoitov <>,
	syzbot <>,
	John Stultz <>,
	LKML <>,,
	syzkaller-bugs <>,
	Peter Zijlstra <>,
	Mark Rutland <>,
	Steven Rostedt <>,
	Alexei Starovoitov <>,
	Daniel Borkmann <>, bpf <>
Subject: Re: [syzbot] possible deadlock in ktime_get_coarse_ts64
Date: Sun, 07 Nov 2021 11:32:07 +0100	[thread overview]
Message-ID: <87zgqg2r4o.ffs@tglx> (raw)
In-Reply-To: <20211106200733.meank7oonwvsdjy4@amnesia>


On Sun, Nov 07 2021 at 00:07, Dmitrii Banshchikov wrote:
> On Fri, Nov 05, 2021 at 06:24:30PM +0100, Thomas Gleixner wrote:
>> It cannot be used in TRACING and PERF_EVENT either. But those contexts
>> have to exclude other functions as well:
>>      bpf_ktime_get_ns
>>      bpf_ktime_get_boot_ns
>> along with
>>     bpf_spin_lock/unlock
>>     bpf_timer_*
> 1) bpf_ktime_get_ns and bpf_ktime_get_boot_ns use
> ktime_get_{mono,boot}_fast_ns.

Ok. That's fine then. I was just going from the bpf function names and
missed the implementation detail.

> 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

> 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.

            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.



  reply	other threads:[~2021-11-07 10:32 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 [this message]
2021-11-07 13:51             ` Dmitrii Banshchikov

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgqg2r4o.ffs@tglx \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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.