mirror of https://lore.kernel.org/lkml/
 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: Sat, 28 Jul 2018 22:51:05 -0700	[thread overview]
Message-ID: <20180729055105.GA3716@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <65fc88dc-5d38-6323-9ba0-8776bcd6165f@kernel.org>

On 07/27, Chao Yu wrote:
> On 2018/7/27 17:17, Jaegeuk Kim wrote:
> > 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?
> 
> Yes, it looks good to me. :)
> 
> > 
> > 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>
> 
> Reviewed-by: Chao Yu <yuchao0@huawei.com>
> 
> Thanks,
> 
> > ---
> >  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))) {

       if ((f2fs_is_atomic_file(inode) &&
                       !f2fs_available_free_memory(sbi, INMEM_PAGES)) ||
                       is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST)) {

-- Fixed wrong condition.

> >  		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);
> > 

      reply	other threads:[~2018-07-29  5:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-15  1:11 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-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-23 13:03   ` Jaegeuk Kim
2018-07-23 13:27     ` [f2fs-dev] " Chao Yu
2018-07-27  9:17       ` Jaegeuk Kim
2018-07-27 11:44         ` Chao Yu
2018-07-29  5:51           ` Jaegeuk Kim [this message]

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=20180729055105.GA3716@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®