All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: fix and simplify the inline extent decompression path for subpage
Date: Mon,  8 Jan 2024 19:38:43 +1030	[thread overview]
Message-ID: <cover.1704704328.git.wqu@suse.com> (raw)

There is a long existing bug in subpage inline extent reflinking to
another location.

The bug is caused by an existing bad code, which is from the beginning
of btrfs.
The bad code is never properly explained and got further copied into new
compression code.

The bad condition never got properly triggered by different reasons for
different platforms:

- On 4K page sized system, the @start_byte is always 0
  Thus the existing checks are all dead code, thus never triggered.

- For subpage (4K sectorsize 64K page size) cases, inline extent
  creation is disable for a different reason
  Since no inline extent can be created, there is no way to reflink
  any inlined extent thus no way to trigger it.

The fixes are mostly going to rework the decompression loop, making sure
the input and output buffer are always large enough for inline extent.
Thus no need for any loop, but a single decompression call.

But the difficulty lies in how to properly test the bug.
For now I'm only doing cross-platform tests, using image created on
x86_64, and do the reflink on aarch64.
Not sure if it's possible to upload a binary image for fstests, or I
don't have any good way to test the bug.

Qu Wenruo (3):
  btrfs: zlib: fix and simplify the inline extent decompression
  btrfs: lzo: fix and simplify the inline extent decompression
  btrfs: zstd: fix and simplify the inline extent decompression

 fs/btrfs/compression.c | 23 +++++++++----
 fs/btrfs/compression.h |  6 ++--
 fs/btrfs/lzo.c         | 34 +++++--------------
 fs/btrfs/super.h       |  3 ++
 fs/btrfs/zlib.c        | 73 +++++++++++------------------------------
 fs/btrfs/zstd.c        | 74 +++++++++++++-----------------------------
 6 files changed, 72 insertions(+), 141 deletions(-)

-- 
2.43.0


             reply	other threads:[~2024-01-08  9:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08  9:08 Qu Wenruo [this message]
2024-01-08  9:08 ` [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression Qu Wenruo
2024-01-09  3:02   ` kernel test robot
2024-01-10  1:59     ` David Sterba
2024-01-10  2:03       ` Qu Wenruo
2024-01-10  2:26         ` David Sterba
2024-01-10  2:34           ` Qu Wenruo
2024-01-10  2:42             ` David Sterba
2024-01-08  9:08 ` [PATCH 2/3] btrfs: lzo: " Qu Wenruo
2024-01-08  9:08 ` [PATCH 3/3] btrfs: zstd: " Qu Wenruo
2024-01-10  3:29 ` [PATCH 0/3] btrfs: fix and simplify the inline extent decompression path for subpage David Sterba
2024-01-10  4:18   ` 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.1704704328.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 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.