Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <643d007e-1041-4b3d-ed5e-ae47804f279d@linux.microsoft.com>
Date:   Mon, 24 Oct 2022 18:32:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
To:     Jan Kara <jack@suse.cz>
Cc:     Ye Bin <yebin10@huawei.com>, jack@suse.com, tytso@mit.edu,
        linux-ext4@vger.kernel.org, regressions@lists.linux.dev,
        Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
References: <20220929082716.5urzcfk4hnapd3cr@quack3>
 <d8b18ba8-ea12-b617-6b5e-455a1d7b5e21@linux.microsoft.com>
 <20221004063807.GA30205@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
 <20221004091035.idjgo2xyscf6ovnv@quack3>
 <eeb17fca-4e79-b39f-c394-a6fa6873eb26@linux.microsoft.com>
 <20221005151053.7jjgc7uhvquo6a5n@quack3>
 <20221010142410.GA1689@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
 <2ede5fce-7077-6e64-93a9-a7d993bc498f@linux.microsoft.com>
 <20221014132543.i3aiyx4ent4qwy4i@quack3>
 <d30f4e74-aa75-743d-3c89-80ec61d67c6c@linux.microsoft.com>
 <20221024104628.ozxjtdrotysq2haj@quack3>
Content-Language: en-US
From:   Thilo Fromm <t-lo@linux.microsoft.com>
Subject: Re: [syzbot] possible deadlock in jbd2_journal_lock_updates
In-Reply-To: <20221024104628.ozxjtdrotysq2haj@quack3>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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