[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875yt64isx.ffs@tglx>
Date: Fri, 05 Nov 2021 18:24:30 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Dmitrii Banshchikov <me@...que.spb.ru>,
Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: syzbot <syzbot+43fd005b5a1b4d10781e@...kaller.appspotmail.com>,
John Stultz <john.stultz@...aro.org>,
LKML <linux-kernel@...r.kernel.org>, sboyd@...nel.org,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>,
Steven Rostedt <rosted@...dmis.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
bpf <bpf@...r.kernel.org>
Subject: Re: [syzbot] possible deadlock in ktime_get_coarse_ts64
On Fri, Nov 05 2021 at 21:03, Dmitrii Banshchikov wrote:
> On Fri, Nov 05, 2021 at 08:53:06AM -0700, Alexei Starovoitov wrote:
>> > 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.
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_*
Thanks,
tglx
Powered by blists - more mailing lists