lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241124223045.4e47e8b7@rorschach.local.home>
Date: Sun, 24 Nov 2024 22:30:45 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ruan Bonan
 <bonan.ruan@...us.edu>, "mingo@...hat.com" <mingo@...hat.com>,
 "will@...nel.org" <will@...nel.org>, "longman@...hat.com"
 <longman@...hat.com>, "boqun.feng@...il.com" <boqun.feng@...il.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "kpsingh@...nel.org" <kpsingh@...nel.org>, "mattbobrowski@...gle.com"
 <mattbobrowski@...gle.com>, "ast@...nel.org" <ast@...nel.org>,
 "daniel@...earbox.net" <daniel@...earbox.net>, "andrii@...nel.org"
 <andrii@...nel.org>, "martin.lau@...ux.dev" <martin.lau@...ux.dev>,
 "eddyz87@...il.com" <eddyz87@...il.com>, "song@...nel.org"
 <song@...nel.org>, "yonghong.song@...ux.dev" <yonghong.song@...ux.dev>,
 "john.fastabend@...il.com" <john.fastabend@...il.com>, "sdf@...ichev.me"
 <sdf@...ichev.me>, "haoluo@...gle.com" <haoluo@...gle.com>,
 "jolsa@...nel.org" <jolsa@...nel.org>, "mhiramat@...nel.org"
 <mhiramat@...nel.org>, "mathieu.desnoyers@...icios.com"
 <mathieu.desnoyers@...icios.com>, "bpf@...r.kernel.org"
 <bpf@...r.kernel.org>, "linux-trace-kernel@...r.kernel.org"
 <linux-trace-kernel@...r.kernel.org>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>, Fu Yeqi <e1374359@...us.edu>
Subject: Re: [BUG] possible deadlock in __schedule (with reproducer
 available)

On Sun, 24 Nov 2024 18:02:35 -0800
Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:

> > > -EWONTFIX. Don't do stupid.  
> >
> > Ack. BPF should not be causing deadlocks by doing code called from
> > tracepoints.  
> 
> I sense so much BPF love here that it diminishes the ability to read
> stack traces :)

You know I love BPF ;-)  I do recommend it when I feel it's the right
tool for the job.

> Above is one of many printk related splats that syzbot keeps finding.
> This is not a new issue and it has nothing to do with bpf.

I had to fight printk related spats too. But when that happens, its not
considered a bug to the code that is being attached to. Note, my
response is more about the subject title, which sounds like it's
blaming the schedule code. Which is not the issue.

> 
> > Tracepoints have a special context similar to NMIs. If you add
> > a hook into an NMI handler that causes a deadlock, it's a bug in the hook,
> > not the NMI code. If you add code that causes a deadlock when attaching to a
> > tracepoint, it's a bug in the hook, not the tracepoint.  
> 
> trace events call strncpy_from_user_nofault() just as well.
> kernel/trace/trace_events_filter.c:830

Well, in some cases you could do that from NMI as well. The point is,
tracepoints are a different context, and things need to be careful when
using it. If any deadlock occurs by attaching to a tracepoint (and this
isn't just BPF, I have code too that needs to be very careful about
this as well), then the bug is with the attached callback.

I agree with Peter. This isn't his problem. Hence my Ack.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ