public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/7] btrfs: introduce seperate structure to avoid
Date: Fri, 26 Dec 2025 15:42:46 +1030	[thread overview]
Message-ID: <cover.1766725912.git.wqu@suse.com> (raw)

The structure btrfs_file_extent_item is defined that if one file extent
is inlined, the data starts after btrfs_file_extent_item::type, aka,
overlapping with btrfs_file_extent_item::disk_bytenr and other members.

This makes it harder to understand btrfs on-disk format.

This also requires every user of btrfs_file_extent_item::disk_bytenr and
other non-inline members to check btrfs_file_extent_item::type first.

But not all callers are strictly following that, and when
access-beyond-boundary happens, we have no built-in checks to catch
them.

This series address the problem by:

- Introduce btrfs_file_header structure to define the shared part
  Initially I'm planning to use ms-extension to define an unnamed
  structure inside btrfs_file_extent_item, to avoid duplicated
  definition, but it doesn't work for arm64.

  So have to do duplicated definition.

- Introduce btrfs_file_header_*() helpers for the shared members

- Introduce btrfs_file_header_disk_bytenr() for btrfs_file_extent_item
  This allows using the same btrfs_file_header pointer to access the
  btrfs_file_extent_item exclusive members, with built-in ASSERT() to
  catch incorrect types.

- Convert existing btrfs_file_extent_item pointer users to
  btrfs_file_header
  This also reduce the lifespan of those pointers to minimal,
  e.g. only define them in the minimal scope, even if it means to define
  such pointer again and again in different scopes.

  There are some exceptions:

  * On-stack ones are still using btrfs_file_extent_item

  * Certain write paths are still using btrfs_file_extent_item pointer
    Those sites are known to handling non-inlined extents, thus
    can still use the old pointer, but not recommended anymore.

Qu Wenruo (7):
  btrfs: introduce btrfs_file_header structure
  btrfs: use btrfs_file_header structure for tree-checker
  btrfs: use btrfs_file_header structure for trace events
  btrfs: use btrfs_file_header structure for inode.c
  btrfs: use btrfs_file_header structure for simple usages
  btrfs: use btrfs_file_header structure for file.c
  btrfs: use btrfs_file_header structure for send.c and tree-log.c

 fs/btrfs/accessors.h            |  79 +++++++++++++
 fs/btrfs/backref.c              |  36 +++---
 fs/btrfs/ctree.c                |  33 +++---
 fs/btrfs/defrag.c               |   8 +-
 fs/btrfs/extent-tree.c          |  26 ++--
 fs/btrfs/fiemap.c               |  30 ++---
 fs/btrfs/file-item.c            |  26 ++--
 fs/btrfs/file-item.h            |  23 ++--
 fs/btrfs/file.c                 | 204 ++++++++++++++++----------------
 fs/btrfs/inode-item.c           |  47 ++++----
 fs/btrfs/inode.c                | 151 ++++++++++++-----------
 fs/btrfs/print-tree.c           |  28 ++---
 fs/btrfs/qgroup.c               |  11 +-
 fs/btrfs/reflink.c              |  34 +++---
 fs/btrfs/relocation.c           |  42 +++----
 fs/btrfs/send.c                 | 145 +++++++++++------------
 fs/btrfs/tree-checker.c         |  82 ++++++-------
 fs/btrfs/tree-log.c             |  70 +++++------
 include/trace/events/btrfs.h    |  58 ++++-----
 include/uapi/linux/btrfs_tree.h |  61 ++++++----
 20 files changed, 643 insertions(+), 551 deletions(-)

-- 
2.52.0


             reply	other threads:[~2025-12-26  5:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-26  5:12 Qu Wenruo [this message]
2025-12-26  5:12 ` [PATCH 1/7] btrfs: introduce btrfs_file_header structure Qu Wenruo
2025-12-26  5:12 ` [PATCH 2/7] btrfs: use btrfs_file_header structure for tree-checker Qu Wenruo
2025-12-26  5:12 ` [PATCH 3/7] btrfs: use btrfs_file_header structure for trace events Qu Wenruo
2025-12-26  5:12 ` [PATCH 4/7] btrfs: use btrfs_file_header structure for inode.c Qu Wenruo
2025-12-26  5:12 ` [PATCH 5/7] btrfs: use btrfs_file_header structure for simple usages Qu Wenruo
2025-12-26  5:12 ` [PATCH 6/7] btrfs: use btrfs_file_header structure for file.c Qu Wenruo
2025-12-26  5:12 ` [PATCH 7/7] btrfs: use btrfs_file_header structure for send.c and tree-log.c Qu Wenruo
2026-01-18  2:37 ` [PATCH 0/7] btrfs: introduce seperate structure to avoid Qu Wenruo

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=cover.1766725912.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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