Received-SPF: pass (google.com: domain of linux-kernel+bounces-25063-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231228143152.1543509-1-chao@kernel.org> <20231228143152.1543509-3-chao@kernel.org>
 <CACOAw_xCfOtJaC3FbOhvbrEzyUwecdSujFo4-f--dz+33BC+Sg@mail.gmail.com>
 <e7f4a835-6a4c-4f94-a79f-a425b04516e2@kernel.org> <CACOAw_wzBTV=+cqZeiCZvhud1Ek06aW_5nJbg=9FF327MNgxEg@mail.gmail.com>
 <d2f2e4ba-8668-4e37-a56f-dbe7c730b01f@kernel.org>
In-Reply-To: <d2f2e4ba-8668-4e37-a56f-dbe7c730b01f@kernel.org>
From: Daeho Jeong <daeho43@gmail.com>
Date: Fri, 12 Jan 2024 14:19:34 -0800
Message-ID: <CACOAw_xLFQchVKde8dH5EooqrUq8J1pftDYFJ-Ur6KaqXL_dfQ@mail.gmail.com>
Subject: Re: [f2fs-dev] [PATCH v3 3/6] f2fs: compress: fix to check unreleased
 compressed cluster
To: Chao Yu <chao@kernel.org>
Cc: jaegeuk@kernel.org, linux-kernel@vger.kernel.org, 
	linux-f2fs-devel@lists.sourceforge.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 11, 2024 at 5:06=E2=80=AFPM Chao Yu <chao@kernel.org> wrote:
>
> On 2024/1/12 1:15, Daeho Jeong wrote:
> > On Wed, Jan 10, 2024 at 5:33=E2=80=AFPM Chao Yu <chao@kernel.org> wrote=
:
> >>
> >> On 2024/1/11 9:18, Daeho Jeong wrote:
> >>> On Thu, Dec 28, 2023 at 6:33=E2=80=AFAM Chao Yu <chao@kernel.org> wro=
te:
> >>>>
> >>>> From: Sheng Yong <shengyong@oppo.com>
> >>>>
> >>>> Compressed cluster may not be released due to we can fail in
> >>>> release_compress_blocks(), fix to handle reserved compressed
> >>>> cluster correctly in reserve_compress_blocks().
> >>>>
> >>>> Fixes: 4c8ff7095bef ("f2fs: support data compression")
> >>>> Signed-off-by: Sheng Yong <shengyong@oppo.com>
> >>>> Signed-off-by: Chao Yu <chao@kernel.org>
> >>>> ---
> >>>>    fs/f2fs/file.c | 12 ++++++++++++
> >>>>    1 file changed, 12 insertions(+)
> >>>>
> >>>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >>>> index 026d05a7edd8..782ae3be48f6 100644
> >>>> --- a/fs/f2fs/file.c
> >>>> +++ b/fs/f2fs/file.c
> >>>> @@ -3624,6 +3624,15 @@ static int reserve_compress_blocks(struct dno=
de_of_data *dn, pgoff_t count)
> >>>>                                   goto next;
> >>>>                           }
> >>>>
> >>>> +                       /*
> >>>> +                        * compressed cluster was not released due t=
o
> >>>> +                        * it fails in release_compress_blocks().
> >>>> +                        */
> >>>> +                       if (blkaddr =3D=3D NEW_ADDR) {
> >>>> +                               compr_blocks++;
> >>>> +                               continue;
> >>>> +                       }
> >>>> +
> >>>>                           if (__is_valid_data_blkaddr(blkaddr)) {
> >>>>                                   compr_blocks++;
> >>>>                                   continue;
> >>>
> >>> How about merging two conditions like "blkaddr =3D=3D NEW_ADDR ||
> >>> __is_valid_data_blkaddr(blkaddr)"?
> >>
> >> Oh, sure.
> >>
> >>>
> >>>> @@ -3633,6 +3642,9 @@ static int reserve_compress_blocks(struct dnod=
e_of_data *dn, pgoff_t count)
> >>>>                   }
> >>>>
> >>>>                   reserved =3D cluster_size - compr_blocks;
> >>>> +               if (!reserved)
> >>>> +                       goto next;
> >>>> +
> >>>
> >>> How can the reserved variable be zero?
> >>
> >> I guess it can happen if a cluster was not released during
> >> release_compress_blocks(), then all blocks in the cluster should
> >> has been reserved, so, in this round of reserving, it needs to skip
> >> reserve blocks, right?
> >
> > Let's assume cluster_size is 4. How can compr_blocks be 4?
> >
> >                          if (i =3D=3D 0) {
> >                                  if (blkaddr =3D=3D COMPRESS_ADDR)
> >                                          continue;
> >                                  dn->ofs_in_node +=3D cluster_size;
> >                                  goto next;
> >                          }
> >
> > We skip the block having COMPRESS_ADDR when counting compr_blocks.
> > So, the maximum value of compr_blocks should be 3, right?
>
> Ah, got it, and I think you're right.
>
> Should fix the condition as below?
>
>                 /* for the case all blocks in cluster were reserved */
>                 if (reserved =3D=3D 1)
>                         goto next;

It looks good to me.

>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>
> >>>
> >>>>                   ret =3D inc_valid_block_count(sbi, dn->inode, &res=
erved);
> >>>>                   if (ret)
> >>>>                           return ret;
> >>>> --
> >>>> 2.40.1
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Linux-f2fs-devel mailing list
> >>>> Linux-f2fs-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel