All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Chao Yu <yuchao0@huawei.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/3] f2fs: turn off atomic writes when deteting abnormal behaviors
Date: Fri, 27 Jul 2018 18:17:21 +0900	[thread overview]
Message-ID: <20180727091721.GA16155@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <d7fe5243-b0cd-a685-fe24-7ce833a07015@kernel.org>

On 07/23, Chao Yu wrote:
> On 2018/7/23 21:03, Jaegeuk Kim wrote:
> > On 07/16, Chao Yu wrote:
> >> On 2018/7/15 9:11, Jaegeuk Kim wrote:
> >>> In order to prevent abusing atomic writes by abnormal users, we've added a
> >>> threshold, 20% over memory footprint, which disallows further atomic writes.
> >>> Previously, however, SQLite doesn't know the files became normal, so that
> >>> it could write stale data and commit on revoked normal database file.
> >>>
> >>> Once f2fs detects such the abnormal behavior, this patch simply disables
> >>> all the atomic operations such as:
> >>> - write_begin() gives EINVAL to avoid stale data writes, and SQLite will call
> >>>   F2FS_IOC_ABORT_VOLATILE_WRITE to notify aborting the transaction,
> >>> - F2FS_IOC_START_ATOMIC_WRITE gives EINVAL for SQLite to fall back normal
> >>>   journal_mode,
> >>> - F2FS_IOC_COMMIT_ATOMIC_WRITE gives EINVAL, if the file was revoked, so that
> >>>   Framework retries to submit the transaction given propagated SQLite error.
> >>>
> >>> Note that, this patch also turns off atomic operations, if foreground GC tries
> >>> to move atomic files too frequently.
> >>
> >> Well, how about just keeping original implementation: shutdown atomic write for
> >> those files which are really affect fggc? Since intention of the original
> >> behavior is targeting to abnormal atomic write usage, e.g. open atomic_write
> >> file for very long time, then fggc will be blocked each time when moving its
> >> block. So shutdown it, fggc will recover.
> > 
> > The point here is stopping sqlite to keep going wrong data writes even after
> > we already revoked blocks.
> 
> Yes, that's correct, what I mean is that if we can do that with smaller
> granularity like just revoke blocks for file which is blocking fggc, it will
> affect system/sqlite flow much less than forcing closing all atomic_write.

How about this?

From 64d2becb82a496c2e2c04abeed42efa3b401ee20 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
Date: Fri, 27 Jul 2018 18:15:11 +0900
Subject: [PATCH] f2fs: don't allow any writes on aborted atomic writes

In order to prevent abusing atomic writes by abnormal users, we've added a
threshold, 20% over memory footprint, which disallows further atomic writes.
Previously, however, SQLite doesn't know the files became normal, so that
it could write stale data and commit on revoked normal database file.

Once f2fs detects such the abnormal behavior, this patch tries to avoid further
writes in write_begin().

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
 fs/f2fs/data.c | 3 ++-
 fs/f2fs/file.c | 7 ++++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 22dd00c6e241..02ec2603725f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2295,7 +2295,8 @@ static int f2fs_write_begin(struct file *file, struct address_space *mapping,
 	trace_f2fs_write_begin(inode, pos, len, flags);
 
 	if (f2fs_is_atomic_file(inode) &&
-			!f2fs_available_free_memory(sbi, INMEM_PAGES)) {
+			(is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST) ||
+			!f2fs_available_free_memory(sbi, INMEM_PAGES))) {
 		err = -ENOMEM;
 		drop_atomic = true;
 		goto fail;
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index ff2cb8fb6934..c2c47f3248c4 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1708,8 +1708,11 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
 
 	down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
 
-	if (f2fs_is_atomic_file(inode))
+	if (f2fs_is_atomic_file(inode)) {
+		if (is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST))
+			ret = -EINVAL;
 		goto out;
+	}
 
 	ret = f2fs_convert_inline_inode(inode);
 	if (ret)
@@ -1871,6 +1874,8 @@ static int f2fs_ioc_abort_volatile_write(struct file *filp)
 		ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true);
 	}
 
+	clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
+
 	inode_unlock(inode);
 
 	mnt_drop_write_file(filp);
-- 
2.17.0.441.gb46fe60e1d-goog


WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Chao Yu <yuchao0@huawei.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/3] f2fs: turn off atomic writes when deteting abnormal behaviors
Date: Fri, 27 Jul 2018 18:17:21 +0900	[thread overview]
Message-ID: <20180727091721.GA16155@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <d7fe5243-b0cd-a685-fe24-7ce833a07015@kernel.org>

On 07/23, Chao Yu wrote:
> On 2018/7/23 21:03, Jaegeuk Kim wrote:
> > On 07/16, Chao Yu wrote:
> >> On 2018/7/15 9:11, Jaegeuk Kim wrote:
> >>> In order to prevent abusing atomic writes by abnormal users, we've added a
> >>> threshold, 20% over memory footprint, which disallows further atomic writes.
> >>> Previously, however, SQLite doesn't know the files became normal, so that
> >>> it could write stale data and commit on revoked normal database file.
> >>>
> >>> Once f2fs detects such the abnormal behavior, this patch simply disables
> >>> all the atomic operations such as:
> >>> - write_begin() gives EINVAL to avoid stale data writes, and SQLite will call
> >>>   F2FS_IOC_ABORT_VOLATILE_WRITE to notify aborting the transaction,
> >>> - F2FS_IOC_START_ATOMIC_WRITE gives EINVAL for SQLite to fall back normal
> >>>   journal_mode,
> >>> - F2FS_IOC_COMMIT_ATOMIC_WRITE gives EINVAL, if the file was revoked, so that
> >>>   Framework retries to submit the transaction given propagated SQLite error.
> >>>
> >>> Note that, this patch also turns off atomic operations, if foreground GC tries
> >>> to move atomic files too frequently.
> >>
> >> Well, how about just keeping original implementation: shutdown atomic write for
> >> those files which are really affect fggc? Since intention of the original
> >> behavior is targeting to abnormal atomic write usage, e.g. open atomic_write
> >> file for very long time, then fggc will be blocked each time when moving its
> >> block. So shutdown it, fggc will recover.
> > 
> > The point here is stopping sqlite to keep going wrong data writes even after
> > we already revoked blocks.
> 
> Yes, that's correct, what I mean is that if we can do that with smaller
> granularity like just revoke blocks for file which is blocking fggc, it will
> affect system/sqlite flow much less than forcing closing all atomic_write.

How about this?

>From 64d2becb82a496c2e2c04abeed42efa3b401ee20 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
Date: Fri, 27 Jul 2018 18:15:11 +0900
Subject: [PATCH] f2fs: don't allow any writes on aborted atomic writes

In order to prevent abusing atomic writes by abnormal users, we've added a
threshold, 20% over memory footprint, which disallows further atomic writes.
Previously, however, SQLite doesn't know the files became normal, so that
it could write stale data and commit on revoked normal database file.

Once f2fs detects such the abnormal behavior, this patch tries to avoid further
writes in write_begin().

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
 fs/f2fs/data.c | 3 ++-
 fs/f2fs/file.c | 7 ++++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 22dd00c6e241..02ec2603725f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2295,7 +2295,8 @@ static int f2fs_write_begin(struct file *file, struct address_space *mapping,
 	trace_f2fs_write_begin(inode, pos, len, flags);
 
 	if (f2fs_is_atomic_file(inode) &&
-			!f2fs_available_free_memory(sbi, INMEM_PAGES)) {
+			(is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST) ||
+			!f2fs_available_free_memory(sbi, INMEM_PAGES))) {
 		err = -ENOMEM;
 		drop_atomic = true;
 		goto fail;
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index ff2cb8fb6934..c2c47f3248c4 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1708,8 +1708,11 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
 
 	down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
 
-	if (f2fs_is_atomic_file(inode))
+	if (f2fs_is_atomic_file(inode)) {
+		if (is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST))
+			ret = -EINVAL;
 		goto out;
+	}
 
 	ret = f2fs_convert_inline_inode(inode);
 	if (ret)
@@ -1871,6 +1874,8 @@ static int f2fs_ioc_abort_volatile_write(struct file *filp)
 		ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true);
 	}
 
+	clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
+
 	inode_unlock(inode);
 
 	mnt_drop_write_file(filp);
-- 
2.17.0.441.gb46fe60e1d-goog

  reply	other threads:[~2018-07-27  9:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-15  1:11 [PATCH 1/3] f2fs: turn off atomic writes when deteting abnormal behaviors Jaegeuk Kim
2018-07-15  1:11 ` [PATCH 2/3] f2fs: keep meta pages in cp_error state Jaegeuk Kim
2018-07-16  9:40   ` Chao Yu
2018-07-16  9:40     ` Chao Yu
2018-07-23 11:59     ` Jaegeuk Kim
2018-07-15  1:11 ` [PATCH 3/3] f2fs: indicate shutdown f2fs to allow unmount successfully Jaegeuk Kim
2018-07-16  9:23 ` [PATCH 1/3] f2fs: turn off atomic writes when deteting abnormal behaviors Chao Yu
2018-07-16  9:23   ` Chao Yu
2018-07-23 13:03   ` Jaegeuk Kim
2018-07-23 13:27     ` [f2fs-dev] " Chao Yu
2018-07-27  9:17       ` Jaegeuk Kim [this message]
2018-07-27  9:17         ` Jaegeuk Kim
2018-07-27 11:44         ` Chao Yu
2018-07-29  5:51           ` Jaegeuk Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180727091721.GA16155@jaegeuk-macbookpro.roam.corp.google.com \
    --to=jaegeuk@kernel.org \
    --cc=chao@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuchao0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.