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
| ||
|
Message-ID: <ZGp+fW855gmWuh9W@krava> Date: Sun, 21 May 2023 22:26:37 +0200 From: Jiri Olsa <olsajiri@...il.com> To: Ze Gao <zegao2021@...il.com> Cc: Yonghong Song <yhs@...a.com>, Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Hao Luo <haoluo@...gle.com>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, Masami Hiramatsu <mhiramat@...nel.org>, Song Liu <song@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Steven Rostedt <rostedt@...dmis.org>, Yonghong Song <yhs@...com>, bpf@...r.kernel.org, linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, kafai@...com, kpsingh@...omium.org, netdev@...r.kernel.org, paulmck@...nel.org, songliubraving@...com, Ze Gao <zegao@...cent.com> Subject: Re: On Sun, May 21, 2023 at 11:10:16PM +0800, Ze Gao wrote: > > kprobe_multi/fprobe share the same set of attachments with fentry. > > Currently, fentry does not filter with !rcu_is_watching, maybe > > because this is an extreme corner case. Not sure whether it is > > worthwhile or not. > > Agreed, it's rare, especially after Peter's patches which push narrow > down rcu eqs regions > in the idle path and reduce the chance of any traceable functions > happening in between. > > However, from RCU's perspective, we ought to check if rcu_is_watching > theoretically > when there's a chance our code will run in the idle path and also we > need rcu to be alive, > And also we cannot simply make assumptions for any future changes in > the idle path. > You know, just like what was hit in the thread. > > > Maybe if you can give a concrete example (e.g., attachment point) > > with current code base to show what the issue you encountered and > > it will make it easier to judge whether adding !rcu_is_watching() > > is necessary or not. > > I can reproduce likely warnings on v6.1.18 where arch_cpu_idle is > traceable but not on the latest version > so far. But as I state above, in theory we need it. So here is a > gentle ping :) . hum, this change [1] added rcu_is_watching check to ftrace_test_recursion_trylock, which we use in fprobe_handler and is coming to fprobe_exit_handler in [2] I might be missing something, but it seems like we don't need another rcu_is_watching call on kprobe_multi level jirka [1] d099dbfd3306 cpuidle: tracing: Warn about !rcu_is_watching() [2] https://lore.kernel.org/bpf/20230517034510.15639-4-zegao@tencent.com/
Powered by blists - more mailing lists