Messages in this thread |  | | From | Alexander Aring <> | | Date | Mon, 27 Apr 2026 09:15:08 -0400 | | Subject | Re: [bug report] Potential order violation in fs/dlm/midcomms.c, between 'dlm_midcomms_addr()' and 'dlm_midcomms_exit()' |
| |
Hi Ginger,
On Thu, Apr 23, 2026 at 1:35 AM Ginger <ginger.jzllee@gmail.com> wrote: > > Dear Linux kernel maintainers, > > My research-based static analyzer found a potential atomicity bug > within the 'fs/dlm' subsystem, more specifically, in > 'fs/dlm/midcomms.c'. > > Kernel version: long-term kernel v6.18.9 > > Potential concurrent triggering executions: > T0: > dlm_midcomms_addr > --> node = kmalloc(sizeof(*node)) > --> hlist_add_head_rcu(&node->hlist, &node_hash[r]); [t0] > --> node->debugfs = dlm_create_debug_comms_file(nodeid, node); [t3] > > T1: > dlm_midcomms_exit > --> hlist_for_each_entry_rcu(node, &node_hash[i], hlist) [t1] > --> dlm_delete_debug_comms_file(node->debugfs); [t2] > > In T0, the freshly allocated midcomms_node is first added to the > globally visible 'node_hash' list, and then has its 'debugfs' field > set up. > In this case, in T1, the exit function can first iterate over the > 'node_hash' list and access a 'debugfs' field that has not been set up > yet. > The concurrent buggy order is t0 -> t1 -> t2 -> t3, causing order violation. > > Please kindly check at your convenience. Thank you for your time and > consideration.
Thanks for the report. I looked into it and midcomms_exit() is called in module init/exit functions. I believe the case above can't happen, but I created a patch to change the behaviour to initialize the debugfs field in nodes at first before adding it to the node_hash. This avoids such an issue in potential future changes.
Thanks.
- Alex
|  |