lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 4 Jan 2022 15:33:16 +0100
From:   Jan Kara <>
To:     kvartet <>
Cc:     Theodore Ts'o <>, Jan Kara <>,,,,
Subject: Re: INFO: task hung in add_transaction_credits


On Tue 04-01-22 18:30:47, kvartet wrote:
> When using Syzkaller to fuzz the latest Linux kernel, the following
> crash was triggered.
> HEAD commit: a7904a538933 Linux 5.16-rc6
> git tree: upstream
> console output:
> kernel config:
> Sorry, I don't have a reproducer for this crash, hope the symbolized
> report can help.
> If you fix this issue, please add the following tag to the commit:
> Reported-by: Yiru Xu <>

Thanks for report. I had a look into the stacktraces. What is clear is that
there are several processes waiting in wait_transaction_locked() meaning
that we want to commit a transaction and wait while there are still active
handles attached to the transaction. I can also infer that the process
holding the handle for the transaction is:

4 locks held by syz-executor.1/20606:
 #0: ffff88810c7ec460 (sb_writers#5){.+.+}-{0:0}, at:
filename_create+0xf3/0x490 fs/namei.c:3649
 #1: ffff888028ff7198 (&type->i_mutex_dir_key#4/1){+.+.}-{3:3}, at:
inode_lock_nested include/linux/fs.h:818 [inline]
 #1: ffff888028ff7198 (&type->i_mutex_dir_key#4/1){+.+.}-{3:3}, at:
filename_create+0x158/0x490 fs/namei.c:3654
 #2: ffff88810c7f8990 (jbd2_handle){++++}-{0:0}, at:
start_this_handle+0xf58/0x1360 fs/jbd2/transaction.c:466
 #3: ffff8880287f2e28 (&mapping->i_mmap_rwsem){++++}-{3:3}, at:
i_mmap_lock_read include/linux/fs.h:513 [inline]
 #3: ffff8880287f2e28 (&mapping->i_mmap_rwsem){++++}-{3:3}, at:
rmap_walk_file+0x86d/0xc20 mm/rmap.c:2345

What is not obvious though is why this task is blocked and does not
eventually release the transaction handle. For that we would need a
stacktrace of this task...

Jan Kara <>

Powered by blists - more mailing lists