All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Naohiro Aota <naohiro.aota@wdc.com>, linux-btrfs@vger.kernel.org
Cc: wqu@suse.com, hch@lst.de
Subject: Re: [PATCH] btrfs: fix error propagation of split bios
Date: Thu, 10 Oct 2024 09:41:04 +1030	[thread overview]
Message-ID: <8f76a524-aa49-46b2-aa44-33f92fcd00a5@gmx.com> (raw)
In-Reply-To: <5c363f14-c3d3-4d5d-bc46-8b38d2bcd08e@gmx.com>



在 2024/10/10 08:28, Qu Wenruo 写道:
>
>
> 在 2024/10/10 08:08, Qu Wenruo 写道:
[...]
>> And __bi_remaining is only decreased when the cloned or the original bio
>> get its endio function called (bio_endio()).
>>
>> For cloned bios, it's mostly the same chained bio behavior, with extra
>> btrfs write tolerance added.
>
> OK, I see the point. For the cloned ones we can have the following case:
>
> The profile is DUP/RAID1.
>
> For stripe 0, we cloned the original bio, increased
> orig_bio->__bi_remaining.
>
> Then submitted the cloned bio.
>
> But before submitting the original one, cloned one get finished first,
> it call the cloned endio function, which calls back to the endio of the
> original bio.
>
> Then the endio function decrease the __bi_remaining to 0 of the original
> bio, thus it continue to call the endio of the original bio, which freed
> the original bio.

My bad, this is not possible.

The original bio will have 1 as __bi_remaining as the initial value.

So even if the cloned one is finished first, the __bi_remaining will
only stay at 1, not reaching 0, so the original bio will not finish,
thus impossible to free the original bio.

I need to dig further deeper to find out why the NULL pointer
dereference happens.

Thanks,
Qu

  reply	other threads:[~2024-10-09 23:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 15:57 [PATCH] btrfs: fix error propagation of split bios Naohiro Aota
2024-10-09 16:59 ` David Sterba
2024-10-10  5:51   ` Naohiro Aota
2024-10-10 11:02     ` David Sterba
2024-10-09 21:38 ` Qu Wenruo
2024-10-09 21:40   ` Qu Wenruo
2024-10-09 21:58   ` Qu Wenruo
2024-10-09 23:11     ` Qu Wenruo [this message]
2024-10-10  7:06       ` Christoph Hellwig
2024-10-10  8:53         ` Naohiro Aota
2024-10-10  9:45           ` hch
2024-10-12  6:12 ` kernel test robot

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=8f76a524-aa49-46b2-aa44-33f92fcd00a5@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=hch@lst.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    --cc=wqu@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 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.