Re: [syzbot] possible deadlock in jbd2_journal_lock_updates

[Jan Kara <jack@suse.cz>]

On Fri 21-10-22 12:23:41, Thilo Fromm wrote:
> Hello Honza,
> 
> > > Just want to make sure this does not get lost - as mentioned earlier,
> > > reverting 51ae846cff5 leads to a kernel build that does not have this issue.
> > 
> > Yes, I'm aware of this and still cannot quite wrap my head how it could be
> > given the stacktraces I see :) They do not seem to come anywhere near that
> > code...
> 
> Just reaching out to let folks know that we see more reports on this issue
> coming in for kernels >=5.15.63, see
> https://github.com/flatcar/Flatcar/issues/847#issuecomment-1286523602.

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. 

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.

Thanks for your help and patience.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR