Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200508042506.143395-1-daeho43@gmail.com> <4dfb73d9-03a0-bb2f-a112-1dd42db4d7bb@huawei.com>
 <CACOAw_z0BU3t7V+BN7TvaO96GckwNh2SRLreGxO60EDbMb_epw@mail.gmail.com> <cd08c824-c5d3-9603-7a81-a48cb191ac99@huawei.com>
In-Reply-To: <cd08c824-c5d3-9603-7a81-a48cb191ac99@huawei.com>
From:   Daeho Jeong <daeho43@gmail.com>
Date:   Fri, 8 May 2020 16:10:19 +0900
Message-ID: <CACOAw_xx-ZsVgEEb3D9Zu+2gWLZb9UjE3p8sDZbTNywcu2yBPA@mail.gmail.com>
Subject: Re: [f2fs-dev] [PATCH] f2fs: remove race condition in releasing cblocks
To:     Chao Yu <yuchao0@huawei.com>
Cc:     linux-kernel@vger.kernel.org,
        linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com,
        Daeho Jeong <daehojeong@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Oops,

I will re-check it.

Thanks,

2020=EB=85=84 5=EC=9B=94 8=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 4:09, Ch=
ao Yu <yuchao0@huawei.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
>
> On 2020/5/8 14:58, Daeho Jeong wrote:
> > I moved checking i_compr_blocks phrase after calling inode_lock()
> > already, because we should check this after writing pages.
> >
> > So, if it fails to check i_compr_blocks, we need to call inode_unlock()=
.
> >
> > Am I missing something?
>
> After applying this patch, I get this:
>
>         ret =3D mnt_want_write_file(filp);
>         if (ret)
>                 return ret;
>
>         if (!F2FS_I(inode)->i_compr_blocks)
>                 goto out;
>
>         f2fs_balance_fs(F2FS_I_SB(inode), true);
>
>         inode_lock(inode);
>
> >
> > 2020=EB=85=84 5=EC=9B=94 8=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 3:50=
, Chao Yu <yuchao0@huawei.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
> >>
> >> On 2020/5/8 12:25, Daeho Jeong wrote:
> >>> From: Daeho Jeong <daehojeong@google.com>
> >>>
> >>> Now, if writing pages and releasing compress blocks occur
> >>> simultaneously, and releasing cblocks is executed more than one time
> >>> to a file, then total block count of filesystem and block count of th=
e
> >>> file could be incorrect and damaged.
> >>>
> >>> We have to execute releasing compress blocks only one time for a file
> >>> without being interfered by writepages path.
> >>>
> >>> Signed-off-by: Daeho Jeong <daehojeong@google.com>
> >>> ---
> >>>  fs/f2fs/file.c | 31 ++++++++++++++++++++++++-------
> >>>  1 file changed, 24 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >>> index 4aab4b42d8ba..a92bc51b9b28 100644
> >>> --- a/fs/f2fs/file.c
> >>> +++ b/fs/f2fs/file.c
> >>> @@ -3488,6 +3488,7 @@ static int f2fs_release_compress_blocks(struct =
file *filp, unsigned long arg)
> >>>       pgoff_t page_idx =3D 0, last_idx;
> >>>       unsigned int released_blocks =3D 0;
> >>>       int ret;
> >>> +     int writecount;
> >>>
> >>>       if (!f2fs_sb_has_compression(F2FS_I_SB(inode)))
> >>>               return -EOPNOTSUPP;
> >>
> >> Before inode_lock(), there is one case we may jump to out label, in
> >> this case, we may unlock inode incorrectly.
> >>
> >>         if (!F2FS_I(inode)->i_compr_blocks)
> >>                 goto out;
> >>
> >>> -
> >>> -     inode_unlock(inode);
> >>>  out:
> >>> +     inode_unlock(inode);
> >>> +
> >>>       mnt_drop_write_file(filp);
> >>
> >> Thanks,
> > .
> >