[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <1462150237-20701-1-git-send-email-daeho.jeong@samsung.com>
Date: Mon, 02 May 2016 09:50:37 +0900
From: Daeho Jeong <daeho.jeong@...sung.com>
To: tytso@....edu, linux-ext4@...r.kernel.org
Cc: Daeho Jeong <daeho.jeong@...sung.com>,
Kitae Lee <kitae87.lee@...sung.com>
Subject: [PATCH] ext4: guarantee already started handles to successfully finish
while ro remounting
We check whether a new handle can be started through
ext4_journal_check_start() and the function refuses to start the handle
when the filesystem is mounted with read-only. But now, when we remount
the filesystem with read-only option, already started handles are
allowed to be written on disk, but the subsequent metadata modification
using the handles are refused by ext4_journal_check_start().
As an example, in ext4_evict_inode(), i_size can be set to 0 using
a successfully started handle, but, when we remount the filesystem
with read-only option at that time, the subsequent ext4_truncate()
will be failed and the filesystem integrity will be damaged.
Therefore, we need to permit the metadata modification using already
started handles to be proceeded, even if s_flags of the filesystem is
set to MS_RDONLY.
Kitae found the problem and suggested the solution.
Signed-off-by: Kitae Lee <kitae87.lee@...sung.com>
Signed-off-by: Daeho Jeong <daeho.jeong@...sung.com>
---
fs/ext4/ext4_jbd2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
index e770c1ee..3b59e11 100644
--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -43,7 +43,7 @@ static int ext4_journal_check_start(struct super_block *sb)
journal_t *journal;
might_sleep();
- if (sb->s_flags & MS_RDONLY)
+ if (sb->s_flags & MS_RDONLY && ext4_journal_current_handle() == NULL)
return -EROFS;
WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);
journal = EXT4_SB(sb)->s_journal;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists