linux-ext4 - Re: [syzbot] possible deadlock in jbd2_journal_lock

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: <643d007e-1041-4b3d-ed5e-ae47804f279d@linux.microsoft.com>
Date:   Mon, 24 Oct 2022 18:32:51 +0200
From:   Thilo Fromm <t-lo@...ux.microsoft.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Ye Bin <yebin10@...wei.com>, jack@...e.com, tytso@....edu,
        linux-ext4@...r.kernel.org, regressions@...ts.linux.dev,
        Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
Subject: Re: [syzbot] possible deadlock in jbd2_journal_lock_updates

Hello Honza,

> Yeah, I was pondering about this for some time but still I have no clue who
> could be holding the buffer lock (which blocks the task holding the
> transaction open) or how this could related to the commit you have
> identified. I have two things to try:
> 
> 1) Can you please check whether the deadlock reproduces also with 6.0
> kernel? The thing is that xattr handling code in ext4 has there some
> additional changes, commit 307af6c8793 ("mbcache: automatically delete
> entries from cache on freeing") in particular.

This would be complex; we currently do not integrate 6.0 with Flatcar 
and would need to spend quite some effort ingesting it first (mostly, 
make sure the new kernel does not break something unrelated). Flatcar is 
an image-based distro, so kernel updates imply full distro updates.

> 2) I have created a debug patch (against 5.15.x stable kernel). Can you
> please reproduce the failure with it and post the output of "echo w
>> /proc/sysrq-trigger" and also the output the debug patch will put into the
> kernel log? It will dump the information about buffer lock owner if we > cannot get the lock for more than 32 seconds.

This would be more straightforward - I can reach out to one of our users 
suffering from the issue; they can reliably reproduce it and don't shy 
away from patching their kernel. Where can I find the patch?

Best,
Thilo