lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <bug-198187-13602-i46SPmwAq8@https.bugzilla.kernel.org/> Date: Thu, 18 Jan 2018 10:05:53 +0000 From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...nel.org Subject: [Bug 198187] jbd2_log_wait_commit hangs https://bugzilla.kernel.org/show_bug.cgi?id=198187 --- Comment #8 from Jan Kara (jack@...e.cz) --- Thanks for the output. So every process there waits for jbd2 thread to commit the running transaction. JBD2 does: [144526.447408] jbd2/dm-19-8 D 0 1580 2 0x00000080 [144526.448176] Call Trace: [144526.448937] __schedule+0x3be/0x830 [144526.449632] ? scsi_request_fn+0x3f/0x6b0 [144526.450310] ? bit_wait+0x60/0x60 [144526.450993] schedule+0x36/0x80 [144526.451673] io_schedule+0x16/0x40 [144526.452343] bit_wait_io+0x11/0x60 [144526.453017] __wait_on_bit+0x58/0x90 [144526.453692] out_of_line_wait_on_bit+0x8e/0xb0 [144526.454371] ? bit_waitqueue+0x40/0x40 [144526.455051] __wait_on_buffer+0x32/0x40 [144526.455731] jbd2_journal_commit_transaction+0xfa4/0x1800 [144526.456414] kjournald2+0xd2/0x270 [144526.457098] ? kjournald2+0xd2/0x270 [144526.457782] ? remove_wait_queue+0x70/0x70 [144526.458470] kthread+0x109/0x140 [144526.459139] ? commit_timeout+0x10/0x10 [144526.459821] ? kthread_park+0x60/0x60 [144526.460497] ? do_syscall_64+0x67/0x150 [144526.461166] ret_from_fork+0x25/0x30 So we have submitted buffers for IO and they have not completed. In cases like this the problem is in 99% of cases either in the storage driver or in the storage firmware. Since you mentioned this started happening after kernel update and you seem to be using only plain SATA drives (am I right?), storage firmware is probably out of question. You seem to be using some kind of RAID on top of these SATA drives, that would look like the most probable culprit at this point. Can you describe your storage configuration? Also output of 'dmsetup table' would be useful. After having that we would probably need to pull in DM developers to have a look. Thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
Powered by blists - more mailing lists