Re: [PATCH] btrfs-progs: mark BUG() as unreachable

On Thu, Apr 01, 2021 at 05:41:00PM +0900, Naohiro Aota wrote: > Marking BUG() unreachable helps us silence unnecessary warnings e.g. > "warning: control reaches end of non-void function [-Wreturn-type]" like > the code below. > >int foo() >

Re: [PATCH] btrfs-progs: utils: fix btrfs_wipe_existing_sb probe bug

On Fri, Apr 9, 2021 at 12:32 PM Wang Yugui wrote: > > Hi, > > > btrfs_wipe_existing_sb() misses calling blkid_do_fullprobe() to do > > the real probe. After calling blkid_new_probe() & > > blkid_probe_set_device() to setup blkid_probe context, it directly > > calls blkid_probe_lookup_value(). This

Re: [PATCH] btrfs-progs: utils: fix btrfs_wipe_existing_sb probe bug

Hi, > btrfs_wipe_existing_sb() misses calling blkid_do_fullprobe() to do > the real probe. After calling blkid_new_probe() & > blkid_probe_set_device() to setup blkid_probe context, it directly > calls blkid_probe_lookup_value(). This results in > blkid_probe_lookup_value returning -1, because pr-

Re: kernel BUG at fs/btrfs/tree-mod-log.c:675 - misc-next 9228ad80f849 (Mar 29 2021)

On Mon, Apr 05, 2021 at 12:19:46PM +0100, Filipe Manana wrote: > On Sun, Apr 4, 2021 at 5:16 AM Zygo Blaxell > wrote: > > > > Base kernel is 9228ad80f849 "btrfs: zoned: move log tree node allocation > > out of log_root_tree->log_mutex" from misc-next on 2021-0

Re: kernel BUG at fs/btrfs/tree-mod-log.c:675 - misc-next 9228ad80f849 (Mar 29 2021)

On Sun, Apr 4, 2021 at 5:16 AM Zygo Blaxell wrote: > > Base kernel is 9228ad80f849 "btrfs: zoned: move log tree node allocation > out of log_root_tree->log_mutex" from misc-next on 2021-03-29. > > The BUG() moved, but we are still hitting it: > > [145427.

kernel BUG at fs/btrfs/tree-mod-log.c:675 - misc-next 9228ad80f849 (Mar 29 2021)

Base kernel is 9228ad80f849 "btrfs: zoned: move log tree node allocation out of log_root_tree->log_mutex" from misc-next on 2021-03-29. The BUG() moved, but we are still hitting it: [145427.426011][ T5492] BTRFS info (device dm-0): balance: canceled [145427.6

[PATCH] btrfs-progs: mark BUG() as unreachable

Marking BUG() unreachable helps us silence unnecessary warnings e.g. "warning: control reaches end of non-void function [-Wreturn-type]" like the code below. int foo() { ... if (XXX) return 0; else if (YYY) return 1;

[PATCH] btrfs-progs: utils: fix btrfs_wipe_existing_sb probe bug

btrfs_wipe_existing_sb() misses calling blkid_do_fullprobe() to do the real probe. After calling blkid_new_probe() & blkid_probe_set_device() to setup blkid_probe context, it directly calls blkid_probe_lookup_value(). This results in blkid_probe_lookup_value returning -1, because pr->values is empt

Re: kernel 5.11.x: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281

the default in any > case?), but I’m subsequently seeing very frequent BUGs being output by the > kernel: > > [ 821.843637] BUG: sleeping function called from invalid context at > kernel/locking/mutex.c:281 > [ 821.843641] in_atomic(): 1, irqs_disabled(): 0, non_b

kernel 5.11.x: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281

output by the kernel: [ 821.843637] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 821.843641] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 28214, name: podman [ 821.843644] CPU: 3 PID: 28214 Comm: podman Tainted: GW 5.11.6 #15

Re: [PATCH 0/9] btrfs: bug fixes for the tree mod log and small refactorings

On Thu, Mar 11, 2021 at 02:31:04PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > This patchset fixes a couple bugs, in the two first patches, with the tree > mod log code. The remaining patches just move all that code into a separate > file, since it's quite large and ctree.c is hug

Re: misc-next a646ddc2bba2: kernel BUG at fs/btrfs/ctree.c:1210! tree mod log

[40422.398920][T28995] BTRFS info (device dm-0): balance: > > > > > canceled > > > > > [40607.394003][T11577] BTRFS info (device dm-0): balance: > > > > > start -dlimit=9 > > > > > [40607.398597][T11577] BTRFS info (de

[PATCH 0/9] btrfs: bug fixes for the tree mod log and small refactorings

From: Filipe Manana This patchset fixes a couple bugs, in the two first patches, with the tree mod log code. The remaining patches just move all that code into a separate file, since it's quite large and ctree.c is huge as well, and do some small refactorings and cleanups. One of the bugs in par

Re: misc-next a646ddc2bba2: kernel BUG at fs/btrfs/ctree.c:1210! tree mod log

; > > > block group 315676950528 flags data > > > > [40643.279661][T11577] BTRFS info (device dm-0): found 12686 > > > > extents, loops 1, stage: move data extents > > > > [40692.752695][T11577] BTRFS info (device dm-0): found 12686 >

possible documentation bug[s]?

Hi all. *Long*-time Linux kernel hacker here, long-time storage-and-filesystems geek, new-ish to Btrfs. A few weeks ago I noticed some apparent intra-row conflicts [between "Size" and "Type" values] in the table at , so I

Re: misc-next a646ddc2bba2: kernel BUG at fs/btrfs/ctree.c:1210! tree mod log

, loops 1, stage: move data extents > > > [40692.752695][T11577] BTRFS info (device dm-0): found 12686 > > > extents, loops 2, stage: update data pointers > > > [40704.860522][T11577] BTRFS info (device dm-0): relocating block > > > group 314603208704 flag

Re: misc-next a646ddc2bba2: kernel BUG at fs/btrfs/ctree.c:1210! tree mod log

T11577] BTRFS info (device dm-0): relocating block > > group 314603208704 flags data > > [40704.919977][T19054] [ cut here ] > > [40704.921895][T19054] kernel BUG at fs/btrfs/ctree.c:1210! > > [40704.923497][T19054] invalid o

Re: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

On Tue, Mar 02, 2021 at 10:27:28AM +, Johannes Thumshirn wrote: > I've just tripped over this lockdep splat on v5.12-rc1 (Linus' tree not > misc-next), > while investigating a different bug report. > > > [ 1250.721882] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

Re: misc-next a646ddc2bba2: kernel BUG at fs/btrfs/ctree.c:1210! tree mod log

[40692.752695][T11577] BTRFS info (device dm-0): found 12686 extents, > loops 2, stage: update data pointers > [40704.860522][T11577] BTRFS info (device dm-0): relocating block > group 314603208704 flags data > [40704.919977][T19054] [ cut here ]

BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

I've just tripped over this lockdep splat on v5.12-rc1 (Linus' tree not misc-next), while investigating a different bug report. [ 1250.721882] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! [ 1250.722641] turning off the locking correctness validator. [ 1250.723486] CPU: 0 PID: 468 Comm: fs

misc-next a646ddc2bba2: kernel BUG at fs/btrfs/ctree.c:1210! tree mod log

[40704.919977][T19054] [ cut here ] [40704.921895][T19054] kernel BUG at fs/btrfs/ctree.c:1210! [40704.923497][T19054] invalid opcode: [#1] SMP KASAN PTI [40704.925549][T19054] CPU: 1 PID: 19054 Comm: crawl_335 Tainted: G W 5.11.0

Re: [PATCH] btrfs-progs: receive: fix btrfs_mount_root substring bug

On Mon, Nov 16, 2020 at 04:58:20PM -0800, Boris Burkov wrote: > The current mount detection code in btrfs receive is not quite perfect. > For example, suppose /tmp is mounted as a tmpfs. In that case, > btrfs receive /tmp2 will find /tmp as the longest mount that matches a > prefix of /tmp2 and blo

Re: [bug report] Unable to handle kernel paging request

On 2021/2/2 下午9:37, Anand Jain wrote: It is much simpler to reproduce. I am using two systems with different pagesizes to test the subpage readonly support. On a host with pagesize = 4k.   truncate -s 3g 3g.img   mkfs.btrfs ./3g.img   mount -o loop,compress=zstd ./3g.img /btrfs   xfs_io

Re: [bug report] btrfs: mark block groups to copy for device-replace

On 03/02/2021 09:57, Dan Carpenter wrote: > Hello Naohiro Aota, > > The patch 0d57e73ac5ae: "btrfs: mark block groups to copy for > device-replace" from Jan 26, 2021, leads to the following static > checker warning: > > fs/btrfs/dev-replace.c:505 mark_block_group_to_copy() > error: do

[bug report] btrfs: mark block groups to copy for device-replace

Hello Naohiro Aota, The patch 0d57e73ac5ae: "btrfs: mark block groups to copy for device-replace" from Jan 26, 2021, leads to the following static checker warning: fs/btrfs/dev-replace.c:505 mark_block_group_to_copy() error: double unlocked '&fs_info->trans_lock' (orig line 486)

[BUG] remove_from_free_space_tree error

5 disk raid1 created with Linux 3.18 once upon a time. Most disks have been replaced through the years and I was about to replace yet another one with a couple of bad blocks. Running Linux 5.10.0-2-amd64 #1 SMP Debian 5.10.9-1 (2021-01-20) x86_64 GNU/Linux. Same problem with Debian 5.9.15-1 (2020-

Re: [bug report] Unable to handle kernel paging request

It is much simpler to reproduce. I am using two systems with different pagesizes to test the subpage readonly support. On a host with pagesize = 4k. truncate -s 3g 3g.img mkfs.btrfs ./3g.img mount -o loop,compress=zstd ./3g.img /btrfs xfs_io -f -c "pwrite -S 0xab 0 128k" /btrfs/foo u

Re: [bug report] Unable to handle kernel paging request

On 2/2/2021 6:23 PM, Qu Wenruo wrote: On 2021/2/2 下午5:21, Anand Jain wrote: Qu,   fstests ran fine on an aarch64 kvm with this patch set. Do you mean subpage patchset? With 4K sector size? No way it can run fine... No . fstests ran with sectorsize == pagesize == 64k. These aren't s

Re: [bug report] Unable to handle kernel paging request

On 2021/2/2 下午5:21, Anand Jain wrote: Qu,  fstests ran fine on an aarch64 kvm with this patch set. Do you mean subpage patchset? With 4K sector size? No way it can run fine... Long enough fsstress can crash the kernel with btrfs_csum_one_bio() unable to locate the corresponding ordered

[bug report] Unable to handle kernel paging request

Qu, fstests ran fine on an aarch64 kvm with this patch set. Further, I was running few hand tests as below, and it fails with - Unable to handle kernel paging. Test case looks something like.. On x86_64 create btrfs on a file 11g copy /usr into /test-mnt stops at enospc set compressio

Re: [bug report] btrfs: introduce read_extent_buffer_subpage()

On 2021/1/28 下午7:06, Qu Wenruo wrote: On 2021/1/28 下午6:50, Dan Carpenter wrote: Hello Qu Wenruo, The patch 5c60a522f1ea: "btrfs: introduce read_extent_buffer_subpage()" from Jan 16, 2021, leads to the following static checker warning: fs/btrfs/extent_io.c:5797 read_extent_buffer_subpag

Re: [bug report] btrfs: introduce read_extent_buffer_subpage()

On 2021/1/28 下午6:50, Dan Carpenter wrote: Hello Qu Wenruo, The patch 5c60a522f1ea: "btrfs: introduce read_extent_buffer_subpage()" from Jan 16, 2021, leads to the following static checker warning: fs/btrfs/extent_io.c:5797 read_extent_buffer_subpage() info: return a literal i

Re: [PATCH] btrfs: fix a bug that btrfs_invalidapge() can double account ordered extent for subpage

for subpage case, as > >> for regular sectorsize == PAGE_SIZE case, we will always find a OE ends > >> at or after page end, thus no way to trigger the problem. > >> > >> This patch will move the again label after start = page_start, to fix > >> the bug. &g

[bug report] btrfs: introduce read_extent_buffer_subpage()

Hello Qu Wenruo, The patch 5c60a522f1ea: "btrfs: introduce read_extent_buffer_subpage()" from Jan 16, 2021, leads to the following static checker warning: fs/btrfs/extent_io.c:5797 read_extent_buffer_subpage() info: return a literal instead of 'ret' fs/btrfs/extent_io.c 5780 s

Re: [PATCH] btrfs: fix a bug that btrfs_invalidapge() can double account ordered extent for subpage

== PAGE_SIZE case, we will always find a OE ends at or after page end, thus no way to trigger the problem. This patch will move the again label after start = page_start, to fix the bug. This is just a quick fix, which is easy to backport. Hum? Why does it need to be backported? There are no ke

Re: [PATCH] btrfs: fix a bug that btrfs_invalidapge() can double account ordered extent for subpage

te_left to > underflow. > > The only good news is, this problem can only happen for subpage case, as > for regular sectorsize == PAGE_SIZE case, we will always find a OE ends > at or after page end, thus no way to trigger the problem. > > This patch will move the again label after st

[PATCH] btrfs: fix a bug that btrfs_invalidapge() can double account ordered extent for subpage

his patch will move the again label after start = page_start, to fix the bug. This is just a quick fix, which is easy to backport. There will be more comprehensive rework to convert the open coded loop to a proper while loop. Fixes: dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could

Re: kernel BUG at fs/btrfs/relocation.c:3494

On 23/01/2021 23:57, Zygo Blaxell wrote: You don't have enough space to convert metadata yet, and you also don't have enough space to lock one of your 3 metadata block groups without running out of global reserve space, so this balance command forces the filesystem read-only due to lack of space.

[PATCH 0/2] btrfs: a couple bug fixes for failures of log replay and mount

From: Filipe Manana This small patchset fixes two bugs that lead to an -EINVAL failure during log replay, causing the filesystem mount to fail. They are relatively new regressions, one caused by the recent change to make space cache loading asynchronous and the other caused by the refactoring tha

Re: [bug] Balance fails due to ENOSPC

On 2021/1/12 下午6:35, Anand Jain wrote: Balance fails due to ENOSPC on 5.11.0-rc2+. [ 2460.219094] BTRFS info (device sdb6): balance: start -f -dconvert=single -mconvert=single -sconvert=single [ 2460.219224] BTRFS info (device sdb6): relocating block group 194572713984 flags data [ 2460.24

[bug] Balance fails due to ENOSPC

Balance fails due to ENOSPC on 5.11.0-rc2+. [ 2460.219094] BTRFS info (device sdb6): balance: start -f -dconvert=single -mconvert=single -sconvert=single [ 2460.219224] BTRFS info (device sdb6): relocating block group 194572713984 flags data [ 2460.241299] [ cut here ]-

Re: [bug] scrub on low disk space leads to Transaction aborted

` output? There is a bug in recent kernel that global rsv is not increased properly so that we have a much higher chance to exhaust metadata space. Now I have made some space in the filesystem. So the usage below may not be relevant at the time of the problem. # btrfs fi usage /Volumes/ Overall

Re: [bug] scrub on low disk space leads to Transaction aborted

On 2021/1/9 下午4:53, Anand Jain wrote:  I ran scrub when disk space was low on a btrfs with some raid1 csum  errors, on a system with kernel 5.11.0-rc2+. It lead to transaction  aborted and rdonly FS. Would you please provide `btrfs fi usage` output? There is a bug in recent kernel

[bug] scrub on low disk space leads to Transaction aborted

I ran scrub when disk space was low on a btrfs with some raid1 csum errors, on a system with kernel 5.11.0-rc2+. It lead to transaction aborted and rdonly FS. [ 2365.314375] [ cut here ] [ 2365.314385] BTRFS: Transaction aborted (error -28) [ 2365.314470] WARNING: CPU

Re: [BUG] 500-2000% performance regression w/ 5.10

The problem is worse on SSD than on HDD. It actually makes the SSD *slower* than an HDD, on 5.10. For this workload HDD 5.9.16-200.fc33.x86_64 mq-deadline kyber [bfq] none $ time tar -xf /tmp/firefox-85.0b4.source.tar.xz && time sync real1m27.299s user0m27.294s sys0m14.134s real

Re: [BUG] 500-2000% performance regression w/ 5.10

Hey there, On 12/26/20 1:24 PM, Nikolay Borisov wrote: On 24.12.20 г. 23:11 ч., René Rebe wrote: Hi Josef, On 24. Dec 2020, at 19:09, Josef Bacik wrote: On 12/21/20 2:45 PM, René Rebe wrote: Hey there, as a long time btrfs user I noticed some some things became very slow w/ Linux kernel 5

Re: [BUG] 500-2000% performance regression w/ 5.10

On 24.12.20 г. 23:11 ч., René Rebe wrote: > Hi Josef, > >> On 24. Dec 2020, at 19:09, Josef Bacik wrote: >> >> On 12/21/20 2:45 PM, René Rebe wrote: >>> Hey there, >>> as a long time btrfs user I noticed some some things became very slow >>> w/ Linux kernel 5.10. I found a very simple test cas

Re: [BUG] 500-2000% performance regression w/ 5.10

On 24.12.20 г. 20:09 ч., Josef Bacik wrote: > On 12/21/20 2:45 PM, René Rebe wrote: >> Hey there, >> >> as a long time btrfs user I noticed some some things became very slow >> w/ Linux kernel 5.10. I found a very simple test case, namely extracting >> a huge tarball like: >> >>    tar xf /usr/s

Re: [BUG] 500-2000% performance regression w/ 5.10

Hi Josef, > On 24. Dec 2020, at 19:09, Josef Bacik wrote: > > On 12/21/20 2:45 PM, René Rebe wrote: >> Hey there, >> as a long time btrfs user I noticed some some things became very slow >> w/ Linux kernel 5.10. I found a very simple test case, namely extracting >> a huge tarball like: >> tar

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

o queue it seems. You can try compiling your test kernel with KASAN, as it often immediately points out where the memory starts to get corrupted (if that's the bug). Enabling other "checking" kernel debug options might help debugging the root case of this, too. Regards, Ignat Thanks, Maciej

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

_cpu_qlen set to 1) (decoded with stacktrace_decode.sh): [ 89.324723] BUG: kernel NULL pointer dereference, address: 0008 [ 89.325713] #PF: supervisor write access in kernel mode [ 89.326460] #PF: error_code(0x0002) - not-present page [ 89.327211] PGD 0 P4D 0 [ 89.327589] Oops: 0002 [#1] P

Re: [BUG] 500-2000% performance regression w/ 5.10

On 12/21/20 2:45 PM, René Rebe wrote: Hey there, as a long time btrfs user I noticed some some things became very slow w/ Linux kernel 5.10. I found a very simple test case, namely extracting a huge tarball like: tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst Why my

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On Wed, Dec 23, 2020 at 9:20 PM Maciej S. Szmigiero wrote: > > On 23.12.2020 22:09, Ignat Korchagin wrote: > (..) > > I've been looking into this for the last couple of days because of > > other reports [1]. > > Just finished testing a possible solution. Will submit soon. > > Thanks for looking in

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On 23.12.2020 22:09, Ignat Korchagin wrote: (..) I've been looking into this for the last couple of days because of other reports [1]. Just finished testing a possible solution. Will submit soon. Thanks for looking into it. By the way, on a bare metal I am actually hitting a different problem

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On Wed, Dec 23, 2020 at 3:37 PM Maciej S. Szmigiero wrote: > > On 14.12.2020 19:11, Maciej S. Szmigiero wrote: > > Hi, > > > > I hit a reproducible BUG() when scrubbing a btrfs fs on top of > > a dm-crypt device with no_read_workqueue and no_write_workqueue > >

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote: > > It looks like to me that the skcipher API might not be safe to > call from a softirq context, after all. skcipher is safe to use in a softirq. The problem is only in dm-crypt where it tries to allocate memory with GFP_NOIO.

Re: [BUG] 500-2000% performance regression w/ 5.10

On 12/23/20 3:31 PM, Holger Hoffstätte wrote: On 2020-12-23 20:41, Josef Bacik wrote: Could you give this a try?  I'm not able to reproduce the problem, but I'm Since I wanted to rule out NVME/block layer/scheduler etc. I tried and could reproduce it immediately, see below. Didn't notice it ea

Re: [BUG] 500-2000% performance regression w/ 5.10

On 2020-12-23 20:41, Josef Bacik wrote: Could you give this a try? I'm not able to reproduce the problem, but I'm Since I wanted to rule out NVME/block layer/scheduler etc. I tried and could reproduce it immediately, see below. Didn't notice it earlier since most of btrfs is read-mostly.. :(

Re: [BUG] 500-2000% performance regression w/ 5.10

Hello, Could you give this a try? I'm not able to reproduce the problem, but I'm testing inside of a VM. I'm in the middle of Christmas stuff, but I'll get ahold of a giant machine at work tomorrow and see if I can reproduce there. Meanwhile can you give this a shot? I have a sneaking suspicion

Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()

On 14.12.2020 19:11, Maciej S. Szmigiero wrote: Hi, I hit a reproducible BUG() when scrubbing a btrfs fs on top of a dm-crypt device with no_read_workqueue and no_write_workqueue flags enabled. Still happens on the current torvalds/master. Due to this bug it is not possible to use btrfs on

Re: [BUG] 500-2000% performance regression w/ 5.10

On 12/21/20 2:45 PM, René Rebe wrote: Hey there, as a long time btrfs user I noticed some some things became very slow w/ Linux kernel 5.10. I found a very simple test case, namely extracting a huge tarball like: tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst Why my

Re: [BUG] 500-2000% performance regression w/ 5.10

Dear Qu, On 12/22/20 9:28 AM, Qu Wenruo wrote: On 2020/12/22 上午3:45, René Rebe wrote: Hey there, as a long time btrfs user I noticed some some things became very slow w/ Linux kernel 5.10. I found a very simple test case, namely extracting a huge tarball like:    tar xf /usr/src/t2-clean/dow

Re: [BUG] 500-2000% performance regression w/ 5.10

On 2020/12/22 上午3:45, René Rebe wrote: Hey there, as a long time btrfs user I noticed some some things became very slow w/ Linux kernel 5.10. I found a very simple test case, namely extracting a huge tarball like: tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst Why

[BUG] 500-2000% performance regression w/ 5.10

Hey there, as a long time btrfs user I noticed some some things became very slow w/ Linux kernel 5.10. I found a very simple test case, namely extracting a huge tarball like: tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst Why my external, USB3 road-warrior SSD on a Ryze

[bug report] btrfs: do an allocation earlier during snapshot creation

[ Sorry David, the complain script uses git blame and it just picked you. And then I decided to keep the address because your email is still active and you seem like an expert. -dan ] Hello David Sterba, The patch a1ee73626844: "btrfs: do an allocation earlier during snapshot creation" from

[PATCH v3 0/2] btrfs: trim: Fix a bug certain range may not be trimmed properly

There is a bug report about discard mount option not trimming some range properly, and causing unexpected space usage for thin device. It turns out to be that, if there are pinned extents across block group boundary, we will only trim to the end of current block group, skipping the remaining

[PATCH v2 0/2] btrfs: trim: Fix a bug certain range may not be trimmed properly

There is a bug report about discard mount option not trimming some range properly, and causing unexpected space usage for thin device. It turns out to be that, if there are pinned extents across block group boundary, we will only trim to the end of current block group, skipping the remaining

[PATCH 0/2] btrfs: trim: Fix a bug certain range may not be trimmed properly

There is a bug report about discard mount option not trimming some range properly, and causing unexpected space usage for thin device. It turns out to be that, if there are pinned extents across block group boundary, we will only trim to the end of current block group, skipping the remaining

Re: "BUG: kernel NULL pointer dereference," when unmounting filesystem hitted by enospc error

On 21/10/2019 11:17, Johannes Thumshirn wrote: [...] >> - >> $ cat run-btrfs-test >> modprobe -iv zram num_devices=8 >> udevadm trigger >> sync >> zramctl /dev/zram0 -s 8G && \ >> zramctl /dev/zram1 -s 8G && \ >> zramctl /dev/zram2 -s 4G && \ >> zramctl /dev/zram3 -s 4G && \ >> zramctl /dev/zra

Re: "BUG: kernel NULL pointer dereference," when unmounting filesystem hitted by enospc error

On 19/10/2019 21:29, Peter Hjalmarsson wrote: Hi Peter, Thanks for the report. > While trying to reproduce another problem I have seen with BTRFS while > running balance and raid6 I hit an issue resulting in: > BUG: kernel NULL pointer dereference, address: 02ce > &

"BUG: kernel NULL pointer dereference," when unmounting filesystem hitted by enospc error

Hi, While trying to reproduce another problem I have seen with BTRFS while running balance and raid6 I hit an issue resulting in: BUG: kernel NULL pointer dereference, address: 02ce I created a script trying to pinpoint the problem utilizing zram, and the run goes like this: 1. run

Re: [PATCH v2 0/2] btrfs: qgroup: Bug fixes for trace events

On Thu, Oct 17, 2019 at 10:38:35AM +0800, Qu Wenruo wrote: > Several stupid bugs exposed for qgroup related trace events. > Fix them. Queued for 5.4-rc, thanks.

[PATCH v2 0/2] btrfs: qgroup: Bug fixes for trace events

Several stupid bugs exposed for qgroup related trace events. Fix them. Changelog: v2: - Split patches Qu Wenruo (2): btrfs: qgroup: Fix wrong parameter order for trace events btrfs: qgroup: Fix bad entry members of qgroup trace events fs/btrfs/qgroup.c| 4 ++-- include/trace/eve

Re: [bug] strange systemd-udevd scan for btrfs device

use appropriate ml for systemd bugs -systemd-b...@lists.freedesktop.org +systemd-de...@lists.freedesktop.org inline below.. On 10/2/19 9:33 PM, Andrei Borzenkov wrote: On Wed, Oct 2, 2019 at 1:19 PM Anand Jain wrote: On 10/2/19 6:02 PM, Anand Jain wrote: On 10/2/19 5:55 PM, Andrei Bor

Re: Btrfs: add a extent ref verify tool (static analysis bug report)

On Wed, Oct 02, 2019 at 02:50:51PM +0100, Colin Ian King wrote: > Hi, > > Static analysis on linux-next with Coverity has picked up a potential > issue in file fs/btrfs/ref-verify.c, function process_leaf() in the > following commit: > > commit fd708b81d972a0714b02a60eb4792fdbf15868c4 > Author: J

re: Btrfs: add a extent ref verify tool (static analysis bug report)

Hi, Static analysis on linux-next with Coverity has picked up a potential issue in file fs/btrfs/ref-verify.c, function process_leaf() in the following commit: commit fd708b81d972a0714b02a60eb4792fdbf15868c4 Author: Josef Bacik Date: Fri Sep 29 15:43:50 2017 -0400 Btrfs: add a extent ref

Re: [bug] strange systemd-udevd scan for btrfs device

On Wed, Oct 2, 2019 at 1:19 PM Anand Jain wrote: > > > > On 10/2/19 6:02 PM, Anand Jain wrote: > > > > > > On 10/2/19 5:55 PM, Andrei Borzenkov wrote: > >> On Wed, Oct 2, 2019 at 12:27 PM Anand Jain wrote: > >>> > >>> > >>> > >>> I am looking for systemd part of the answers to understand what > >

Re: [bug] strange systemd-udevd scan for btrfs device

On 10/2/19 6:02 PM, Anand Jain wrote: On 10/2/19 5:55 PM, Andrei Borzenkov wrote: On Wed, Oct 2, 2019 at 12:27 PM Anand Jain wrote: I am looking for systemd part of the answers to understand what is triggering a strange problem. Any help is appreciated. After mkfs.btrfs creates btrfs

Re: [bug] strange systemd-udevd scan for btrfs device

On 10/2/19 5:55 PM, Andrei Borzenkov wrote: On Wed, Oct 2, 2019 at 12:27 PM Anand Jain wrote: I am looking for systemd part of the answers to understand what is triggering a strange problem. Any help is appreciated. After mkfs.btrfs creates btrfs filesystem it scans to register the devic

Re: [bug] strange systemd-udevd scan for btrfs device

On Wed, Oct 2, 2019 at 12:27 PM Anand Jain wrote: > > > > I am looking for systemd part of the answers to understand what > is triggering a strange problem. Any help is appreciated. > > After mkfs.btrfs creates btrfs filesystem it scans to register the > device in btrfs.ko. > And we have 'btrfs de

[bug] strange systemd-udevd scan for btrfs device

I am looking for systemd part of the answers to understand what is triggering a strange problem. Any help is appreciated. After mkfs.btrfs creates btrfs filesystem it scans to register the device in btrfs.ko. And we have 'btrfs dev scan --forget' command to undo the process of register. But t

Re: BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2bf/0x330 [btrfs]

> 1433 int clear_rsv = 0; >> 1434 int ret; >> 1435 >> 1436 if (root->reloc_root) { >> 1437 reloc_root = root->reloc_root; >> 1438 reloc_root->last_trans = trans->transid; This should the correct

Re: BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2bf/0x330 [btrfs]

e buggy address belongs to the page: >>> [49294.094962] page:ea0016d24000 refcount:1 mapcount:0 >>> mapping:88864400e800 index:0x0 compound_mapcount: 0 >>> [49294.094968] flags: 0x2010200(slab|head) >>> [49294.094976] raw: 02010200 dead01

Re: BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2bf/0x330 [btrfs]

> > 2221681934336 flags data|raid0 > > [49294.092536] > > ====== > > [49294.092637] BUG: KASAN: use-after-free in > > btrfs_init_reloc_root+0x2bf/0x330 [btrfs] > > It would be much nicer if you could provide the code context by using > 1) gdb: >

Re: BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2bf/0x330 [btrfs]

info (device sdi1): balance: start > -dvrange=2221681934336..2221681934337 > [49286.515651] BTRFS info (device sdi1): relocating block group 2221681934336 > flags data|raid0 > [49294.092536] > ====== > [49294.0

BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2bf/0x330 [btrfs]

[49286.515651] BTRFS info (device sdi1): relocating block group 2221681934336 flags data|raid0 [49294.092536] == [49294.092637] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2bf/0x330 [btrfs] [49294.092645] Write of size 8 at addr

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

subsystem >>> EXT4-fs (loop1): mounted filesystem without journal. Opts: (null) >>> EXT4-fs (loop1): mounting ext3 file system using the ext4 subsystem >>> EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null) >>> EXT4-fs (loop1): mounted filesy

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

On Wed, 2019-09-11 at 11:09 +0300, Nikolay Borisov wrote: > > On 11.09.19 г. 11:00 ч., Abdul Haleem wrote: > > On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote: > >> > > > > >> corresponds to? > > > > btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751 > > write

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

On 11.09.19 г. 11:00 ч., Abdul Haleem wrote: > On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote: >> >> corresponds to? > > btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751 > write_lock_level = BTRFS_MAX_LEVEL; That doesn't make sense, presumably btrfs_sear

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

ystem with ordered data mode. Opts: (null) > > EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null) > > XFS (loop1): Mounting V5 Filesystem > > XFS (loop1): Ending clean mount > > XFS (loop1): Unmounting Filesystem > > BTRFS: device fsid 7c08f81b-6642-4a06

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote: > Greeting's > > Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file > system on my P9 box running mainline kernel 5.3.0-rc5 Is the issue reproducible? And if yes, how reliably? Thanks.

Re: Bug?: unlink cause btrfs error but other fs don't

On 9/4/19 6:48 PM, Josef Bacik wrote: On Wed, Sep 04, 2019 at 04:02:24PM +0800, Hongzhi, Song wrote: Hi , *Kernel:*     After v5.2-rc1, qemux86-64     make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc     use qemu to bootup kernel *Reproduce:*     There is a test case failed on btrfs b

Re: Bug?: unlink cause btrfs error but other fs don't

On Wed, Sep 04, 2019 at 04:02:24PM +0800, Hongzhi, Song wrote: > Hi , > > > *Kernel:* > >     After v5.2-rc1, qemux86-64 > >     make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc >     use qemu to bootup kernel > > > *Reproduce:* > >     There is a test case failed on btrfs but success on other

Re: Bug?: unlink cause btrfs error but other fs don't

Hi Nikolay, > There were multiple fixes from Josef recently improving btrfs enospc handling with tiny filesystems (which is generally not the targeted use case of btrfs). The code lives in https://github.com/kdave/btrfs-devel/commits/misc-next should you want to test it. Otherwise re-test after

Bug?: unlink cause btrfs error but other fs don't

Hi , *Kernel:*     After v5.2-rc1, qemux86-64     make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc     use qemu to bootup kernel *Reproduce:*     There is a test case failed on btrfs but success on other fs(ext4,ext3), see attachment.     Download attachments:         gcc test.c -o myout

Re: Bug Report: Btrfs can't allocate space for delete when block size arounds 512M

On 4.09.19 г. 5:36 ч., Hongzhi, Song wrote: > Anybody notice this? > There were multiple fixes from Josef recently improving btrfs enospc handling with tiny filesystems (which is generally not the targeted use case of btrfs). The code lives in https://github.com/kdave/btrfs-devel/commits/mis

Re: Bug Report: Btrfs can't allocate space for delete when block size arounds 512M

I remake the test case to be more simply. And the send the new email. Thanks, --Hongzhi On 9/4/19 10:36 AM, Hongzhi, Song wrote: Anybody notice this? --Hongzhi On 7/17/19 4:34 PM, Hongzhi, Song wrote: Hi friends, *Description:*     One LTP testcase, fs_fill.c, fails on btrfs with kern

Re: Bug Report: Btrfs can't allocate space for delete when block size arounds 512M

Anybody notice this? --Hongzhi On 7/17/19 4:34 PM, Hongzhi, Song wrote: Hi friends, *Description:*     One LTP testcase, fs_fill.c, fails on btrfs with kernel error when unlink files on Btrfs device:     "BTRFS warning (device loop0): could not allocate space for a delete; will truncate

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote: > Greeting's > > Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my > P9 box running mainline kernel 5.3.0-rc5 > > BUG_ON was first introduced by below commit Well, technically the bug_on was there already

Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!

dev/loop1 > BTRFS info (device loop1): disk space caching is enabled > BTRFS info (device loop1): has skinny extents > BTRFS info (device loop1): enabling ssd optimizations > BTRFS info (device loop1): creating UUID tree > [ cut here ] > kernel BUG at fs/btrfs/locking.c:7

  1   2   3   4   5   6   7   8   9   10   >