* [HACK] fs/super.c: sync ro remount after blocking writers
@ 2014-01-30 15:26 ` Andrew Ruder
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Ruder @ 2014-01-30 15:26 UTC (permalink / raw)
To: linux-fsdevel, linux-mtd
Cc: Andrew Ruder, Artem Bityutskiy, Christoph Hellwig,
Alexander Viro, Richard Weinberger
Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
it can cause inodes to be dirtied and writeback to occur well after
sys_mount() has completely successfully.
This was spotted by corrupted ubifs filesystems on reboot, but appears
that it can cause issues with any filesystem using writeback.
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Richard Weinberger <richard@nod.at>
Co-authored-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
---
I marked this as hack as because there is still a race condition concerning
the force == 1 situation. mark_files_ro() never actually blocks new
writers even through the filesystem-specific remount code because nothing
ever sets sb->s_readonly_remount.
fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/super.c b/fs/super.c
index 0225c20..1912090d 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -735,59 +735,59 @@ rescan:
int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
{
int retval;
int remount_ro;
if (sb->s_writers.frozen != SB_UNFROZEN)
return -EBUSY;
#ifdef CONFIG_BLOCK
if (!(flags & MS_RDONLY) && bdev_read_only(sb->s_bdev))
return -EACCES;
#endif
if (flags & MS_RDONLY)
acct_auto_close(sb);
shrink_dcache_sb(sb);
- sync_filesystem(sb);
remount_ro = (flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY);
/* If we are remounting RDONLY and current sb is read/write,
make sure there are no rw files opened */
if (remount_ro) {
if (force) {
mark_files_ro(sb);
} else {
retval = sb_prepare_remount_readonly(sb);
if (retval)
return retval;
}
}
+ sync_filesystem(sb);
if (sb->s_op->remount_fs) {
retval = sb->s_op->remount_fs(sb, &flags, data);
if (retval) {
if (!force)
goto cancel_readonly;
/* If forced remount, go ahead despite any errors */
WARN(1, "forced remount of a %s fs returned %i\n",
sb->s_type->name, retval);
}
}
sb->s_flags = (sb->s_flags & ~MS_RMT_MASK) | (flags & MS_RMT_MASK);
/* Needs to be ordered wrt mnt_is_readonly() */
smp_wmb();
sb->s_readonly_remount = 0;
/*
* Some filesystems modify their metadata via some other path than the
* bdev buffer cache (eg. use a private mapping, or directories in
* pagecache, etc). Also file data modifications go via their own
* mappings. So If we try to mount readonly then copy the filesystem
* from bdev, we could get stale data, so invalidate it to give a best
* effort at coherency.
*/
if (remount_ro && sb->s_bdev)
invalidate_bdev(sb->s_bdev);
return 0;
--
1.8.5.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [HACK] fs/super.c: sync ro remount after blocking writers
@ 2014-01-30 15:26 ` Andrew Ruder
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Ruder @ 2014-01-30 15:26 UTC (permalink / raw)
To: linux-fsdevel, linux-mtd
Cc: Christoph Hellwig, Richard Weinberger, Andrew Ruder,
Alexander Viro, Artem Bityutskiy
Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
it can cause inodes to be dirtied and writeback to occur well after
sys_mount() has completely successfully.
This was spotted by corrupted ubifs filesystems on reboot, but appears
that it can cause issues with any filesystem using writeback.
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Richard Weinberger <richard@nod.at>
Co-authored-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
---
I marked this as hack as because there is still a race condition concerning
the force == 1 situation. mark_files_ro() never actually blocks new
writers even through the filesystem-specific remount code because nothing
ever sets sb->s_readonly_remount.
fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/super.c b/fs/super.c
index 0225c20..1912090d 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -735,59 +735,59 @@ rescan:
int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
{
int retval;
int remount_ro;
if (sb->s_writers.frozen != SB_UNFROZEN)
return -EBUSY;
#ifdef CONFIG_BLOCK
if (!(flags & MS_RDONLY) && bdev_read_only(sb->s_bdev))
return -EACCES;
#endif
if (flags & MS_RDONLY)
acct_auto_close(sb);
shrink_dcache_sb(sb);
- sync_filesystem(sb);
remount_ro = (flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY);
/* If we are remounting RDONLY and current sb is read/write,
make sure there are no rw files opened */
if (remount_ro) {
if (force) {
mark_files_ro(sb);
} else {
retval = sb_prepare_remount_readonly(sb);
if (retval)
return retval;
}
}
+ sync_filesystem(sb);
if (sb->s_op->remount_fs) {
retval = sb->s_op->remount_fs(sb, &flags, data);
if (retval) {
if (!force)
goto cancel_readonly;
/* If forced remount, go ahead despite any errors */
WARN(1, "forced remount of a %s fs returned %i\n",
sb->s_type->name, retval);
}
}
sb->s_flags = (sb->s_flags & ~MS_RMT_MASK) | (flags & MS_RMT_MASK);
/* Needs to be ordered wrt mnt_is_readonly() */
smp_wmb();
sb->s_readonly_remount = 0;
/*
* Some filesystems modify their metadata via some other path than the
* bdev buffer cache (eg. use a private mapping, or directories in
* pagecache, etc). Also file data modifications go via their own
* mappings. So If we try to mount readonly then copy the filesystem
* from bdev, we could get stale data, so invalidate it to give a best
* effort at coherency.
*/
if (remount_ro && sb->s_bdev)
invalidate_bdev(sb->s_bdev);
return 0;
--
1.8.5.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
2014-01-30 15:26 ` Andrew Ruder
@ 2014-01-31 8:20 ` Richard Weinberger
-1 siblings, 0 replies; 9+ messages in thread
From: Richard Weinberger @ 2014-01-31 8:20 UTC (permalink / raw)
To: Andrew Ruder, linux-fsdevel, linux-mtd
Cc: Artem Bityutskiy, Christoph Hellwig, Alexander Viro
Am 30.01.2014 16:26, schrieb Andrew Ruder:
> Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
> sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
> it can cause inodes to be dirtied and writeback to occur well after
> sys_mount() has completely successfully.
>
> This was spotted by corrupted ubifs filesystems on reboot, but appears
> that it can cause issues with any filesystem using writeback.
Link to original report:
http://lists.infradead.org/pipermail/linux-mtd/2014-January/051651.html
What we see is that writeback still happens after mounting the fs ro.
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
@ 2014-01-31 8:20 ` Richard Weinberger
0 siblings, 0 replies; 9+ messages in thread
From: Richard Weinberger @ 2014-01-31 8:20 UTC (permalink / raw)
To: Andrew Ruder, linux-fsdevel, linux-mtd
Cc: Christoph Hellwig, Alexander Viro, Artem Bityutskiy
Am 30.01.2014 16:26, schrieb Andrew Ruder:
> Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
> sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
> it can cause inodes to be dirtied and writeback to occur well after
> sys_mount() has completely successfully.
>
> This was spotted by corrupted ubifs filesystems on reboot, but appears
> that it can cause issues with any filesystem using writeback.
Link to original report:
http://lists.infradead.org/pipermail/linux-mtd/2014-January/051651.html
What we see is that writeback still happens after mounting the fs ro.
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
2014-01-30 15:26 ` Andrew Ruder
@ 2014-02-03 10:23 ` Christoph Hellwig
-1 siblings, 0 replies; 9+ messages in thread
From: Christoph Hellwig @ 2014-02-03 10:23 UTC (permalink / raw)
To: Andrew Ruder
Cc: linux-fsdevel, linux-mtd, Artem Bityutskiy, Christoph Hellwig,
Alexander Viro, Richard Weinberger
On Thu, Jan 30, 2014 at 09:26:54AM -0600, Andrew Ruder wrote:
> Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
> sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
> it can cause inodes to be dirtied and writeback to occur well after
> sys_mount() has completely successfully.
>
> This was spotted by corrupted ubifs filesystems on reboot, but appears
> that it can cause issues with any filesystem using writeback.
>From the link that Richard posted it seems like you have a testcase.
Can you please integrate it into xfstests so that we can properly
regression test for this issue from now on?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
@ 2014-02-03 10:23 ` Christoph Hellwig
0 siblings, 0 replies; 9+ messages in thread
From: Christoph Hellwig @ 2014-02-03 10:23 UTC (permalink / raw)
To: Andrew Ruder
Cc: Artem Bityutskiy, Richard Weinberger, Christoph Hellwig,
linux-mtd, Alexander Viro, linux-fsdevel
On Thu, Jan 30, 2014 at 09:26:54AM -0600, Andrew Ruder wrote:
> Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
> sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
> it can cause inodes to be dirtied and writeback to occur well after
> sys_mount() has completely successfully.
>
> This was spotted by corrupted ubifs filesystems on reboot, but appears
> that it can cause issues with any filesystem using writeback.
>From the link that Richard posted it seems like you have a testcase.
Can you please integrate it into xfstests so that we can properly
regression test for this issue from now on?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
2014-02-03 10:23 ` Christoph Hellwig
@ 2014-02-28 9:25 ` Richard Weinberger
-1 siblings, 0 replies; 9+ messages in thread
From: Richard Weinberger @ 2014-02-28 9:25 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Ruder
Cc: linux-fsdevel, linux-mtd, Artem Bityutskiy, Alexander Viro
Andrew,
Am 03.02.2014 11:23, schrieb Christoph Hellwig:
> On Thu, Jan 30, 2014 at 09:26:54AM -0600, Andrew Ruder wrote:
>> Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
>> sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
>> it can cause inodes to be dirtied and writeback to occur well after
>> sys_mount() has completely successfully.
>>
>> This was spotted by corrupted ubifs filesystems on reboot, but appears
>> that it can cause issues with any filesystem using writeback.
>
> From the link that Richard posted it seems like you have a testcase.
> Can you please integrate it into xfstests so that we can properly
> regression test for this issue from now on?
Is it possible to create such a test case?
I don't know whether it is possible to trigger the issue on
a regular filesystem.
But as hch noted, it would be nice to have. :)
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
@ 2014-02-28 9:25 ` Richard Weinberger
0 siblings, 0 replies; 9+ messages in thread
From: Richard Weinberger @ 2014-02-28 9:25 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Ruder
Cc: linux-fsdevel, linux-mtd, Alexander Viro, Artem Bityutskiy
Andrew,
Am 03.02.2014 11:23, schrieb Christoph Hellwig:
> On Thu, Jan 30, 2014 at 09:26:54AM -0600, Andrew Ruder wrote:
>> Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
>> sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
>> it can cause inodes to be dirtied and writeback to occur well after
>> sys_mount() has completely successfully.
>>
>> This was spotted by corrupted ubifs filesystems on reboot, but appears
>> that it can cause issues with any filesystem using writeback.
>
> From the link that Richard posted it seems like you have a testcase.
> Can you please integrate it into xfstests so that we can properly
> regression test for this issue from now on?
Is it possible to create such a test case?
I don't know whether it is possible to trigger the issue on
a regular filesystem.
But as hch noted, it would be nice to have. :)
Thanks,
//richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [HACK] fs/super.c: sync ro remount after blocking writers
2014-02-28 9:25 ` Richard Weinberger
(?)
@ 2014-03-03 21:12 ` Andrew Ruder
-1 siblings, 0 replies; 9+ messages in thread
From: Andrew Ruder @ 2014-03-03 21:12 UTC (permalink / raw)
To: linux-mtd
On Fri, Feb 28, 2014 at 10:25:24AM +0100, Richard Weinberger wrote:
> Is it possible to create such a test case? I don't know whether it is
> possible to trigger the issue on a regular filesystem. But as hch
> noted, it would be nice to have. :)
I've given this some thought after initially receiving the email and it
would not be easily recreated. As best as I can tell, the test case
would be something along the line of:
1. # Start up a filesystem writer
2. mount -o remount,ro /testfilesystem
3. # Immediately mark block device as read only
4. # Reboot, show that the filesystem is dirty next time around.
Step 3 I'm not sure how to do, Step 4 makes for the world's most painful
test case. The thread from Leon Pollak is probably the easiest way to
recreate these issues (remount,ro followed by a hardware-enabled
read-only) and I'm just not sure it belongs in a test case.
- Andy
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-03-03 21:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-30 15:26 [HACK] fs/super.c: sync ro remount after blocking writers Andrew Ruder
2014-01-30 15:26 ` Andrew Ruder
2014-01-31 8:20 ` Richard Weinberger
2014-01-31 8:20 ` Richard Weinberger
2014-02-03 10:23 ` Christoph Hellwig
2014-02-03 10:23 ` Christoph Hellwig
2014-02-28 9:25 ` Richard Weinberger
2014-02-28 9:25 ` Richard Weinberger
2014-03-03 21:12 ` Andrew Ruder
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.