Re: [PATCH v19 31/40] dept: assign unique dept_key to each distinct wait_for_completion() caller

"Gary Guo" <[email protected]>
Newsgroups gmane.linux.kernel.modules,gmane.linux.kernel,gmane.linux.ide,gmane.comp.file-systems.ext4,gmane.linux.kernel.mm,gmane.linux.block,gmane.linux.file-systems,gmane.comp.video.dri.devel,gmane.linux.network,gmane.linux.documentation,gmane.linux.ports.arm.kernel,gmane.linux.drivers.video-input-infrastructure,gmane.linux.drivers.i2c,gmane.linux.kernel.cross-arch,gmane.linux.nfs,gmane.linux.kernel.rust
Message-ID <[email protected]>
On Mon Jul 6, 2026 at 7:19 AM BST, Byungchul Park wrote:
> wait_for_completion() can be used at various points in the code and it's
> very hard to distinguish wait_for_completion()s between different usages.
> Using a single dept_key for all the wait_for_completion()s could trigger
> false positive reports.
>
> Assign unique dept_key to each distinct wait_for_completion() caller to
> avoid false positive reports.
>
> While at it, add a rust helper for wait_for_completion() to avoid build
> errors.

This will cause Rust code to share the same dept_key, so it will have all the
false positives that the change is trying to avoid.

In general it is easy to create Rust bindings for static inline C functions
because it'll be just some computation, while creating bindings for C
function-like macros that define additional statics can be challenging.

Is dept_key similar to lock_class_key, where only the address matters? If so,
the approach that I use in
https://lore.kernel.org/rust-for-linux/[email protected]
could be used for dept_key as well, then we can keep Rust `wait_for_completion`
still a function; otherwise we have to turn it into a macro too on the Rust side
to create such statics, which isn't ideal.

Best,
Gary

>
> Signed-off-by: Byungchul Park <[email protected]>
> ---
>  include/linux/completion.h | 100 +++++++++++++++++++++++++++++++------
>  kernel/sched/completion.c  |  60 +++++++++++-----------
>  rust/helpers/completion.c  |   5 ++
>  3 files changed, 120 insertions(+), 45 deletions(-)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.