mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitrii Banshchikov <me@ubique.spb.ru>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	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: Fri, 5 Nov 2021 21:03:28 +0400	[thread overview]
Message-ID: <20211105170328.fjnzr6bnbca7mdfq@amnesia> (raw)
In-Reply-To: <CAADnVQLcuMAr3XMTD1Lys5S5ybME4h=NL3=adEwib2UT6b-E9w@mail.gmail.com>

On Fri, Nov 05, 2021 at 08:53:06AM -0700, Alexei Starovoitov wrote:
> On Fri, Nov 5, 2021 at 6:10 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > >
> > > -> #0 (tk_core.seq.seqcount){----}-{0:0}:
> > >        check_prev_add kernel/locking/lockdep.c:3051 [inline]
> > >        check_prevs_add kernel/locking/lockdep.c:3174 [inline]
> > >        validate_chain+0x1dfb/0x8240 kernel/locking/lockdep.c:3789
> > >        __lock_acquire+0x1382/0x2b00 kernel/locking/lockdep.c:5015
> > >        lock_acquire+0x19f/0x4d0 kernel/locking/lockdep.c:5625
> > >        seqcount_lockdep_reader_access+0xfe/0x230 include/linux/seqlock.h:103
> > >        ktime_get_coarse_ts64+0x25/0x110 kernel/time/timekeeping.c:2255
> > >        ktime_get_coarse include/linux/timekeeping.h:120 [inline]
> > >        ktime_get_coarse_ns include/linux/timekeeping.h:126 [inline]
> >
> > --> this call is invalid
> >
> > >        ____bpf_ktime_get_coarse_ns kernel/bpf/helpers.c:173 [inline]
> > >        bpf_ktime_get_coarse_ns+0x7e/0x130 kernel/bpf/helpers.c:171
> > >        bpf_prog_a99735ebafdda2f1+0x10/0xb50
> > >        bpf_dispatcher_nop_func include/linux/bpf.h:721 [inline]
> > >        __bpf_prog_run include/linux/filter.h:626 [inline]
> > >        bpf_prog_run include/linux/filter.h:633 [inline]
> > >        BPF_PROG_RUN_ARRAY include/linux/bpf.h:1294 [inline]
> > >        trace_call_bpf+0x2cf/0x5d0 kernel/trace/bpf_trace.c:127
> > >        perf_trace_run_bpf_submit+0x7b/0x1d0 kernel/events/core.c:9708
> > >        perf_trace_lock+0x37c/0x440 include/trace/events/lock.h:39
> > >        trace_lock_release+0x128/0x150 include/trace/events/lock.h:58
> >
> > Timestamps from within a tracepoint can only be taken with:
> >
> >          1) jiffies
> >          2) sched_clock()
> >          3) ktime_get_*_fast_ns()
> >
> > Those are NMI safe and can be invoked from anywhere.
> >
> > All other time getters which have to use the timekeeping seqcount
> > protection are prone to live locks and _cannot_ be used from
> > tracepoints ever.
> 
> Obviously.
> That helper was added for networking use cases and accidentally
> enabled for tracing.

Sorry for that.
I'm preparing a patch that will forbid using bpf_ktime_get_coarse_ns()
helper in BPF_LINK_TYPE_RAW_TRACEPOINT.



-- 

Dmitrii Banshchikov

  reply	other threads:[~2021-11-05 17:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 16:18 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 [this message]
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

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=20211105170328.fjnzr6bnbca7mdfq@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®