Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] `ldt_set_class` silently drops the lock name parameter, causing newly assigned lock classes to be registered in DEPT with the old lock name. --
commit ca6be2708025c25889ef609a2203d1465096983d Author: Byungchul Park <[email protected]> dept: add lock dependency tracker APIs Wrap the base APIs for easier annotation on typical lock. > diff --git a/include/linux/dept_ldt.h b/include/linux/dept_ldt.h > new file mode 100644 > index 0000000000000..8047d0a531f10 > --- /dev/null > +++ b/include/linux/dept_ldt.h [ ... ] > +#define ldt_downgrade(m, i) \ > + do { \ > + if (dept_ecxt_holding(m, LDT_EVT_W)) \ > + dept_map_ecxt_modify(m, LDT_EVT_W, NULL, LDT_EVT_R, i, > "downgrade", "read_unlock", -1);\ > + } while (0) > + > +#define ldt_set_class(m, n, k, sl, i) dept_map_ecxt_modify(m, > LDT_EVT_ALL, k, 0UL, i, "lock_set_class", "(any)unlock", sl) [Severity: Medium] Does this code inadvertently drop the lock name parameter `n`? When a caller invokes `lock_set_class` on a held lock, it passes the new name `n`. Because `n` is completely omitted from the replacement list here, `dept_map_ecxt_modify` won't receive the new name. This could cause newly assigned lock classes to be registered in DEPT with the old lock name, which might lead to incorrect lock names in dependency deadlock reports. Inside `dept_map_ecxt_modify()`, `dept_map_reinit()` is called with `NULL` for the name, leaving `m->name` unchanged. `check_new_class()` is then called, which registers the new class key using the old `m->name`. Lockdep subsequently updates `m->name` via `ldt_init`, but it is too late as the DEPT class was already created with the old name. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
