From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DD98C4332F for ; Thu, 8 Dec 2022 15:40:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229828AbiLHPkY (ORCPT ); Thu, 8 Dec 2022 10:40:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229808AbiLHPkO (ORCPT ); Thu, 8 Dec 2022 10:40:14 -0500 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63CE8B68 for ; Thu, 8 Dec 2022 07:40:07 -0800 (PST) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2B8FdpFn004109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Dec 2022 10:39:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1670513994; bh=69C163rhbG+6KT0oaec3E5RjFCQQ6U3oPgXAAoCstXk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=BeMJDct5Nn8W9MUec75hie7Ta+R0uOft0TCOCl/sC3bcK+DINybV61quBWp8nBZY4 n4CGvE7iGGGooOStJDw+FnCi0o8nOIDJ6ywuKahsQcKKwwqOHDp+5ytFDHqKLc5J8W GcRr1MP1Yc1S+lQoN7DTbAnRU1Vu6Y495zWSMvRA6zb3Q6FIf/JiwbZ+H3VFpztpDN OA+557NZqpE5oX/1/2FApRnBvoTqxygCmmm6TnRVEbct96OJhkt/HWyBT0ewze5pRF tdzMHCgdu6MulQa0iiQh50Sm+6OQm0TJpu7KxUPRkMmhlzUk2tveE9EtvdvS6CBAvQ 24sb7Ae8c+2CA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id D5B2015C39E4; Thu, 8 Dec 2022 10:39:51 -0500 (EST) Date: Thu, 8 Dec 2022 10:39:51 -0500 From: "Theodore Ts'o" To: Jan Kara Cc: Thorsten Leemhuis , Andreas Dilger , linux-ext4@vger.kernel.org, stable@vger.kernel.org, Thilo Fromm , Jeremi Piotrowski , Andreas Gruenbacher Subject: Re: [PATCH] ext4: Fix deadlock due to mbcache entry corruption Message-ID: References: <20221123193950.16758-1-jack@suse.cz> <20221201151021.GA18380@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <9c414060-989d-55bb-9a7b-0f33bf103c4f@leemhuis.info> <20221208091523.t6ka6tqtclcxnsrp@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221208091523.t6ka6tqtclcxnsrp@quack3> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Dec 08, 2022 at 10:15:23AM +0100, Jan Kara wrote: > > Furthermore, the fix which Jan provided, and which apparently fixes > > the user's problem, (a) doesn't touch the ext4_bmap function, and (b) > > has a fixes tag for the patch: > > > > Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries") > > > > ... which is a commit which dates back to 2016, and the v4.6 kernel. ?!? > > Yes. AFAICT the bitfield race in mbcache was introduced in this commit but > somehow ext4 was using mbcache in a way that wasn't tripping the race. > After 65f8b80053 ("ext4: fix race when reusing xattr blocks"), the race > became much more likely and users started to notice... Ah, OK. And 65f8b80053 landed in 6.0, so while the bug may have been around for much longer, this change made it much more likely that folks would notice. That's the missing piece and why Microsoft started noticing this in their "Flatcar" container kernel. So I'll update the commit description so that this is more clear, and then I can figure out how to tell the regression-bot that the regression should be tracked using commit 65f8b80053 instead of 51ae846cff5 ("ext4: fix warning in ext4_iomap_begin as race between bmap and write"). Cheers, and thanks for the clarification, - Ted