Re: [PATCH v19 31/40] dept: assign unique dept_key to each distinct wait_for_completion() caller
Byungchul Park <[email protected]> Fri, 10 Jul 2026 14:53:54 +0900
| Newsgroups | org.kernel.vger.linux-ide,dev.linux.lists.linux-rt-devel,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-arch,org.kernel.vger.linux-block,org.kernel.vger.linux-doc,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-i2c,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.linux-modules,org.kernel.vger.linux-nfs,org.kernel.vger.netdev,org.kernel.vger.rcu,org.kernel.vger.rust-for-linux,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Jul 07, 2026 at 03:18:29PM +0100, Gary Guo wrote: > 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. Thank you for the input. > 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] Yes, dept_key is similar to lock_class_key. IIUC, the way you tried for lock_class_key can be applied to DEPT too. I will do: 1) add 'key' parameter to sdt_might_sleep_start_timeout() 2) introduce init_completion_dkey() to allow custom keys 3) remove init_completion_dmap() and adjust the existing users Just in case, it's worth noting that the custom keys must be well-managed using e.g. dept_key_destroy() when the key gets freed. Byungchul > 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(-)