summaryrefslogtreecommitdiff
path: root/rust/helpers/workqueue.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2025-11-17 14:22:46 -0500
committerAl Viro <viro@zeniv.linux.org.uk>2025-11-17 23:52:20 -0500
commitfcb8985143540cbcb8e91c0ea8b7fb5d37c88177 (patch)
treee533927d9c4c849855ff930ac7ae8d9970ce76c5 /rust/helpers/workqueue.c
parentcd08d17f39b7b7c54bfa35437fa4cd4e144d8179 (diff)
functionfs: don't abuse ffs_data_closed() on fs shutdown
ffs_data_closed() has a seriously confusing logics in it: in addition to the normal "decrement a counter and do some work if it hits zero" there's "... and if it has somehow become negative, do that" bit. It's not a race, despite smelling rather fishy. What really happens is that in addition to "call that on close of files there, to match the increments of counter on opens" there's one call in ->kill_sb(). Counter starts at 0 and never goes negative over the lifetime of filesystem (or we have much worse problems everywhere - ->release() call of some file somehow unpaired with successful ->open() of the same). At the filesystem shutdown it will be 0 or, again, we have much worse problems - filesystem instance destroyed with files on it still open. In other words, at that call and at that call alone the decrement would go from 0 to -1, hitting that chunk (and not hitting the "if it hits 0" part). So that check is a weirdly spelled "called from ffs_kill_sb()". Just expand the call in the latter and kill the misplaced chunk in ffs_data_closed(). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'rust/helpers/workqueue.c')
0 files changed, 0 insertions, 0 deletions