Re: [PATCH v2 tip/perf/core 3/5] fs: add back RCU-delayed freeing of FMODE_BACKING file
From: Andrii Nakryiko <hidden>
Date: 2024-10-04 19:58:13
Also in:
bpf, linux-mm, lkml
On Fri, Oct 4, 2024 at 1:01 AM Christian Brauner [off-list ref] wrote:
On Thu, Oct 03, 2024 at 11:13:54AM GMT, Christian Brauner wrote:quoted
On Tue, Oct 01, 2024 at 03:52:05PM GMT, Andrii Nakryiko wrote:quoted
6cf41fcfe099 ("backing file: free directly") switched FMODE_BACKING files to direct freeing as back then there were no use cases requiring RCU protected access to such files. Now, with speculative lockless VMA-to-uprobe lookup logic, we do need to have a guarantee that struct file memory is not going to be freed from under us during speculative check. So add back RCU-delayed freeing logic. We use headless kfree_rcu_mightsleep() variant, as file_free() is only called for FMODE_BACKING files in might_sleep() context. Suggested-by: Suren Baghdasaryan <surenb@google.com> Cc: Christian Brauner <brauner@kernel.org> Cc: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> ---Reviewed-by: Christian Brauner <brauner@kernel.org>Fwiw, I have another patch series for files that I'm testing that will require me to switch FMODE_BACKING to a SLAB_TYPSAFE_BY_RCU cache. That shouldn't matter for your use-case though.
Correct, we assume SLAB_TYPESAFE_BY_RCU semantics for the common case anyways. But hopefully my change won't cause major merge conflicts with your patch set.