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 <cebtenz...@gmail.com>
