Commit graph

5 commits

Author SHA1 Message Date
Al Viro
59eda0e07f new fs_pin killing logics
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-01-25 23:17:28 -05:00
Al Viro
fdab684d72 allow attaching fs_pin to a group not associated with some superblock
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-01-25 23:17:28 -05:00
Al Viro
34cece2e8a take count and rcu_head out of fs_pin
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-01-25 23:17:27 -05:00
Al Viro
9e251d0204 kill pin_put()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-01-25 23:16:28 -05:00
Al Viro
efb170c228 take fs_pin stuff to fs/*
Add a new field to fs_pin - kill(pin).  That's what umount and r/o remount
will be calling for all pins attached to vfsmount and superblock resp.
Called after bumping the refcount, so it won't go away under us.  Dropping
the refcount is responsibility of the instance.  All generic stuff moved to
fs/fs_pin.c; the next step will rip all the knowledge of kernel/acct.c from
fs/super.c and fs/namespace.c.  After that - death to mnt_pin(); it was
intended to be usable as generic mechanism for code that wants to attach
objects to vfsmount, so that they would not make the sucker busy and
would get killed on umount.  Never got it right; it remained acct.c-specific
all along.  Now it's very close to being killable.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-08-07 14:40:08 -04:00