All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Nanzhe Zhao <nzzhao@126.com>
Cc: Kim Jaegeuk <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v1 4/5] f2fs: add 'folio_in_bio' to handle readahead folios with no BIO submission
Date: Wed, 7 Jan 2026 09:16:50 +0800	[thread overview]
Message-ID: <c83f9368-e962-440c-9107-ba76ca71602a@kernel.org> (raw)
In-Reply-To: <6a3d4e52.402.19b95df7350.Coremail.nzzhao@126.com>

On 1/7/2026 8:33 AM, Nanzhe Zhao wrote:
> Hi Chao yu:
> At 2026-01-06 17:31:20, "Chao Yu" <chao@kernel.org> wrote:
>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>>> index 66ab7a43a56f..ac569a396914 100644
>>>> --- a/fs/f2fs/data.c
>>>> +++ b/fs/f2fs/data.c
>>>> @@ -2430,6 +2430,7 @@ static int f2fs_read_data_large_folio(struct inode *inode,
>>>>    	unsigned nrpages;
>>>>    	struct f2fs_folio_state *ffs;
>>>>    	int ret = 0;
>>>> +	bool folio_in_bio = false;
>>>
>>> No need to initialize folio_in_bio?
> 
> Agreed. It's redundant since we reset it to false for each new folio before processing.
> 
>>>> @@ -2539,6 +2542,11 @@ static int f2fs_read_data_large_folio(struct inode *inode,
>>>>    	}
>>>>    	trace_f2fs_read_folio(folio, DATA);
>>>>    	if (rac) {
>>>> +		if (!folio_in_bio) {
>>>> +			if (!ret)
>>>> +				folio_mark_uptodate(folio);
>>>> +			folio_unlock(folio);
>>>> +	}
>>>
>>> err_out:
>>> 	/* Nothing was submitted. */
>>> 	if (!bio) {
>>> 		if (!ret)
>>> 			folio_mark_uptodate(folio);
>>> 		folio_unlock(folio);
>>>
>>>                  ^^^^^^^^^^^^
>>>
>>> If all folios in rac have not been mapped (hole case), will we unlock the folio twice?
> 
> Are you worried the folio could be unlocked once in the if (rac) { ... } block and then
> unlocked again at err_out:? If so, I think that won't happen.
> 
> In such a case, every non-NULL folio will be unlocked exactly once by:
> 
> if (!folio_in_bio) {
>         if (!ret)
>                 folio_mark_uptodate(folio);
>         folio_unlock(folio);
> }
> Specifically, after the last folio runs through the block above, the next call:
> 
> folio = readahead_folio(rac);
> will return NULL. Then we go to next_folio:, and will directly hit:
> 
> if (!folio)
>         goto out;
> This jumps straight to the out: label, skipping err_out: entirely.
> Therefore, when ret is not an error code, the err_out: label will never be reached.
> 
> If ret becomes an error code, then the current folio will immediately goto err_out;
> and be unlocked there once.
> 
> If rac is NULL (meaning we only read the single large folio passed in as the function argument),
> we won't enter the if (rac) { ... goto next_folio; } path at all, so we also won't go to next_folio
> and then potentially goto out;. In that case, it will naturally be unlocked once at err_out:.
> Or am I missing some edge case here?

Nanzhe,

Oh, yes, I think so, thanks for the explanation.

Thanks,

> 
> Thanks,
> Nanzhe



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <chao@kernel.org>
To: Nanzhe Zhao <nzzhao@126.com>
Cc: chao@kernel.org, Kim Jaegeuk <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 4/5] f2fs: add 'folio_in_bio' to handle readahead folios with no BIO submission
Date: Wed, 7 Jan 2026 09:16:50 +0800	[thread overview]
Message-ID: <c83f9368-e962-440c-9107-ba76ca71602a@kernel.org> (raw)
In-Reply-To: <6a3d4e52.402.19b95df7350.Coremail.nzzhao@126.com>

On 1/7/2026 8:33 AM, Nanzhe Zhao wrote:
> Hi Chao yu:
> At 2026-01-06 17:31:20, "Chao Yu" <chao@kernel.org> wrote:
>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>>> index 66ab7a43a56f..ac569a396914 100644
>>>> --- a/fs/f2fs/data.c
>>>> +++ b/fs/f2fs/data.c
>>>> @@ -2430,6 +2430,7 @@ static int f2fs_read_data_large_folio(struct inode *inode,
>>>>    	unsigned nrpages;
>>>>    	struct f2fs_folio_state *ffs;
>>>>    	int ret = 0;
>>>> +	bool folio_in_bio = false;
>>>
>>> No need to initialize folio_in_bio?
> 
> Agreed. It's redundant since we reset it to false for each new folio before processing.
> 
>>>> @@ -2539,6 +2542,11 @@ static int f2fs_read_data_large_folio(struct inode *inode,
>>>>    	}
>>>>    	trace_f2fs_read_folio(folio, DATA);
>>>>    	if (rac) {
>>>> +		if (!folio_in_bio) {
>>>> +			if (!ret)
>>>> +				folio_mark_uptodate(folio);
>>>> +			folio_unlock(folio);
>>>> +	}
>>>
>>> err_out:
>>> 	/* Nothing was submitted. */
>>> 	if (!bio) {
>>> 		if (!ret)
>>> 			folio_mark_uptodate(folio);
>>> 		folio_unlock(folio);
>>>
>>>                  ^^^^^^^^^^^^
>>>
>>> If all folios in rac have not been mapped (hole case), will we unlock the folio twice?
> 
> Are you worried the folio could be unlocked once in the if (rac) { ... } block and then
> unlocked again at err_out:? If so, I think that won't happen.
> 
> In such a case, every non-NULL folio will be unlocked exactly once by:
> 
> if (!folio_in_bio) {
>         if (!ret)
>                 folio_mark_uptodate(folio);
>         folio_unlock(folio);
> }
> Specifically, after the last folio runs through the block above, the next call:
> 
> folio = readahead_folio(rac);
> will return NULL. Then we go to next_folio:, and will directly hit:
> 
> if (!folio)
>         goto out;
> This jumps straight to the out: label, skipping err_out: entirely.
> Therefore, when ret is not an error code, the err_out: label will never be reached.
> 
> If ret becomes an error code, then the current folio will immediately goto err_out;
> and be unlocked there once.
> 
> If rac is NULL (meaning we only read the single large folio passed in as the function argument),
> we won't enter the if (rac) { ... goto next_folio; } path at all, so we also won't go to next_folio
> and then potentially goto out;. In that case, it will naturally be unlocked once at err_out:.
> Or am I missing some edge case here?

Nanzhe,

Oh, yes, I think so, thanks for the explanation.

Thanks,

> 
> Thanks,
> Nanzhe


  reply	other threads:[~2026-01-07  1:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-05 15:30 [f2fs-dev] [PATCH v1 0/5] f2fs: fix large folio read corner cases for immutable files Nanzhe Zhao
2026-01-05 15:30 ` Nanzhe Zhao
2026-01-05 15:30 ` [f2fs-dev] [PATCH v1 1/5] f2fs: Zero f2fs_folio_state on allocation Nanzhe Zhao
2026-01-05 15:30   ` Nanzhe Zhao
2026-01-06  3:38   ` [f2fs-dev] " Barry Song
2026-01-06  3:38     ` Barry Song
2026-01-07  3:44     ` [f2fs-dev] " Nanzhe Zhao
2026-01-07  3:44       ` Nanzhe Zhao
2026-01-08 22:35       ` [f2fs-dev] " Barry Song
2026-01-08 22:35         ` Barry Song
2026-01-06  9:16   ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-06  9:16     ` Chao Yu
2026-01-05 15:30 ` [f2fs-dev] [PATCH v1 2/5] f2fs: Accounting large folio subpages before bio submission Nanzhe Zhao
2026-01-05 15:30   ` Nanzhe Zhao
2026-01-06  9:16   ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-06  9:16     ` Chao Yu
2026-01-05 15:30 ` [f2fs-dev] [PATCH v1 3/5] f2fs: add f2fs_block_needs_zeroing() to handle hole blocks Nanzhe Zhao
2026-01-05 15:30   ` Nanzhe Zhao
2026-01-06  9:19   ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-06  9:19     ` Chao Yu
2026-01-06 11:25     ` [f2fs-dev] " Nanzhe Zhao
2026-01-06 11:25       ` Nanzhe Zhao
2026-01-06  9:30   ` [f2fs-dev] " kernel test robot
2026-01-06  9:30     ` kernel test robot
2026-01-05 15:31 ` [f2fs-dev] [PATCH v1 4/5] f2fs: add 'folio_in_bio' to handle readahead folios with no BIO submission Nanzhe Zhao
2026-01-05 15:31   ` Nanzhe Zhao
2026-01-06  9:31   ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-06  9:31     ` Chao Yu
2026-01-07  0:33     ` [f2fs-dev] " Nanzhe Zhao
2026-01-07  0:33       ` Nanzhe Zhao
2026-01-07  1:16       ` Chao Yu via Linux-f2fs-devel [this message]
2026-01-07  1:16         ` Chao Yu
2026-01-05 15:31 ` [f2fs-dev] [PATCH v1 5/5] f2fs: advance index and offset after zeroing in large folio read Nanzhe Zhao
2026-01-05 15:31   ` Nanzhe Zhao
2026-01-06  9:35   ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-06  9:35     ` Chao Yu
2026-01-07  3:08 ` [f2fs-dev] [PATCH v1 0/5] f2fs: fix large folio read corner cases for immutable files Jaegeuk Kim via Linux-f2fs-devel
2026-01-07  3:08   ` Jaegeuk Kim
2026-01-08  2:17   ` [f2fs-dev] " Nanzhe Zhao
2026-01-08  2:17     ` Nanzhe Zhao
2026-01-08  9:23     ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-08  9:23       ` Chao Yu

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=c83f9368-e962-440c-9107-ba76ca71602a@kernel.org \
    --to=linux-f2fs-devel@lists.sourceforge.net \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nzzhao@126.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.