linux-ext4 - [Bug 198187] jbd2_log_wait

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.