From: Eugen Hristev <eugen.hristev@collabora.com>
To: Gabriel Krisman Bertazi <krisman@suse.de>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org, jaegeuk@kernel.org, chao@kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@collabora.com, viro@zeniv.linux.org.uk,
brauner@kernel.org, jack@suse.cz,
Gabriel Krisman Bertazi <krisman@collabora.com>
Subject: Re: [PATCH v13 2/9] f2fs: Simplify the handling of cached insensitive names
Date: Mon, 18 Mar 2024 11:53:54 +0200 [thread overview]
Message-ID: <cea072bf-0ae5-4d0d-b0db-cd2ac772f463@collabora.com> (raw)
In-Reply-To: <8734sskha1.fsf@mailhost.krisman.be>
On 3/14/24 16:41, Gabriel Krisman Bertazi wrote:
> Eugen Hristev <eugen.hristev@collabora.com> writes:
>
>>> Please, make sure you actually stress test this patchset with fstests
>>> against both f2fs and ext4 before sending each new version.
>>
>> I did run the xfstests, however, maybe I did not run the full suite, or maybe I am
>> running it in a wrong way ?
>
> No worries. Did you manage to reproduce it?
Yes, thank you, using qemu on the x86_64 with your commands below.
While the oops was caused by that wrong kfree call, fixing it and moving further
got me into further problems.
I am unsure though how these patches cause it.
Here is a snippet of the problem that occurs now :
generic/417 12s ... [ 616.265444] run fstests generic/417 at 2024-03-18 09:22:48
[ 616.768435] ------------[ cut here ]------------
[ 616.769493] WARNING: CPU: 4 PID: 133 at block/blk-merge.c:580
__blk_rq_map_sg+0x46a/0x480
[ 616.771253] Modules linked in:
[ 616.771873] CPU: 4 PID: 133 Comm: kworker/4:1H Not tainted
6.7.0-09941-g554c4640dff5 #18
[ 616.773660] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014
[ 616.775573] Workqueue: kblockd blk_mq_run_work_fn
[ 616.776570] RIP: 0010:__blk_rq_map_sg+0x46a/0x480
[ 616.777547] Code: 17 fe ff ff 44 89 58 0c 48 8b 01 e9 ec fc ff ff 43 8d 3c 06 48
8b 14 24 81 ff 00 10 00 00 0f 86 af fc ff ff e9 02 fe ff ff 90 <0f> 0b 90 e9 76 fd
ff ff 90 0f 0b 90 0f 0b 0f 1f 84 00 00 00 00 00
[ 616.781245] RSP: 0018:ffff97e4804f3b98 EFLAGS: 00010216
[ 616.782322] RAX: 000000000000005e RBX: 0000000000000f10 RCX: ffff8f5701eed000
[ 616.783929] RDX: ffffdc0c4052df82 RSI: 0000000000001000 RDI: 00000000fffffffc
[ 616.785426] RBP: 000000000000005e R08: 0000000000000000 R09: ffff8f5702120000
[ 616.787065] R10: ffffdc0c4052df80 R11: 0000000000000000 R12: ffff8f5702118000
[ 616.788650] R13: 0000000000000000 R14: 0000000000001000 R15: ffffdc0c4052df80
[ 616.790129] FS: 0000000000000000(0000) GS:ffff8f577db00000(0000)
knlGS:0000000000000000
[ 616.791826] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 616.793069] CR2: 00007fbe596adc98 CR3: 000000001162e000 CR4: 0000000000350ef0
[ 616.794528] Call Trace:
[ 616.795093] <TASK>
[ 616.795541] ? __warn+0x7f/0x130
[ 616.796242] ? __blk_rq_map_sg+0x46a/0x480
[ 616.797101] ? report_bug+0x199/0x1b0
[ 616.797843] ? handle_bug+0x3d/0x70
[ 616.798656] ? exc_invalid_op+0x18/0x70
[ 616.799461] ? asm_exc_invalid_op+0x1a/0x20
[ 616.800313] ? __blk_rq_map_sg+0x46a/0x480
[ 616.801207] ? __blk_rq_map_sg+0xfc/0x480
[ 616.802213] scsi_alloc_sgtables+0xae/0x2b0
[ 616.803258] sd_init_command+0x181/0x860
[ 616.804111] scsi_queue_rq+0x7c3/0xae0
[ 616.804910] blk_mq_dispatch_rq_list+0x2bf/0x7c0
[ 616.805962] __blk_mq_sched_dispatch_requests+0x40a/0x5c0
[ 616.807226] blk_mq_sched_dispatch_requests+0x34/0x60
[ 616.808389] blk_mq_run_work_fn+0x5f/0x70
[ 616.809332] process_one_work+0x136/0x2f0
[ 616.810268] ? __pfx_worker_thread+0x10/0x10
[ 616.811320] worker_thread+0x2ef/0x400
[ 616.812215] ? __pfx_worker_thread+0x10/0x10
[ 616.813205] kthread+0xd5/0x100
[ 616.813907] ? __pfx_kthread+0x10/0x10
[ 616.814787] ret_from_fork+0x2f/0x50
[ 616.815598] ? __pfx_kthread+0x10/0x10
[ 616.816394] ret_from_fork_asm+0x1b/0x30
[ 616.817210] </TASK>
[ 616.817658] ---[ end trace 0000000000000000 ]---
[ 616.818687] ------------[ cut here ]------------
[ 616.819697] kernel BUG at drivers/scsi/scsi_lib.c:1068!
Do you have any ideas ?
Thanks !
Eugen
>
>> How are you running the kvm-xfstests with qemu ? Can you share your command
>> arguments please ?
>
> I don't use kvm-xfstests. I run ./check directly:
>
> export SCRATCH_DEV=/dev/loop1
> export SCRATCH_MNT=$BASEMNT/scratch
> export TEST_DEV=/dev/loop0
> export TEST_DIR=$BASEMNT/test
> export RESULT_BASE=${BASEMNT}/results
> export REPORT_DIR=${BASEMNT}/report
> export FSTYP=f2fs
>
> mkfs.f2fs -f -C utf8 -O casefold ${TEST_DEV}
>
> ./check -g encrypt,quick
>
next prev parent reply other threads:[~2024-03-18 9:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 10:15 [PATCH v13 0/9] Cache insensitive cleanup for ext4/f2fs Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 1/9] ext4: Simplify the handling of cached insensitive names Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 2/9] f2fs: " Eugen Hristev
2024-03-13 23:36 ` Gabriel Krisman Bertazi
2024-03-14 8:44 ` Eugen Hristev
2024-03-14 14:41 ` Gabriel Krisman Bertazi
2024-03-18 9:53 ` Eugen Hristev [this message]
2024-03-05 10:16 ` [PATCH v13 3/9] libfs: Introduce case-insensitive string comparison helper Eugen Hristev
2024-03-13 23:16 ` Gabriel Krisman Bertazi
2024-03-05 10:16 ` [PATCH v13 4/9] ext4: Reuse generic_ci_match for ci comparisons Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 5/9] f2fs: " Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 6/9] ext4: Log error when lookup of encoded dentry fails Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 7/9] f2fs: " Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 8/9] ext4: Move CONFIG_UNICODE defguards into the code flow Eugen Hristev
2024-03-05 10:16 ` [PATCH v13 9/9] f2fs: " Eugen Hristev
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=cea072bf-0ae5-4d0d-b0db-cd2ac772f463@collabora.com \
--to=eugen.hristev@collabora.com \
--cc=adilger.kernel@dilger.ca \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=kernel@collabora.com \
--cc=krisman@collabora.com \
--cc=krisman@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).