Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] Unsafe macro conversion of functions causes double-evaluation of arguments, leading to logic bugs and memory corruption. --
commit e5795ffb367b1b68ef8574b0a67f0bf3654baf77 Author: Byungchul Park <[email protected]> dept: add single event dependency tracker APIs Wrapped the base APIs for easier annotation on wait and event. Start with supporting waiters on each single event. More general support for multiple events is a future work. Do more when the need arises. > diff --git a/include/linux/dept_sdt.h b/include/linux/dept_sdt.h > new file mode 100644 > index 0000000000000..0535f763b21be > --- /dev/null > +++ b/include/linux/dept_sdt.h [ ... ] > +#define sdt_map_init_key(m, k) dept_map_init(m, k, 0, #m) > + > +#define sdt_wait(m) \ > + do { \ > + dept_request_event(m); \ > + dept_wait(m, 1UL, _THIS_IP_, __func__, 0); \ > + } while (0) [Severity: Critical] Can this macro evaluate its argument multiple times, causing a regression if the argument contains side effects? Unlike sdt_might_sleep_start(m) later in this file which safely captures its argument in a local variable __m, sdt_wait(m) evaluates its argument twice. If an expression with a post-increment is passed to a macro like this, the side effect will execute multiple times. This is especially risky if existing synchronization primitives like wait_for_completion(x) are converted into similar macros to integrate with the tracker. For example, looking at drivers/vdpa/mlx5/core/resources.c: mlx5_vdpa_add_res() { ... while (completed < issued) wait_for_completion(&cmds[completed++].cmd_done); ... } If wait_for_completion() or a similar wrapper evaluates its argument twice, completed++ increments twice per loop iteration. This would skip completion entries and eventually access out-of-bounds memory past the end of the cmds array. Could the argument be evaluated once and captured in a local variable within these macros to avoid this? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
