Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: [PATCH 01/17] btrfs: fix file_offset for REQ_BTRFS_ONE_ORDERED bios that get split
Date: Wed, 31 May 2023 09:53:54 +0200	[thread overview]
Message-ID: <20230531075410.480499-2-hch@lst.de> (raw)
In-Reply-To: <20230531075410.480499-1-hch@lst.de>

If a bio gets split, it needs to have a proper file_offset for checksum
validation and repair to work properly.

Based on feedback from Josef, commit 852eee62d31a ("btrfs: allow
btrfs_submit_bio to split bios") skipped this adjustment for ONE_ORDERED
bios.  But if we actually ever need to split a ONE_ORDERED read bio, this
will lead to a wrong file offset in the repair code.  Right now the only
user of the file_offset is logging of an error message so this is mostly
harmless, but the wrong offset might be more problematic for additional
users in the future.

Fixes: 852eee62d31a ("btrfs: allow btrfs_submit_bio to split bios")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
---
 fs/btrfs/bio.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c
index ae6345668d2d01..42c0ded42fafe5 100644
--- a/fs/btrfs/bio.c
+++ b/fs/btrfs/bio.c
@@ -81,8 +81,7 @@ static struct btrfs_bio *btrfs_split_bio(struct btrfs_fs_info *fs_info,
 	btrfs_bio_init(bbio, fs_info, NULL, orig_bbio);
 	bbio->inode = orig_bbio->inode;
 	bbio->file_offset = orig_bbio->file_offset;
-	if (!(orig_bbio->bio.bi_opf & REQ_BTRFS_ONE_ORDERED))
-		orig_bbio->file_offset += map_length;
+	orig_bbio->file_offset += map_length;
 
 	atomic_inc(&orig_bbio->pending_ios);
 	return bbio;
-- 
2.39.2


  reply	other threads:[~2023-05-31  7:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-31  7:53 add an ordered_extent pointer to struct btrfs_bio v2 Christoph Hellwig
2023-05-31  7:53 ` Christoph Hellwig [this message]
2023-05-31  7:53 ` [PATCH 02/17] btrfs: limit write bios to a single ordered extent Christoph Hellwig
2023-05-31  7:53 ` [PATCH 03/17] btrfs: merge the two calls to btrfs_add_ordered_extent in run_delalloc_nocow Christoph Hellwig
2023-06-01 12:17   ` Johannes Thumshirn
2023-05-31  7:53 ` [PATCH 04/17] btrfs: pass an ordered_extent to btrfs_reloc_clone_csums Christoph Hellwig
2023-05-31  7:53 ` [PATCH 05/17] btrfs: pass an ordered_extent to btrfs_submit_compressed_write Christoph Hellwig
2023-05-31  7:53 ` [PATCH 06/17] btrfs: remove btrfs_add_ordered_extent Christoph Hellwig
2023-05-31  7:54 ` [PATCH 07/17] btrfs: add a is_data_bbio helper Christoph Hellwig
2023-06-01 11:50   ` Johannes Thumshirn
2023-05-31  7:54 ` [PATCH 08/17] btrfs: open code btrfs_bio_end_io in btrfs_dio_submit_io Christoph Hellwig
2023-05-31  7:54 ` [PATCH 09/17] btrfs: add an ordered_extent pointer to struct btrfs_bio Christoph Hellwig
2023-05-31  7:54 ` [PATCH 10/17] btrfs: use bbio->ordered in btrfs_csum_one_bio Christoph Hellwig
2023-05-31  7:54 ` [PATCH 11/17] btrfs: factor out a can_finish_ordered_extent helper Christoph Hellwig
2023-05-31  7:54 ` [PATCH 12/17] btrfs: factor out a btrfs_queue_ordered_fn helper Christoph Hellwig
2023-05-31  7:54 ` [PATCH 13/17] btrfs: add a btrfs_finish_ordered_extent helper Christoph Hellwig
2023-06-01 11:50   ` Johannes Thumshirn
2023-05-31  7:54 ` [PATCH 14/17] btrfs: open code end_extent_writepage in end_bio_extent_writepage Christoph Hellwig
2023-05-31  7:54 ` [PATCH 15/17] btrfs: use btrfs_finish_ordered_extent to complete compressed writes Christoph Hellwig
2023-05-31  7:54 ` [PATCH 16/17] btrfs: use btrfs_finish_ordered_extent to complete direct writes Christoph Hellwig
2023-05-31  7:54 ` [PATCH 17/17] btrfs: use btrfs_finish_ordered_extent to complete buffered writes Christoph Hellwig
2023-05-31 16:33 ` add an ordered_extent pointer to struct btrfs_bio v2 Josef Bacik
2023-06-12 13:57 ` David Sterba

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=20230531075410.480499-2-hch@lst.de \
    --to=hch@lst.de \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=josef@toxicpanda.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