Message	SHA1
new fs_pin killing logics ... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Al Viro   commited 2015-01-25 23:17:28 -05:00	59eda0e07f
allow attaching fs_pin to a group not associated with some superblock ... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Al Viro   commited 2015-01-25 23:17:28 -05:00	fdab684d72
take count and rcu_head out of fs_pin ... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Al Viro   commited 2015-01-25 23:17:27 -05:00	34cece2e8a
kill pin_put() ... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Al Viro   commited 2015-01-25 23:16:28 -05:00	9e251d0204
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> Al Viro   commited 2014-08-07 14:40:08 -04:00	efb170c228