On Fri, Jan 30, 2015 at 09:11:26AM +0800, Qu Wenruo wrote: > For the mounted ro case, that's not a problem, since if one instance > is mounted ro, > other instances are also mounted ro, so that's not a problem. Not really. root@satch:~# cd /tmp/ root@satch:~# mkdir /tm/a root@satch:~# mount --bind /tmp/ /tmp/a root@satch:~# mount --bind -o remount,ro /tmp/a root@satch:~# mkdir /tmp/b root@satch:~# mkdir /tmp/a/c mkdir: cannot create directory '/tmp/a/c': Read-only file system root@satch:~# stat /tmp/b /tmp/a/b File: '/tmp/b' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 806h/2054d Inode: 257537 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-01-29 21:03:35.000000000 -0500 Modify: 2015-01-29 21:03:35.000000000 -0500 Change: 2015-01-29 21:03:35.000000000 -0500 Birth: - File: '/tmp/a/b' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 806h/2054d Inode: 257537 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-01-29 21:03:35.000000000 -0500 Modify: 2015-01-29 21:03:35.000000000 -0500 Change: 2015-01-29 21:03:35.000000000 -0500 Birth: - root@satch:~# IOW, /tmp and /tmp/a bear the same filesystem (one from /dev/sda6), the former is mounted r/w, the latter - r/o. > >Assuming that your superblock is guaranteed to stay alive and usable for > >whatever work you are trying to do, what's wrong with sb_want_write()? > Did you mean change the function name and it's parameter to > sb_want_write(sb) and sb_drop_write(sb). > That looks much better. > But I'm a little worried about just using sb_start_write() and > s_readonly_remount/s_flags to do the protection, > will it be enough? Protection against what? If superblock is r/w, it will stay r/w until you do sb_drop_write(); if it's r/o, sb_want_write() will fail. There might be any number of vfsmounts over superblock; attempt to get write access via vfsmount will succeed only of both the vfsmount and superblock are r/w - mnt_want_write() does sb_want_write() and fails if that has failed. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
