diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2025-03-13 02:18:39 +0300 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2025-03-13 05:13:34 +0300 |
commit | c134deabf4784e155d360744d4a6a835b9de4dd4 (patch) | |
tree | 51301a748a275db4cfa95a835600d9d3d3f593e9 /tools/perf/scripts/python/parallel-perf.py | |
parent | d1ca8698ca1332625d83ea0d753747be66f9906d (diff) | |
download | linux-c134deabf4784e155d360744d4a6a835b9de4dd4.tar.xz |
spufs: fix gang directory lifetimes
prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have
a problem with gang lifetimes - creation of a gang returns opened
gang directory, which normally gets removed when that gets closed,
but if somebody has created a context belonging to that gang and
kept it alive until the gang got closed, removal failed and we
ended up with a leak.
Unfortunately, it had been fixed the wrong way. Dentry of gang
directory was no longer pinned, and rmdir on close was gone.
One problem was that failure of open kept calling simple_rmdir()
as cleanup, which meant an unbalanced dput(). Another bug was
in the success case - gang creation incremented link count on
root directory, but that was no longer undone when gang got
destroyed.
Fix consists of
* reverting the commit in question
* adding a counter to gang, protected by ->i_rwsem
of gang directory inode.
* having it set to 1 at creation time, dropped
in both spufs_dir_close() and spufs_gang_close() and bumped
in spufs_create_context(), provided that it's not 0.
* using simple_recursive_removal() to take the gang
directory out when counter reaches zero.
Fixes: 877907d37da9 "[POWERPC] spufs: Fix gang destroy leaks"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'tools/perf/scripts/python/parallel-perf.py')
0 files changed, 0 insertions, 0 deletions