diff options
| author | Al Viro <viro@zeniv.linux.org.uk> | 2025-11-17 14:22:46 -0500 |
|---|---|---|
| committer | Al Viro <viro@zeniv.linux.org.uk> | 2025-11-17 23:52:20 -0500 |
| commit | fcb8985143540cbcb8e91c0ea8b7fb5d37c88177 (patch) | |
| tree | e533927d9c4c849855ff930ac7ae8d9970ce76c5 /rust/helpers/task.c | |
| parent | cd08d17f39b7b7c54bfa35437fa4cd4e144d8179 (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/task.c')
0 files changed, 0 insertions, 0 deletions
