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
