aboutsummaryrefslogtreecommitdiffstats
path: root/fs/afs/super.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2009-05-06 01:07:50 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2009-05-09 10:49:39 -0400
commit74dbbdd7fdc11763f4698d2f3e684cf4446951e6 (patch)
treef31d70174915b0d209fafeec35e996e8ed7e269d /fs/afs/super.c
parent677c9b2e393a0cd203bd54e9c18b012b2c73305a (diff)
downloadkernel_samsung_smdk4412-74dbbdd7fdc11763f4698d2f3e684cf4446951e6.zip
kernel_samsung_smdk4412-74dbbdd7fdc11763f4698d2f3e684cf4446951e6.tar.gz
kernel_samsung_smdk4412-74dbbdd7fdc11763f4698d2f3e684cf4446951e6.tar.bz2
New helper: deactivate_locked_super()
Does equivalent of up_write(&s->s_umount); deactivate_super(s); However, it does not does not unlock it until it's all over. As the result, it's safe to use to dispose of new superblock on ->get_sb() failure exits - nobody will see the sucker until it's all over. Equivalent using up_write/deactivate_super is safe for that purpose if superblock is either safe to use or has NULL ->s_root when we unlock. Normally filesystems take the required precautions, but a) we do have bugs in that area in some of them. b) up_write/deactivate_super sequence is extremely common, so the helper makes sense anyway. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/afs/super.c')
0 files changed, 0 insertions, 0 deletions