Re: [GIT PULL] bcachefs

[Kent Overstreet <kent.overstreet@linux.dev>]

On Mon, Jun 26, 2023 at 08:59:13PM -0600, Jens Axboe wrote:
> On 6/26/23 8:05?PM, Kent Overstreet wrote:
> > On Mon, Jun 26, 2023 at 07:13:54PM -0600, Jens Axboe wrote:
> >> Doesn't reproduce for me with XFS. The above ktest doesn't work for me
> >> either:
> > 
> > It just popped for me on xfs, but it took half an hour or so of looping
> > vs. 30 seconds on bcachefs.
> 
> OK, I'll try and leave it running overnight and see if I can get it to
> trigger.
> 
> >> ~/git/ktest/build-test-kernel run -ILP ~/git/ktest/tests/bcachefs/xfstests.ktest/generic/388
> >> realpath: /home/axboe/git/ktest/tests/bcachefs/xfstests.ktest/generic/388: Not a directory
> >> Error 1 at /home/axboe/git/ktest/build-test-kernel 262 from: ktest_test=$(realpath "$1"), exiting
> >>
> >> and I suspect that should've been a space, but:
> >>
> >> ~/git/ktest/build-test-kernel run -ILP ~/git/ktest/tests/bcachefs/xfstests.ktest generic/388
> >> Running test xfstests.ktest on m1max at /home/axboe/git/linux-block
> >> No tests found
> >> TEST FAILED
> > 
> > doh, this is because we just changed it to pick up the list of tests
> > from the test lists that fstests generated.
> > 
> > Go into ktest/tests/xfstests and run make and it'll work. (Doesn't
> > matter if make fails due to missing libraries, it'll re-run make inside
> > the VM where the dependencies will all be available).
> 
> OK, I'll try that as well.
> 
> BTW, ran into these too. Didn't do anything, it was just a mount and
> umount trying to get the test going:
> 
> axboe@m1max-kvm ~/g/k/t/xfstests> sudo cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff000201a5e000 (size 1024):
>   comm "bch-copygc/nvme", pid 11362, jiffies 4295015821 (age 6863.776s)
>   hex dump (first 32 bytes):
>     40 00 00 00 00 00 00 00 62 aa e8 ee 00 00 00 00  @.......b.......
>     10 e0 a5 01 02 00 ff ff 10 e0 a5 01 02 00 ff ff  ................
>   backtrace:
>     [<000000002668da56>] slab_post_alloc_hook.isra.0+0xb4/0xbc
>     [<000000006b0b510c>] __kmem_cache_alloc_node+0xd0/0x178
>     [<00000000041cfdde>] __kmalloc_node+0xac/0xd4
>     [<00000000e1556d66>] kvmalloc_node+0x54/0xe4
>     [<00000000df620afb>] bucket_table_alloc.isra.0+0x44/0x120
>     [<000000005d44ce16>] rhashtable_init+0x148/0x1ac
>     [<00000000fdca7475>] bch2_copygc_thread+0x50/0x2e4
>     [<00000000ea76e08f>] kthread+0xc4/0xd4
>     [<0000000068107ad6>] ret_from_fork+0x10/0x20
> unreferenced object 0xffff000200eed800 (size 1024):
>   comm "bch-copygc/nvme", pid 13934, jiffies 4295086192 (age 6582.296s)
>   hex dump (first 32 bytes):
>     40 00 00 00 00 00 00 00 e8 a5 2a bb 00 00 00 00  @.........*.....
>     10 d8 ee 00 02 00 ff ff 10 d8 ee 00 02 00 ff ff  ................
>   backtrace:
>     [<000000002668da56>] slab_post_alloc_hook.isra.0+0xb4/0xbc
>     [<000000006b0b510c>] __kmem_cache_alloc_node+0xd0/0x178
>     [<00000000041cfdde>] __kmalloc_node+0xac/0xd4
>     [<00000000e1556d66>] kvmalloc_node+0x54/0xe4
>     [<00000000df620afb>] bucket_table_alloc.isra.0+0x44/0x120
>     [<000000005d44ce16>] rhashtable_init+0x148/0x1ac
>     [<00000000fdca7475>] bch2_copygc_thread+0x50/0x2e4
>     [<00000000ea76e08f>] kthread+0xc4/0xd4
>     [<0000000068107ad6>] ret_from_fork+0x10/0x20

yup, missing a rhashtable_destroy() call, I'll do some kmemleak testing