public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Cebtenzzre <cebtenzzre@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: while (1) in btrfs_relocate_block_group didn't end
Date: Sat, 28 Sep 2019 14:36:04 -0400	[thread overview]
Message-ID: <d19eb085373417fb13f5ec3c634224ecefa9dca2.camel@gmail.com> (raw)
In-Reply-To: <6476e5f02a4bdf26c8f342db11f6dc1675c94394.camel@gmail.com>

On Mon, 2019-09-16 at 17:20 -0400, Cebtenzzre wrote:
> On Sat, 2019-09-14 at 17:36 -0400, Cebtenzzre wrote:
> > Hi,
> > 
> > I started a balance of one block group, and I saw this in dmesg:
> > 
> > BTRFS info (device sdi1): balance: start -dvrange=2236714319872..2236714319873
> > BTRFS info (device sdi1): relocating block group 2236714319872 flags data|raid0
> > BTRFS info (device sdi1): found 1 extents
> > BTRFS info (device sdi1): found 1 extents
> > BTRFS info (device sdi1): found 1 extents
> > BTRFS info (device sdi1): found 1 extents
> > BTRFS info (device sdi1): found 1 extents
> > 
> > [...]
> > 
> > I am using Arch Linux with kernel version 5.2.14-arch2, and I specified
> > "slub_debug=P,kmalloc-2k" in the kernel cmdline to detect and protect
> > against a use-after-free that I found when I had KASAN enabled. Would
> > that kernel parameter result in a silent retry if it hit the use-after-
> > free?
> 
> Please disregard the quoted message. This behavior does appear to be a
> result of using the slub_debug option instead of KASAN. It is not
> directly caused by BTRFS.

Actually, I just reproduced this behavior without slub_debug in the
cmdline, on Linux 5.3.0 with "[PATCH] btrfs: relocation: Fix KASAN
report about use-after-free due to dead reloc tree cleanup race" (
https://patchwork.kernel.org/patch/11153729/) applied.

So, this issue is still relevant and possible to trigger, though under
different conditions (different volume, kernel version, and cmdline).
-- 
Cebtenzzre <cebtenzzre@gmail.com>


  reply	other threads:[~2019-09-28 18:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-14 21:36 while (1) in btrfs_relocate_block_group didn't end Cebtenzzre
2019-09-16 21:20 ` Cebtenzzre
2019-09-28 18:36   ` Cebtenzzre [this message]
2019-09-28 23:37     ` Qu Wenruo
2019-10-04 13:51       ` Cebtenzzre

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=d19eb085373417fb13f5ec3c634224ecefa9dca2.camel@gmail.com \
    --to=cebtenzzre@gmail.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