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: <CAD8CoPAXse1GKAb15O5tZJwBqMt1N_btH+qRe7c_a-ryUMjx7A@mail.gmail.com> Date: Sun, 21 May 2023 23:10:16 +0800 From: Ze Gao <zegao2021@...il.com> To: Yonghong Song <yhs@...a.com> Cc: jolsa@...nel.org, 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: > 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 :) .
Powered by blists - more mailing lists