The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Daniel Vacek <neelx@suse.com>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: remove extent buffer's redundant `len` member field
Date: Wed, 30 Apr 2025 08:04:39 +0930	[thread overview]
Message-ID: <ceaa0748-4190-4f0f-aca9-688ae1c7bfc3@gmx.com> (raw)
In-Reply-To: <20250429151800.649010-1-neelx@suse.com>



在 2025/4/30 00:47, Daniel Vacek 写道:
> Even super block nowadays uses nodesize for eb->len. This is since commits
> 
> 551561c34663 ("btrfs: don't pass nodesize to __alloc_extent_buffer()")
> da17066c4047 ("btrfs: pull node/sector/stripe sizes out of root and into fs_info")
> ce3e69847e3e ("btrfs: sink parameter len to alloc_extent_buffer")
> a83fffb75d09 ("btrfs: sink blocksize parameter to btrfs_find_create_tree_block")
> 
> With these the eb->len is not really useful anymore. Let's use the nodesize
> directly where applicable.

The idea looks great to me, and all the call sites look good too.

> 
> Signed-off-by: Daniel Vacek <neelx@suse.com>
> ---
> [RFC]
>   * Shall the eb_len() helper better be called eb_nodesize()? Or even rather
>     opencoded and not used at all?

However the name eb_len() is a little too generic.

Nodesize is a little easier to understand.

> 
>   fs/btrfs/accessors.c             |  4 +--
>   fs/btrfs/disk-io.c               | 11 ++++---
>   fs/btrfs/extent-tree.c           | 28 +++++++++--------
>   fs/btrfs/extent_io.c             | 54 ++++++++++++++------------------
>   fs/btrfs/extent_io.h             | 11 +++++--
>   fs/btrfs/ioctl.c                 |  2 +-
>   fs/btrfs/relocation.c            |  2 +-
>   fs/btrfs/subpage.c               |  8 ++---
>   fs/btrfs/tests/extent-io-tests.c | 12 +++----
>   fs/btrfs/zoned.c                 |  2 +-
>   10 files changed, 67 insertions(+), 67 deletions(-)
> 
> diff --git a/fs/btrfs/accessors.c b/fs/btrfs/accessors.c
> index e3716516ca387..a2bdbc7990906 100644
> --- a/fs/btrfs/accessors.c
> +++ b/fs/btrfs/accessors.c
> @@ -14,10 +14,10 @@ static bool check_setget_bounds(const struct extent_buffer *eb,
>   {
>   	const unsigned long member_offset = (unsigned long)ptr + off;
>   
> -	if (unlikely(member_offset + size > eb->len)) {
> +	if (unlikely(member_offset + size > eb_len(eb))) {
>   		btrfs_warn(eb->fs_info,
>   		"bad eb member %s: ptr 0x%lx start %llu member offset %lu size %d",
> -			(member_offset > eb->len ? "start" : "end"),
> +			(member_offset > eb_len(eb) ? "start" : "end"),
>   			(unsigned long)ptr, eb->start, member_offset, size);
>   		return false;
>   	}
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 3592300ae3e2e..31eb7419fe11f 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -190,7 +190,7 @@ static int btrfs_repair_eb_io_failure(const struct extent_buffer *eb,
>   	for (int i = 0; i < num_extent_folios(eb); i++) {
>   		struct folio *folio = eb->folios[i];
>   		u64 start = max_t(u64, eb->start, folio_pos(folio));
> -		u64 end = min_t(u64, eb->start + eb->len,
> +		u64 end = min_t(u64, eb->start + fs_info->nodesize,
>   				folio_pos(folio) + eb->folio_size);
>   		u32 len = end - start;
>   		phys_addr_t paddr = PFN_PHYS(folio_pfn(folio)) +
> @@ -230,7 +230,7 @@ int btrfs_read_extent_buffer(struct extent_buffer *eb,
>   			break;
>   
>   		num_copies = btrfs_num_copies(fs_info,
> -					      eb->start, eb->len);
> +					      eb->start, fs_info->nodesize);
>   		if (num_copies == 1)
>   			break;
>   
> @@ -260,6 +260,7 @@ blk_status_t btree_csum_one_bio(struct btrfs_bio *bbio)
>   {
>   	struct extent_buffer *eb = bbio->private;
>   	struct btrfs_fs_info *fs_info = eb->fs_info;
> +	u32 nodesize = fs_info->nodesize;

Minor nitpick, @nodesize can be made const.

Otherwise looks good to me.

Thanks,
Qu

  reply	other threads:[~2025-04-29 22:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29 15:17 [PATCH] btrfs: remove extent buffer's redundant `len` member field Daniel Vacek
2025-04-29 22:34 ` Qu Wenruo [this message]
2025-04-30  8:03 ` David Sterba
2025-04-30  8:21   ` Daniel Vacek
2025-04-30 12:31     ` Daniel Vacek
2025-05-02 10:30       ` David Sterba
2025-05-02 11:23         ` Daniel Vacek
2025-04-30 13:30     ` David Sterba
2025-04-30 14:13       ` Daniel Vacek
2025-05-02 10:56         ` David Sterba
2025-05-02 12:03           ` Daniel Vacek
2025-05-05 14:10             ` David Sterba
2025-05-05 16:19               ` Daniel Vacek
2025-04-30  8:05 ` Filipe Manana
2025-04-30  8:26   ` Daniel Vacek
2025-04-30  8:34     ` Filipe Manana
2025-04-30  8:50       ` Daniel Vacek
2025-04-30 10:26         ` Filipe Manana
2025-04-30 11:09           ` Johannes Thumshirn
2025-04-30 12:09             ` Daniel Vacek
2025-04-30 12:06           ` Daniel Vacek
2025-04-30 12:33             ` Filipe Manana
2025-04-30 12:53               ` Daniel Vacek
2025-05-02 13:37 ` [PATCH v2 0/2] btrfs: eb struct cleanups Daniel Vacek
2025-05-02 13:37   ` [PATCH v2 1/2] btrfs: remove extent buffer's redundant `len` member field Daniel Vacek
2025-05-02 17:35     ` Boris Burkov
2025-05-05  8:23       ` Daniel Vacek
2025-05-05 11:50     ` [PATCH v3 0/2] btrfs: eb struct cleanups Daniel Vacek
2025-05-05 11:50       ` [PATCH v3 1/2] btrfs: remove extent buffer's redundant `len` member field Daniel Vacek
2025-05-05 15:18         ` David Sterba
2025-05-05 17:53           ` Daniel Vacek
2025-05-13  0:32             ` David Sterba
2025-05-13 10:43               ` Daniel Vacek
2025-05-05 11:50       ` [PATCH v3 2/2] btrfs: rearrange the extent buffer structure members Daniel Vacek
2025-05-02 13:37   ` [PATCH v2 " Daniel Vacek

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=ceaa0748-4190-4f0f-aca9-688ae1c7bfc3@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neelx@suse.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