From patchwork Tue Feb 14 21:25:25 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140859 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 65EC3C64ED9 for ; Tue, 14 Feb 2023 21:27:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232679AbjBNV1J (ORCPT ); Tue, 14 Feb 2023 16:27:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232831AbjBNV1F (ORCPT ); Tue, 14 Feb 2023 16:27:05 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E0C5303DD; Tue, 14 Feb 2023 13:26:26 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id bg2so7043535pjb.4; Tue, 14 Feb 2023 13:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=AvsSfQdiGaa1AyDvXxOboWMtTwpMwQiRc7D7tG1w9Ro=; b=iVcmPbW1yesxM8IwO+CU1yc4byy9FpRevMUSsDRzrYNQzGRJ/GLQTTQsYq1pStzEWQ EJLn10vdbCD5IVkbAMYskORrDtDrVKvgUHQJSO+LfrnFQHaw+jQqFzZT8X4L+0DWcmrO Z7DcQH+8RJA9c3GBNKST/vXwesqB/mjSHOZ/80ub79roq906ysnXxCPM64kWgbH2oq8O DrNr4Hwe2wRZyKuOEaUlTUz42oXUH0nc/2eMb3aFOxlA6YuptVS9O2cheDneds5B7mMa h2X21ckBiofoXXhNnOkYcjZCsmLzGEzegfPcs3phSu/EFYh+uhlzRR2GPkzEHBfwnrJw ngoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AvsSfQdiGaa1AyDvXxOboWMtTwpMwQiRc7D7tG1w9Ro=; b=3zzPdlDgDtuY+zVOPxPrgWN6UP10kxAJMhm/j3hbL0rJsZR/Yojpf8KZkfu7Qapl7G 7oACFo+1j+BHt227jeHWlVo6fwBDE++xR8t0hujWsAbGnKd894eanGZE3GtVWlapDrhr pVMZJXZzDGmLOA3bvI4akwL3ho4POq7n4K8rXYwkxZf4DkW3Ib5IqB0r5RhsKxjaeecR 6WD77z6Cyg4W9vC6MHryYULSYYaZUtXNQObfFfeYPpnU0wjLqD2tGxXeDIVIR5Wq+MTp QSD+q6kLqXP0l3hMC9oIOFyKf/I8GRpvWJoWAPAnDo630awLQkk8lqN2iiYtFaVUWQ0h uLpQ== X-Gm-Message-State: AO0yUKWwvOLa9fA6zAIBfH9s9q0JlAG807HG9Nh/VlWadMWAjY3pwah9 cZ7I+BGvRt+KJUsH/VqlIyDucwxVZun7vQ== X-Google-Smtp-Source: AK7set+Fy1QlswK6VigLtt7GdUUadz2KELuXnhPdbVYsZc2dHkGMc5a4orWFPUlJRiMH0TCXgpOdng== X-Received: by 2002:a17:902:da90:b0:192:5ec4:6656 with SMTP id j16-20020a170902da9000b001925ec46656mr165064plx.3.1676409965810; Tue, 14 Feb 2023 13:26:05 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:05 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , "Darrick J . Wong" , Allison Henderson , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 01/10] xfs: zero inode fork buffer at allocation Date: Tue, 14 Feb 2023 13:25:25 -0800 Message-Id: <20230214212534.1420323-2-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit cb512c921639613ce03f87e62c5e93ed9fe8c84d ] When we first allocate or resize an inline inode fork, we round up the allocation to 4 byte alingment to make journal alignment constraints. We don't clear the unused bytes, so we can copy up to three uninitialised bytes into the journal. Zero those bytes so we only ever copy zeros into the journal. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Reviewed-by: Allison Henderson Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_inode_fork.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/fs/xfs/libxfs/xfs_inode_fork.c b/fs/xfs/libxfs/xfs_inode_fork.c index 1d174909f9bd..20095233d7bc 100644 --- a/fs/xfs/libxfs/xfs_inode_fork.c +++ b/fs/xfs/libxfs/xfs_inode_fork.c @@ -50,8 +50,13 @@ xfs_init_local_fork( mem_size++; if (size) { + /* + * As we round up the allocation here, we need to ensure the + * bytes we don't copy data into are zeroed because the log + * vectors still copy them into the journal. + */ real_size = roundup(mem_size, 4); - ifp->if_u1.if_data = kmem_alloc(real_size, KM_NOFS); + ifp->if_u1.if_data = kmem_zalloc(real_size, KM_NOFS); memcpy(ifp->if_u1.if_data, data, size); if (zero_terminate) ifp->if_u1.if_data[size] = '\0'; @@ -500,10 +505,11 @@ xfs_idata_realloc( /* * For inline data, the underlying buffer must be a multiple of 4 bytes * in size so that it can be logged and stay on word boundaries. - * We enforce that here. + * We enforce that here, and use __GFP_ZERO to ensure that size + * extensions always zero the unused roundup area. */ ifp->if_u1.if_data = krealloc(ifp->if_u1.if_data, roundup(new_size, 4), - GFP_NOFS | __GFP_NOFAIL); + GFP_NOFS | __GFP_NOFAIL | __GFP_ZERO); ifp->if_bytes = new_size; } From patchwork Tue Feb 14 21:25:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140860 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 AA9E6C64ED6 for ; Tue, 14 Feb 2023 21:27:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232830AbjBNV1I (ORCPT ); Tue, 14 Feb 2023 16:27:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232833AbjBNV1F (ORCPT ); Tue, 14 Feb 2023 16:27:05 -0500 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4593303F8; Tue, 14 Feb 2023 13:26:27 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id k13so18421793plg.0; Tue, 14 Feb 2023 13:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=D4ycGkk3qcn7VrJ4nBZli7Tj+n2Cr5liEIeaqSLavKY=; b=M7ufR78AaMh+GneDxEPh59VSWgdo18rjoEqopHpm9f2pZz/+tIKNCwDZReGQS74k4o pzaLlgrdtrllt4RMtN026JrTAXm5goJQ9W+YuywaRAIbCwmPEgBpFBu52Jvgqjc9yitZ ydTPERRSOkEhwWdX6RZuyK0t3eszt4ywwQg/wuSpV68D5uBkUAacd440LWen1KGDW5Ug GA+fem/GgKOg02fmmhPDhUx8ukyWllFP5tj64OYLE/Y5T2i5H2hdFJl4zX/61JjhyMlO AXLZeSI1bSSgKxujSmFTKS6cH6PZ9QYPPYu41gC5RwSEy333kXXqIReLZgfj8/pEvxxt FF6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=D4ycGkk3qcn7VrJ4nBZli7Tj+n2Cr5liEIeaqSLavKY=; b=LBf+4zaCaJ5iG1wRBMBHB5hoRNAH8RLe0Ub1+bs+wB1y5Ksh3C90wPjz4Ei7VhVHn/ iZvJiyDToow0bYrrLVMCBvn2U8D1qpxmsOeaekiBl1DWdJCJGnuhqmCuZWnGIzM7hcaD IFSuvwmuyoJzxj5xgRdlvNIEg2u5eJT4eqV+LZ92gJ/myvTmbZPSPHXJCp/m3Ynutr2e 3TNhf9x6dITd5XMyAitM5S4pISFTnGtn/VQpmv2icD8c/HlukKrhKtDtz0NGtSQDkPyI 7IRmXOhlQMZA4XUXu/LYNWBn+dkale173Uw9dsJmnXZ8iyFJqBPgCfjXIJgcY+yBvIaG VU4w== X-Gm-Message-State: AO0yUKUWuujpevPUQZUz157iLP840qOZOjWjo0dhxYH5OUW2stHCcUXu fGEKDYpXKEOtVioDhnoPO4LXx3S4ljTxzA== X-Google-Smtp-Source: AK7set8pIcYPBs8qchSHsSHcUMOngpGDsRkci5AGbFq+FJavVyLVXj6T9R9Cvm+zdw6FDbDlCAYwGA== X-Received: by 2002:a17:902:fad0:b0:199:201d:12f1 with SMTP id ld16-20020a170902fad000b00199201d12f1mr63756plb.47.1676409967146; Tue, 14 Feb 2023 13:26:07 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:06 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , "Darrick J . Wong" , Allison Henderson , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 02/10] xfs: fix potential log item leak Date: Tue, 14 Feb 2023 13:25:26 -0800 Message-Id: <20230214212534.1420323-3-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit c230a4a85bcdbfc1a7415deec6caf04e8fca1301 ] Ever since we added shadown format buffers to the log items, log items need to handle the item being released with shadow buffers attached. Due to the fact this requirement was added at the same time we added new rmap/reflink intents, we missed the cleanup of those items. In theory, this means shadow buffers can be leaked in a very small window when a shutdown is initiated. Testing with KASAN shows this leak does not happen in practice - we haven't identified a single leak in several years of shutdown testing since ~v4.8 kernels. However, the intent whiteout cleanup mechanism results in every cancelled intent in exactly the same state as this tiny race window creates and so if intents down clean up shadow buffers on final release we will leak the shadow buffer for just about every intent we create. Hence we start with this patch to close this condition off and ensure that when whiteouts start to be used we don't leak lots of memory. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Reviewed-by: Allison Henderson Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_bmap_item.c | 2 ++ fs/xfs/xfs_icreate_item.c | 1 + fs/xfs/xfs_refcount_item.c | 2 ++ fs/xfs/xfs_rmap_item.c | 2 ++ 4 files changed, 7 insertions(+) diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c index 03159970133f..51ffdec5e4fa 100644 --- a/fs/xfs/xfs_bmap_item.c +++ b/fs/xfs/xfs_bmap_item.c @@ -39,6 +39,7 @@ STATIC void xfs_bui_item_free( struct xfs_bui_log_item *buip) { + kmem_free(buip->bui_item.li_lv_shadow); kmem_cache_free(xfs_bui_zone, buip); } @@ -198,6 +199,7 @@ xfs_bud_item_release( struct xfs_bud_log_item *budp = BUD_ITEM(lip); xfs_bui_release(budp->bud_buip); + kmem_free(budp->bud_item.li_lv_shadow); kmem_cache_free(xfs_bud_zone, budp); } diff --git a/fs/xfs/xfs_icreate_item.c b/fs/xfs/xfs_icreate_item.c index 017904a34c02..c265ae20946d 100644 --- a/fs/xfs/xfs_icreate_item.c +++ b/fs/xfs/xfs_icreate_item.c @@ -63,6 +63,7 @@ STATIC void xfs_icreate_item_release( struct xfs_log_item *lip) { + kmem_free(ICR_ITEM(lip)->ic_item.li_lv_shadow); kmem_cache_free(xfs_icreate_zone, ICR_ITEM(lip)); } diff --git a/fs/xfs/xfs_refcount_item.c b/fs/xfs/xfs_refcount_item.c index 46904b793bd4..8ef842d17916 100644 --- a/fs/xfs/xfs_refcount_item.c +++ b/fs/xfs/xfs_refcount_item.c @@ -35,6 +35,7 @@ STATIC void xfs_cui_item_free( struct xfs_cui_log_item *cuip) { + kmem_free(cuip->cui_item.li_lv_shadow); if (cuip->cui_format.cui_nextents > XFS_CUI_MAX_FAST_EXTENTS) kmem_free(cuip); else @@ -204,6 +205,7 @@ xfs_cud_item_release( struct xfs_cud_log_item *cudp = CUD_ITEM(lip); xfs_cui_release(cudp->cud_cuip); + kmem_free(cudp->cud_item.li_lv_shadow); kmem_cache_free(xfs_cud_zone, cudp); } diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c index 5f0695980467..15e7b01740a7 100644 --- a/fs/xfs/xfs_rmap_item.c +++ b/fs/xfs/xfs_rmap_item.c @@ -35,6 +35,7 @@ STATIC void xfs_rui_item_free( struct xfs_rui_log_item *ruip) { + kmem_free(ruip->rui_item.li_lv_shadow); if (ruip->rui_format.rui_nextents > XFS_RUI_MAX_FAST_EXTENTS) kmem_free(ruip); else @@ -227,6 +228,7 @@ xfs_rud_item_release( struct xfs_rud_log_item *rudp = RUD_ITEM(lip); xfs_rui_release(rudp->rud_ruip); + kmem_free(rudp->rud_item.li_lv_shadow); kmem_cache_free(xfs_rud_zone, rudp); } From patchwork Tue Feb 14 21:25:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140861 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 928D8C678D4 for ; Tue, 14 Feb 2023 21:27:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232833AbjBNV1K (ORCPT ); Tue, 14 Feb 2023 16:27:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232853AbjBNV1J (ORCPT ); Tue, 14 Feb 2023 16:27:09 -0500 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1187A305CF; Tue, 14 Feb 2023 13:26:31 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id i18so9933453pli.3; Tue, 14 Feb 2023 13:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GJ7rmQaa+5eKP3H4nq3epkc5bH6eIMkkoMiaG58I7BU=; b=LfdNyZUfbIp/Y2KzJEK35pQynmoURN0t3OVUZg7n44Ei69l2XO7kYBzIDVN8bhRtid SqZ+OPEwNnSTBH3zvhFaGvltR71G1jaA62tpn+T/Hp/NyPgJ8j4rMSkIQem0/ag+QFIb LF8+WbokN2jmC1TwSIrinhufpA2VAJX6qUQhP2I4g3bncukZ1MywapXS0WHz1CxWDTrd bZqFY8GdAlUQhAOLRUwp4aj0bhQN0OvEXehLf89LTes34ckwNwg/Y80oD5FvyrIVJ1fe +ngptMjhD34nsNoiMKIvQLt/zMsLtjXvytsOWVyMO23Ti/lc5WfUU7841UsqyPz3U4Ie GCGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GJ7rmQaa+5eKP3H4nq3epkc5bH6eIMkkoMiaG58I7BU=; b=XFVzX4kGOYHCxjrIXcWxfzjgugWt7GY3FPLyCmjd1EeM6K6pfSGPJq4MdKPHwNj1HW FxsobbYj0Q/pIYk2hOgpOMS22LY/MCxgcF0BPXKRkekto1VBICIpd8dpBt7klqJHjDJr T43d34Rm425jcGZi/LjrVM9K4MUcVPchX1KTK6ud+Tlhdrlv4JuUM38a0EOpRYsArHEr BIfhr+ZaJlsuscOjcsfRy0dT/xqni8+BpZtz2+pRf0oCqn//I6ANW+R0YBSQE+FZEi+L amI4MgVIyQWm4C6uHiFNgUX+D3bzd0OPS0VmAAFaQEqPrU+vbTmeb5mhw4TQux0Ov1jE Zq7w== X-Gm-Message-State: AO0yUKUCsEZujbpsU5NofALVsGV4bvLBBP8EaCoefW2qXVr/dz4Il3cc lGzhOUCJm4p0wiIcAvCXaDwmAXQhUEZF4w== X-Google-Smtp-Source: AK7set9u9fVZiukUqUAgto9uU7tioNQvgu/wMqYd0YhYTvcDqgLTStlz6zrfHOfuYMqRbPIBunXWhA== X-Received: by 2002:a17:903:88f:b0:19a:9b87:e73f with SMTP id kt15-20020a170903088f00b0019a9b87e73fmr163026plb.1.1676409968602; Tue, 14 Feb 2023 13:26:08 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:07 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , Christoph Hellwig , "Darrick J . Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 03/10] xfs: detect self referencing btree sibling pointers Date: Tue, 14 Feb 2023 13:25:27 -0800 Message-Id: <20230214212534.1420323-4-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit dc04db2aa7c9307e740d6d0e173085301c173b1a ] To catch the obvious graph cycle problem and hence potential endless looping. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_btree.c | 140 ++++++++++++++++++++++++++++---------- 1 file changed, 105 insertions(+), 35 deletions(-) diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index 298395481713..5bec048343b0 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -51,6 +51,52 @@ xfs_btree_magic( return magic; } +static xfs_failaddr_t +xfs_btree_check_lblock_siblings( + struct xfs_mount *mp, + struct xfs_btree_cur *cur, + int level, + xfs_fsblock_t fsb, + xfs_fsblock_t sibling) +{ + if (sibling == NULLFSBLOCK) + return NULL; + if (sibling == fsb) + return __this_address; + if (level >= 0) { + if (!xfs_btree_check_lptr(cur, sibling, level + 1)) + return __this_address; + } else { + if (!xfs_verify_fsbno(mp, sibling)) + return __this_address; + } + + return NULL; +} + +static xfs_failaddr_t +xfs_btree_check_sblock_siblings( + struct xfs_mount *mp, + struct xfs_btree_cur *cur, + int level, + xfs_agnumber_t agno, + xfs_agblock_t agbno, + xfs_agblock_t sibling) +{ + if (sibling == NULLAGBLOCK) + return NULL; + if (sibling == agbno) + return __this_address; + if (level >= 0) { + if (!xfs_btree_check_sptr(cur, sibling, level + 1)) + return __this_address; + } else { + if (!xfs_verify_agbno(mp, agno, sibling)) + return __this_address; + } + return NULL; +} + /* * Check a long btree block header. Return the address of the failing check, * or NULL if everything is ok. @@ -65,6 +111,8 @@ __xfs_btree_check_lblock( struct xfs_mount *mp = cur->bc_mp; xfs_btnum_t btnum = cur->bc_btnum; int crc = xfs_has_crc(mp); + xfs_failaddr_t fa; + xfs_fsblock_t fsb = NULLFSBLOCK; if (crc) { if (!uuid_equal(&block->bb_u.l.bb_uuid, &mp->m_sb.sb_meta_uuid)) @@ -83,16 +131,16 @@ __xfs_btree_check_lblock( if (be16_to_cpu(block->bb_numrecs) > cur->bc_ops->get_maxrecs(cur, level)) return __this_address; - if (block->bb_u.l.bb_leftsib != cpu_to_be64(NULLFSBLOCK) && - !xfs_btree_check_lptr(cur, be64_to_cpu(block->bb_u.l.bb_leftsib), - level + 1)) - return __this_address; - if (block->bb_u.l.bb_rightsib != cpu_to_be64(NULLFSBLOCK) && - !xfs_btree_check_lptr(cur, be64_to_cpu(block->bb_u.l.bb_rightsib), - level + 1)) - return __this_address; - return NULL; + if (bp) + fsb = XFS_DADDR_TO_FSB(mp, xfs_buf_daddr(bp)); + + fa = xfs_btree_check_lblock_siblings(mp, cur, level, fsb, + be64_to_cpu(block->bb_u.l.bb_leftsib)); + if (!fa) + fa = xfs_btree_check_lblock_siblings(mp, cur, level, fsb, + be64_to_cpu(block->bb_u.l.bb_rightsib)); + return fa; } /* Check a long btree block header. */ @@ -130,6 +178,9 @@ __xfs_btree_check_sblock( struct xfs_mount *mp = cur->bc_mp; xfs_btnum_t btnum = cur->bc_btnum; int crc = xfs_has_crc(mp); + xfs_failaddr_t fa; + xfs_agblock_t agbno = NULLAGBLOCK; + xfs_agnumber_t agno = NULLAGNUMBER; if (crc) { if (!uuid_equal(&block->bb_u.s.bb_uuid, &mp->m_sb.sb_meta_uuid)) @@ -146,16 +197,18 @@ __xfs_btree_check_sblock( if (be16_to_cpu(block->bb_numrecs) > cur->bc_ops->get_maxrecs(cur, level)) return __this_address; - if (block->bb_u.s.bb_leftsib != cpu_to_be32(NULLAGBLOCK) && - !xfs_btree_check_sptr(cur, be32_to_cpu(block->bb_u.s.bb_leftsib), - level + 1)) - return __this_address; - if (block->bb_u.s.bb_rightsib != cpu_to_be32(NULLAGBLOCK) && - !xfs_btree_check_sptr(cur, be32_to_cpu(block->bb_u.s.bb_rightsib), - level + 1)) - return __this_address; - return NULL; + if (bp) { + agbno = xfs_daddr_to_agbno(mp, xfs_buf_daddr(bp)); + agno = xfs_daddr_to_agno(mp, xfs_buf_daddr(bp)); + } + + fa = xfs_btree_check_sblock_siblings(mp, cur, level, agno, agbno, + be32_to_cpu(block->bb_u.s.bb_leftsib)); + if (!fa) + fa = xfs_btree_check_sblock_siblings(mp, cur, level, agno, + agbno, be32_to_cpu(block->bb_u.s.bb_rightsib)); + return fa; } /* Check a short btree block header. */ @@ -4265,6 +4318,21 @@ xfs_btree_visit_block( if (xfs_btree_ptr_is_null(cur, &rptr)) return -ENOENT; + /* + * We only visit blocks once in this walk, so we have to avoid the + * internal xfs_btree_lookup_get_block() optimisation where it will + * return the same block without checking if the right sibling points + * back to us and creates a cyclic reference in the btree. + */ + if (cur->bc_flags & XFS_BTREE_LONG_PTRS) { + if (be64_to_cpu(rptr.l) == XFS_DADDR_TO_FSB(cur->bc_mp, + xfs_buf_daddr(bp))) + return -EFSCORRUPTED; + } else { + if (be32_to_cpu(rptr.s) == xfs_daddr_to_agbno(cur->bc_mp, + xfs_buf_daddr(bp))) + return -EFSCORRUPTED; + } return xfs_btree_lookup_get_block(cur, level, &rptr, &block); } @@ -4439,20 +4507,21 @@ xfs_btree_lblock_verify( { struct xfs_mount *mp = bp->b_mount; struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + xfs_fsblock_t fsb; + xfs_failaddr_t fa; /* numrecs verification */ if (be16_to_cpu(block->bb_numrecs) > max_recs) return __this_address; /* sibling pointer verification */ - if (block->bb_u.l.bb_leftsib != cpu_to_be64(NULLFSBLOCK) && - !xfs_verify_fsbno(mp, be64_to_cpu(block->bb_u.l.bb_leftsib))) - return __this_address; - if (block->bb_u.l.bb_rightsib != cpu_to_be64(NULLFSBLOCK) && - !xfs_verify_fsbno(mp, be64_to_cpu(block->bb_u.l.bb_rightsib))) - return __this_address; - - return NULL; + fsb = XFS_DADDR_TO_FSB(mp, xfs_buf_daddr(bp)); + fa = xfs_btree_check_lblock_siblings(mp, NULL, -1, fsb, + be64_to_cpu(block->bb_u.l.bb_leftsib)); + if (!fa) + fa = xfs_btree_check_lblock_siblings(mp, NULL, -1, fsb, + be64_to_cpu(block->bb_u.l.bb_rightsib)); + return fa; } /** @@ -4493,7 +4562,9 @@ xfs_btree_sblock_verify( { struct xfs_mount *mp = bp->b_mount; struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); - xfs_agblock_t agno; + xfs_agnumber_t agno; + xfs_agblock_t agbno; + xfs_failaddr_t fa; /* numrecs verification */ if (be16_to_cpu(block->bb_numrecs) > max_recs) @@ -4501,14 +4572,13 @@ xfs_btree_sblock_verify( /* sibling pointer verification */ agno = xfs_daddr_to_agno(mp, xfs_buf_daddr(bp)); - if (block->bb_u.s.bb_leftsib != cpu_to_be32(NULLAGBLOCK) && - !xfs_verify_agbno(mp, agno, be32_to_cpu(block->bb_u.s.bb_leftsib))) - return __this_address; - if (block->bb_u.s.bb_rightsib != cpu_to_be32(NULLAGBLOCK) && - !xfs_verify_agbno(mp, agno, be32_to_cpu(block->bb_u.s.bb_rightsib))) - return __this_address; - - return NULL; + agbno = xfs_daddr_to_agbno(mp, xfs_buf_daddr(bp)); + fa = xfs_btree_check_sblock_siblings(mp, NULL, -1, agno, agbno, + be32_to_cpu(block->bb_u.s.bb_leftsib)); + if (!fa) + fa = xfs_btree_check_sblock_siblings(mp, NULL, -1, agno, agbno, + be32_to_cpu(block->bb_u.s.bb_rightsib)); + return fa; } /* From patchwork Tue Feb 14 21:25:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140862 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 1BCD7C6FA9D for ; Tue, 14 Feb 2023 21:27:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232862AbjBNV1K (ORCPT ); Tue, 14 Feb 2023 16:27:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232749AbjBNV1J (ORCPT ); Tue, 14 Feb 2023 16:27:09 -0500 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94A7F30295; Tue, 14 Feb 2023 13:26:32 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id e12so835748plh.6; Tue, 14 Feb 2023 13:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=q0YX+gKKtaapqxx0FnXl+kVggR18Ji7mSBNbdaoJVi4=; b=HDc5Ok8E9QADS+lNXh1Vl/GSA5xybqcrBRoEkKCH9/7ix7x2wgbFFU178kClAuRS9+ GtKR1mz4xBUyVd2bgSasPHaE8RA77B+BJIBgjcw/edgZ8NdmlX0tFHTrVYWOwvCuGvLL St0AUKYuLuWaVRpS1Xx+av5lA45JVfhH8wb8v7ZghLjnuCzDzYBZCHW9VszMX3BHdmva VQqpafEolJv83YSvxcBwSgCmirTi5n1px8AOyQpFfhlkv92cvNGQH/uCoPGxI69lFfcO XshXu0Z5AdbAMaCkqKML/so+/sE0XUc30rcjwKsUyJ8fF4DBwlPle4bTHvIHoh8KFzhu SquA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=q0YX+gKKtaapqxx0FnXl+kVggR18Ji7mSBNbdaoJVi4=; b=y/sIY1KIHDQLFYAappaxUh/U4eJApgA806sW3iIHPiUswUCsDO/rqcM81Jd8kdmuK3 KDxds/gvHZYxgIUBp2EHiWw7urpURwhl/oZdXG1f7QZk93ahibOCY7jcWwdIxHAJNzwV WtqTRWKRGrTMBt/6kZWcGxv6iVV7kWqc37wO3LuH86sAPckJQWAgzxEKb59MHXv2xR4G LJIjFyQuwNL6gRkaM36tbN9zbvOXyOgt7Yv9pNthiK9rtImrhT2kfnex+L+TlZMXh8eE 7DK9TZYp8A3gEy6tvvMCatHaAEWzLXSbDcziXM3zkzF64SK07COTXt7vJ2Ue5FXP/GI9 czXg== X-Gm-Message-State: AO0yUKUVBgnxGivwCJGmvEqiqPXG1zBxw9MfXr1hwPW2sHXKc2UaW91n klfU01L4qbsO7ndE89eOnV+djY6Y9phgxg== X-Google-Smtp-Source: AK7set9/i9v3IY2Z4x+Qz4ZjUn667Szq4ar5YYayC17e4QFOA8Rh6+mO4nrWHDs9Wy0kQpML7hJSAA== X-Received: by 2002:a17:902:fa83:b0:194:9b4e:1c90 with SMTP id lc3-20020a170902fa8300b001949b4e1c90mr13806plb.57.1676409969754; Tue, 14 Feb 2023 13:26:09 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:09 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , Christoph Hellwig , "Darrick J . Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 04/10] xfs: set XFS_FEAT_NLINK correctly Date: Tue, 14 Feb 2023 13:25:28 -0800 Message-Id: <20230214212534.1420323-5-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit dd0d2f9755191690541b09e6385d0f8cd8bc9d8f ] While xfs_has_nlink() is not used in kernel, it is used in userspace (e.g. by xfs_db) so we need to set the XFS_FEAT_NLINK flag correctly in xfs_sb_version_to_features(). Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_sb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index e58349be78bd..72c05485c870 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++ b/fs/xfs/libxfs/xfs_sb.c @@ -70,6 +70,8 @@ xfs_sb_version_to_features( /* optional V4 features */ if (sbp->sb_rblocks > 0) features |= XFS_FEAT_REALTIME; + if (sbp->sb_versionnum & XFS_SB_VERSION_NLINKBIT) + features |= XFS_FEAT_NLINK; if (sbp->sb_versionnum & XFS_SB_VERSION_ATTRBIT) features |= XFS_FEAT_ATTR; if (sbp->sb_versionnum & XFS_SB_VERSION_QUOTABIT) From patchwork Tue Feb 14 21:25:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140863 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 E83A2C6FA9E for ; Tue, 14 Feb 2023 21:27:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232749AbjBNV1L (ORCPT ); Tue, 14 Feb 2023 16:27:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232828AbjBNV1K (ORCPT ); Tue, 14 Feb 2023 16:27:10 -0500 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2D57305C4; Tue, 14 Feb 2023 13:26:33 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id n20-20020a17090aab9400b00229ca6a4636so103068pjq.0; Tue, 14 Feb 2023 13:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ydJINgiUXERcprOBsrfHGHvS8ULlgWZrSeh+RZ3+t00=; b=LK1+2Ivzq+WSDw+yIgo/16wGfl5rqUyC6ROPI601hK0UURkqXlc6fBgl6O7jPj0lOp qmgwdlWQIVTZRwWmsM/AMiLolCB31WFwtJbGyxqBnK5Y9NZCtGPwGY4OK5lCGa5+/A4m gq5c+mTFF4qmdyMogqn3ymL9eGNBWTLP5+BzFagUvmHJOnA4oAMeStAy08Rdt6oBDheY DP4XsNG0yu8PPLI8hgUIi+psf9a3/lq96+iM85o0lGEyWQW9Bqin9cFCG/W0VY6K6O26 V4e7mYeLJmYocSayW0YXM4Ld68j7w9cQExLo5nZDxBVMXUQKD4UOBbbWAKxavWkoYocQ ry4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ydJINgiUXERcprOBsrfHGHvS8ULlgWZrSeh+RZ3+t00=; b=UXcyPeLB+crPUDwpaPhDYES7IYZn6liRdBXvN00FiujhaLvhBdX3tt/u+6Rboab16o 1rQT/hfw93Rx4sI7KXG8IURZJ8r7ByAacpvBs53bA2eIvtOJPGHLMn0LbGC8CE1mIPhI MkVBzBYG91cLawwCEoUwweDYvx30Q+KgcG4Y/kJmZOPAiBsCwEFvxaZs6N0pA727pxxu 2iXT00JRD55Y8PDTLdlGC1vzv4sYEQz/AHKw6ecTgm4MZ5qmkQKt30lNLzyZFkFSmrYR ErSWdP6jUFZTa3Cq59rYGZ9NA9kz4h5xgbQ69se71P1Jx2K/1cL4rrn0608BNFBZokG3 g69A== X-Gm-Message-State: AO0yUKXKcALTjVWUhoJrgZkgK4mRrMJ8vOgoRtLQkNwBZCuikueiCdGY TBwXhjeJif94jlOgxSQq0VqesqgpwA/5hQ== X-Google-Smtp-Source: AK7set/qa5S/bcbJH4e0MhNvMUM+1qfZoDm2V33bcRfoDlM9nsMNLBNiuaCpiqV4YMnOWut2nvSj5w== X-Received: by 2002:a17:903:18d:b0:199:1996:71ec with SMTP id z13-20020a170903018d00b00199199671ecmr103090plg.16.1676409970766; Tue, 14 Feb 2023 13:26:10 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:10 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , Christoph Hellwig , "Darrick J . Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 05/10] xfs: validate v5 feature fields Date: Tue, 14 Feb 2023 13:25:29 -0800 Message-Id: <20230214212534.1420323-6-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit f0f5f658065a5af09126ec892e4c383540a1c77f ] We don't check that the v4 feature flags taht v5 requires to be set are actually set anywhere. Do this check when we see that the filesystem is a v5 filesystem. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_sb.c | 68 +++++++++++++++++++++++++++++++++++------- 1 file changed, 58 insertions(+), 10 deletions(-) diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index 72c05485c870..04e2a57313fa 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++ b/fs/xfs/libxfs/xfs_sb.c @@ -30,6 +30,47 @@ * Physical superblock buffer manipulations. Shared with libxfs in userspace. */ +/* + * Check that all the V4 feature bits that the V5 filesystem format requires are + * correctly set. + */ +static bool +xfs_sb_validate_v5_features( + struct xfs_sb *sbp) +{ + /* We must not have any unknown V4 feature bits set */ + if (sbp->sb_versionnum & ~XFS_SB_VERSION_OKBITS) + return false; + + /* + * The CRC bit is considered an invalid V4 flag, so we have to add it + * manually to the OKBITS mask. + */ + if (sbp->sb_features2 & ~(XFS_SB_VERSION2_OKBITS | + XFS_SB_VERSION2_CRCBIT)) + return false; + + /* Now check all the required V4 feature flags are set. */ + +#define V5_VERS_FLAGS (XFS_SB_VERSION_NLINKBIT | \ + XFS_SB_VERSION_ALIGNBIT | \ + XFS_SB_VERSION_LOGV2BIT | \ + XFS_SB_VERSION_EXTFLGBIT | \ + XFS_SB_VERSION_DIRV2BIT | \ + XFS_SB_VERSION_MOREBITSBIT) + +#define V5_FEAT_FLAGS (XFS_SB_VERSION2_LAZYSBCOUNTBIT | \ + XFS_SB_VERSION2_ATTR2BIT | \ + XFS_SB_VERSION2_PROJID32BIT | \ + XFS_SB_VERSION2_CRCBIT) + + if ((sbp->sb_versionnum & V5_VERS_FLAGS) != V5_VERS_FLAGS) + return false; + if ((sbp->sb_features2 & V5_FEAT_FLAGS) != V5_FEAT_FLAGS) + return false; + return true; +} + /* * We support all XFS versions newer than a v4 superblock with V2 directories. */ @@ -37,9 +78,19 @@ bool xfs_sb_good_version( struct xfs_sb *sbp) { - /* all v5 filesystems are supported */ + /* + * All v5 filesystems are supported, but we must check that all the + * required v4 feature flags are enabled correctly as the code checks + * those flags and not for v5 support. + */ if (xfs_sb_is_v5(sbp)) - return true; + return xfs_sb_validate_v5_features(sbp); + + /* We must not have any unknown v4 feature bits set */ + if ((sbp->sb_versionnum & ~XFS_SB_VERSION_OKBITS) || + ((sbp->sb_versionnum & XFS_SB_VERSION_MOREBITSBIT) && + (sbp->sb_features2 & ~XFS_SB_VERSION2_OKBITS))) + return false; /* versions prior to v4 are not supported */ if (XFS_SB_VERSION_NUM(sbp) < XFS_SB_VERSION_4) @@ -51,12 +102,6 @@ xfs_sb_good_version( if (!(sbp->sb_versionnum & XFS_SB_VERSION_EXTFLGBIT)) return false; - /* And must not have any unknown v4 feature bits set */ - if ((sbp->sb_versionnum & ~XFS_SB_VERSION_OKBITS) || - ((sbp->sb_versionnum & XFS_SB_VERSION_MOREBITSBIT) && - (sbp->sb_features2 & ~XFS_SB_VERSION2_OKBITS))) - return false; - /* It's a supported v4 filesystem */ return true; } @@ -264,12 +309,15 @@ xfs_validate_sb_common( bool has_dalign; if (!xfs_verify_magic(bp, dsb->sb_magicnum)) { - xfs_warn(mp, "bad magic number"); + xfs_warn(mp, +"Superblock has bad magic number 0x%x. Not an XFS filesystem?", + be32_to_cpu(dsb->sb_magicnum)); return -EWRONGFS; } if (!xfs_sb_good_version(sbp)) { - xfs_warn(mp, "bad version"); + xfs_warn(mp, +"Superblock has unknown features enabled or corrupted feature masks."); return -EWRONGFS; } From patchwork Tue Feb 14 21:25:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140864 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 0D405C6FD18 for ; Tue, 14 Feb 2023 21:27:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232836AbjBNV1M (ORCPT ); Tue, 14 Feb 2023 16:27:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbjBNV1L (ORCPT ); Tue, 14 Feb 2023 16:27:11 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50DCF298C1; Tue, 14 Feb 2023 13:26:35 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id e17so9504252plg.12; Tue, 14 Feb 2023 13:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=F67ZEsFHmg5bEOyWUasxb3V34Kww6nIyBNz8EfnDjrE=; b=k5zvv+Eut2USYNdayngc61hRQ3iE11uh/SrzxXyxrzYHfxPWUYLdT4zoNR3C+HhNhG +NGXc7FrzeN+2U0Ar/GpMbRPeuPlau86HXJ56gkb8IvfwEJe2ETypaEILeXGowmwtT7u eafketX7vi41CxVr5Yieaa2CDh4YkaIDbZe0UzeYbpJTIDfagNjGeQGqd0DBDmpXSPVb nyehNIXRflIBgSUCGIfgGR3ESjvJgY4juld4ELGSTnaIk53wzBtr3HQhu4cNWgo+qe7c 2kDoqIOTHvrfucJL4oiLqGKs4rCl5I+0nxzokwERNY86Yr9mUBJNorayTJHfJxI8KN5h FuUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F67ZEsFHmg5bEOyWUasxb3V34Kww6nIyBNz8EfnDjrE=; b=YuAE7Phk5QzqivZdMPQtcQNtuYyDx6JgflPwCL8kaewRVLT5fWaitnI30LPY6/RHfQ ExaX9TbQRVo4n/HFf3J8zIwEVvyZWn0005pO2VTU8Zmrim9iV2KGyIvEfa1q2rvEbkUx WOqCIkhamPTPa/6PWej9+ETTXyjd7gnpLoFHTQqjtXcngvzj8f459dXNB3PNtGungu7J DJUps7ZuutVfP94hWFOXE9sC/cxxCaHhrNQqkyGUtJrc4StzmuUlxZRxA8JvOcQTzTWN 74ceQE4Rs1zQ0jqRZ/CA3QTCwe8QMSEBy1kwvRS5+4eeswIzjqvWI7AQC3PcBJCXX0Bc 4egw== X-Gm-Message-State: AO0yUKV8i8PunbnrfQmU/EfibZmCwvp6paChHzubnCCO8t4mph/DC8pn l0dMzZ2zvQMPnrp/RG8yFIjeKbxhe08q2Q== X-Google-Smtp-Source: AK7set/qhfpBSI+8S1A+jumK7jo5nwZ7WhaFoVboEUauEcIqPnOxfbS7kaSKt3zinIHCxHeOnS9a8w== X-Received: by 2002:a17:902:dacb:b0:196:22d5:6583 with SMTP id q11-20020a170902dacb00b0019622d56583mr89503plx.32.1676409972070; Tue, 14 Feb 2023 13:26:12 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:11 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , kernel test robot , "Darrick J . Wong" , Christoph Hellwig , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 06/10] xfs: avoid unnecessary runtime sibling pointer endian conversions Date: Tue, 14 Feb 2023 13:25:30 -0800 Message-Id: <20230214212534.1420323-7-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit 5672225e8f2a872a22b0cecedba7a6644af1fb84 ] Commit dc04db2aa7c9 has caused a small aim7 regression, showing a small increase in CPU usage in __xfs_btree_check_sblock() as a result of the extra checking. This is likely due to the endian conversion of the sibling poitners being unconditional instead of relying on the compiler to endian convert the NULL pointer at compile time and avoiding the runtime conversion for this common case. Rework the checks so that endian conversion of the sibling pointers is only done if they are not null as the original code did. .... and these need to be "inline" because the compiler completely fails to inline them automatically like it should be doing. $ size fs/xfs/libxfs/xfs_btree.o* text data bss dec hex filename 51874 240 0 52114 cb92 fs/xfs/libxfs/xfs_btree.o.orig 51562 240 0 51802 ca5a fs/xfs/libxfs/xfs_btree.o.inline Just when you think the tools have advanced sufficiently we don't have to care about stuff like this anymore, along comes a reminder that *our tools still suck*. Fixes: dc04db2aa7c9 ("xfs: detect self referencing btree sibling pointers") Reported-by: kernel test robot Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_btree.c | 47 +++++++++++++++++++++++++++------------ 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index 5bec048343b0..b4b5bf4bfed7 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -51,16 +51,31 @@ xfs_btree_magic( return magic; } -static xfs_failaddr_t +/* + * These sibling pointer checks are optimised for null sibling pointers. This + * happens a lot, and we don't need to byte swap at runtime if the sibling + * pointer is NULL. + * + * These are explicitly marked at inline because the cost of calling them as + * functions instead of inlining them is about 36 bytes extra code per call site + * on x86-64. Yes, gcc-11 fails to inline them, and explicit inlining of these + * two sibling check functions reduces the compiled code size by over 300 + * bytes. + */ +static inline xfs_failaddr_t xfs_btree_check_lblock_siblings( struct xfs_mount *mp, struct xfs_btree_cur *cur, int level, xfs_fsblock_t fsb, - xfs_fsblock_t sibling) + __be64 dsibling) { - if (sibling == NULLFSBLOCK) + xfs_fsblock_t sibling; + + if (dsibling == cpu_to_be64(NULLFSBLOCK)) return NULL; + + sibling = be64_to_cpu(dsibling); if (sibling == fsb) return __this_address; if (level >= 0) { @@ -74,17 +89,21 @@ xfs_btree_check_lblock_siblings( return NULL; } -static xfs_failaddr_t +static inline xfs_failaddr_t xfs_btree_check_sblock_siblings( struct xfs_mount *mp, struct xfs_btree_cur *cur, int level, xfs_agnumber_t agno, xfs_agblock_t agbno, - xfs_agblock_t sibling) + __be32 dsibling) { - if (sibling == NULLAGBLOCK) + xfs_agblock_t sibling; + + if (dsibling == cpu_to_be32(NULLAGBLOCK)) return NULL; + + sibling = be32_to_cpu(dsibling); if (sibling == agbno) return __this_address; if (level >= 0) { @@ -136,10 +155,10 @@ __xfs_btree_check_lblock( fsb = XFS_DADDR_TO_FSB(mp, xfs_buf_daddr(bp)); fa = xfs_btree_check_lblock_siblings(mp, cur, level, fsb, - be64_to_cpu(block->bb_u.l.bb_leftsib)); + block->bb_u.l.bb_leftsib); if (!fa) fa = xfs_btree_check_lblock_siblings(mp, cur, level, fsb, - be64_to_cpu(block->bb_u.l.bb_rightsib)); + block->bb_u.l.bb_rightsib); return fa; } @@ -204,10 +223,10 @@ __xfs_btree_check_sblock( } fa = xfs_btree_check_sblock_siblings(mp, cur, level, agno, agbno, - be32_to_cpu(block->bb_u.s.bb_leftsib)); + block->bb_u.s.bb_leftsib); if (!fa) fa = xfs_btree_check_sblock_siblings(mp, cur, level, agno, - agbno, be32_to_cpu(block->bb_u.s.bb_rightsib)); + agbno, block->bb_u.s.bb_rightsib); return fa; } @@ -4517,10 +4536,10 @@ xfs_btree_lblock_verify( /* sibling pointer verification */ fsb = XFS_DADDR_TO_FSB(mp, xfs_buf_daddr(bp)); fa = xfs_btree_check_lblock_siblings(mp, NULL, -1, fsb, - be64_to_cpu(block->bb_u.l.bb_leftsib)); + block->bb_u.l.bb_leftsib); if (!fa) fa = xfs_btree_check_lblock_siblings(mp, NULL, -1, fsb, - be64_to_cpu(block->bb_u.l.bb_rightsib)); + block->bb_u.l.bb_rightsib); return fa; } @@ -4574,10 +4593,10 @@ xfs_btree_sblock_verify( agno = xfs_daddr_to_agno(mp, xfs_buf_daddr(bp)); agbno = xfs_daddr_to_agbno(mp, xfs_buf_daddr(bp)); fa = xfs_btree_check_sblock_siblings(mp, NULL, -1, agno, agbno, - be32_to_cpu(block->bb_u.s.bb_leftsib)); + block->bb_u.s.bb_leftsib); if (!fa) fa = xfs_btree_check_sblock_siblings(mp, NULL, -1, agno, agbno, - be32_to_cpu(block->bb_u.s.bb_rightsib)); + block->bb_u.s.bb_rightsib); return fa; } From patchwork Tue Feb 14 21:25:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140865 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 7CC27C6379F for ; Tue, 14 Feb 2023 21:27:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232820AbjBNV1P (ORCPT ); Tue, 14 Feb 2023 16:27:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232890AbjBNV1O (ORCPT ); Tue, 14 Feb 2023 16:27:14 -0500 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BE99303EF; Tue, 14 Feb 2023 13:26:38 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id w14-20020a17090a5e0e00b00233d3b9650eso46863pjf.4; Tue, 14 Feb 2023 13:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=f1te54KzFMmr35wDNb6ewvvz32i8ozDTSolMMbFNyKQ=; b=Tfyz0CxXZ4reVhTSDwWEpdP6e0yHQbU0+PLlamkDb3/XRVP1RslEymCHjDZYvQe4J3 1ofS4JQ2F38hTLJVv/HDymWMGTns/28nArBCrFYREwTJdMUeh+oTaZY+JCKvPVEN3VAV l8wIdFaUvKsxNiW6yIW/V4g/QwDWVUUZVb4iREg0zBf2zdQiZ0KUGwegvLVHOdQcR5TI tuw6buGQyZU5g1sx++T/RBWYAP0WIMkYdxr6GXC5POZh5H8YuVczFeKFcszVAu9qs3TO NEILNY3Uyc2s2I29xIbFfnOnTCf8zZvWcIcrLUUGPmARbsrUQh8VnwDKWQG48Ka56/vn nqpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=f1te54KzFMmr35wDNb6ewvvz32i8ozDTSolMMbFNyKQ=; b=dTslH1kEH4b4t3qYWAxM6f1b2/xTi/KY1fBvJHSuxv6H0OiPZucg9+cIEtFuozbegs XwvRILMQ/H3IkhGwSxtXrXxljS0uc+SBG1hYzls3UuI0TMCj48OMn3g7G+7pRrNKe1F6 KXRRO2U5micEShoVMpqM0fWDaeesNIjqtvHH7J58n5vwPsSUlyFoau9Djh9OuCBLQcZN jX8qpGWdQ+FXL+98rp13iDWNsctbXRb3IcymsJTizCxjFV93wQ1tJObV/xTMsRzmia5d DF0F/NT2E+iIoaC9QoR6xgVIcEAgeRDZa0h/qRhXW+PZS3JJZQClMl/xunHrFlaVbllY mrNA== X-Gm-Message-State: AO0yUKWLoXqcyJO7AuO1o3ipPTBEgsxjlXttX4VvUazXX7GhNZsSaSUE uMsz/ej0yPVWLSXtsH6kGXYiz3elPtYeow== X-Google-Smtp-Source: AK7set+NO0BrwIo8RUvnLhH6sjGXt0LNHVaLjZYljckdl2BZTvDTnmB6A/xavAx3hElK0VfBMjRyDw== X-Received: by 2002:a17:902:c641:b0:19a:b35d:dde5 with SMTP id s1-20020a170902c64100b0019ab35ddde5mr113473pls.6.1676409973106; Tue, 14 Feb 2023 13:26:13 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:12 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 07/10] xfs: don't assert fail on perag references on teardown Date: Tue, 14 Feb 2023 13:25:31 -0800 Message-Id: <20230214212534.1420323-8-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit 5b55cbc2d72632e874e50d2e36bce608e55aaaea ] Not fatal, the assert is there to catch developer attention. I'm seeing this occasionally during recoveryloop testing after a shutdown, and I don't want this to stop an overnight recoveryloop run as it is currently doing. Convert the ASSERT to a XFS_IS_CORRUPT() check so it will dump a corruption report into the log and cause a test failure that way, but it won't stop the machine dead. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_ag.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/xfs/libxfs/xfs_ag.c b/fs/xfs/libxfs/xfs_ag.c index 005abfd9fd34..aff6fb5281f6 100644 --- a/fs/xfs/libxfs/xfs_ag.c +++ b/fs/xfs/libxfs/xfs_ag.c @@ -173,7 +173,6 @@ __xfs_free_perag( struct xfs_perag *pag = container_of(head, struct xfs_perag, rcu_head); ASSERT(!delayed_work_pending(&pag->pag_blockgc_work)); - ASSERT(atomic_read(&pag->pag_ref) == 0); kmem_free(pag); } @@ -192,7 +191,7 @@ xfs_free_perag( pag = radix_tree_delete(&mp->m_perag_tree, agno); spin_unlock(&mp->m_perag_lock); ASSERT(pag); - ASSERT(atomic_read(&pag->pag_ref) == 0); + XFS_IS_CORRUPT(pag->pag_mount, atomic_read(&pag->pag_ref) != 0); cancel_delayed_work_sync(&pag->pag_blockgc_work); xfs_iunlink_destroy(pag); From patchwork Tue Feb 14 21:25:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140866 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 4C054C61DA4 for ; Tue, 14 Feb 2023 21:27:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232932AbjBNV1S (ORCPT ); Tue, 14 Feb 2023 16:27:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232341AbjBNV1P (ORCPT ); Tue, 14 Feb 2023 16:27:15 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 400B21C580; Tue, 14 Feb 2023 13:26:39 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id n20-20020a17090aab9400b00229ca6a4636so103184pjq.0; Tue, 14 Feb 2023 13:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7pBezWEv5JYaH0rJ9igZpBfQr2zzlapuvLblecnISxw=; b=jQLMOBLOwZCJU8jWtiMsD/oWxkgnQk0ClgUt7y5aiD5yvM5A1eC65MkPWBwv8beKe9 gveek6QI6V4cb3f+V2vwBwwrVuGOTJbdTatY/ovT3/75yJTDcN0i4XzJS7glZv5Jh5kp fiZPQRolwNdp6VcjG9pUHCSnHVOoAu0ySuMZe8BpoRiy/qSRoM24GNJHUhDmqC0VFhq+ kVR+CQdhKEdIDPcfJfg7v9UcUkQTBWMmpAFiQ8L8XQNXTpLMRa/JBlCzAOVYqHS99JvP /m+DBd6C9dUtu5ScLE8iQ1QmvMCrrNrxKeNvux2YuCbYN/ox/lWlLNov/IFIdYKMwJQg 0mkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7pBezWEv5JYaH0rJ9igZpBfQr2zzlapuvLblecnISxw=; b=0rJXYJ5Y4Gfc9jVV4xxuIo3HdhdkqTJe2A3mODdVyUiO070i/o9p+hhBozT1UgRrPg oFZ7aKCAQZuoLFEoL0upM4lhyrUrHJAQGDNdycVBmUY1ZYa8KfxYJ2uykMt856DEYe9Z ad08M4KR9mOc59rwmPvDVwIpvJ+9ZkapNc9qhFHOZkNpkrul0ZulEdRlLIBnqs5hQdiZ NXs3Z406BnTZI/LPY75Gmc21S1nwsqBi2mYSfJQZHLiq13qhTkSXSxgsrjqy73UKi38n cPwpYCgG8R1ktrbKTiBzxJ5aiGmY5QpNXnNHQl6iXjHGwUyhiozpjlff8ccGIeK6qG47 TrEg== X-Gm-Message-State: AO0yUKWZsugxrYtbjrBlCmhhNhaxS3NevMOayiXav7gOjB3g0bKXszxk 0CWj/jR8pmrWu/0Vic+BoybMzRvws/uMhw== X-Google-Smtp-Source: AK7set/iVbirS5ppQ3hkiQV54K+LfxPFVAvDMoo9ut2SxblnYt0oresbvwOj3qlKIySJ0GS52MGQtA== X-Received: by 2002:a17:903:200a:b0:198:fc0a:192b with SMTP id s10-20020a170903200a00b00198fc0a192bmr27112pla.64.1676409974395; Tue, 14 Feb 2023 13:26:14 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:13 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 08/10] xfs: assert in xfs_btree_del_cursor should take into account error Date: Tue, 14 Feb 2023 13:25:32 -0800 Message-Id: <20230214212534.1420323-9-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit 56486f307100e8fc66efa2ebd8a71941fa10bf6f ] xfs/538 on a 1kB block filesystem failed with this assert: XFS: Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_ino.allocated == 0 || xfs_is_shutdown(cur->bc_mp), file: fs/xfs/libxfs/xfs_btree.c, line: 448 The problem was that an allocation failed unexpectedly in xfs_bmbt_alloc_block() after roughly 150,000 minlen allocation error injections, resulting in an EFSCORRUPTED error being returned to xfs_bmapi_write(). The error occurred on extent-to-btree format conversion allocating the new root block: RIP: 0010:xfs_bmbt_alloc_block+0x177/0x210 Call Trace: xfs_btree_new_iroot+0xdf/0x520 xfs_btree_make_block_unfull+0x10d/0x1c0 xfs_btree_insrec+0x364/0x790 xfs_btree_insert+0xaa/0x210 xfs_bmap_add_extent_hole_real+0x1fe/0x9a0 xfs_bmapi_allocate+0x34c/0x420 xfs_bmapi_write+0x53c/0x9c0 xfs_alloc_file_space+0xee/0x320 xfs_file_fallocate+0x36b/0x450 vfs_fallocate+0x148/0x340 __x64_sys_fallocate+0x3c/0x70 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa Why the allocation failed at this point is unknown, but is likely that we ran the transaction out of reserved space and filesystem out of space with bmbt blocks because of all the minlen allocations being done causing worst case fragmentation of a large allocation. Regardless of the cause, we've then called xfs_bmapi_finish() which calls xfs_btree_del_cursor(cur, error) to tear down the cursor. So we have a failed operation, error != 0, cur->bc_ino.allocated > 0 and the filesystem is still up. The assert fails to take into account that allocation can fail with an error and the transaction teardown will shut the filesystem down if necessary. i.e. the assert needs to check "|| error != 0" as well, because at this point shutdown is pending because the current transaction is dirty.... Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_btree.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index b4b5bf4bfed7..482a4ccc6568 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -445,8 +445,14 @@ xfs_btree_del_cursor( break; } + /* + * If we are doing a BMBT update, the number of unaccounted blocks + * allocated during this cursor life time should be zero. If it's not + * zero, then we should be shut down or on our way to shutdown due to + * cancelling a dirty transaction on error. + */ ASSERT(cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_ino.allocated == 0 || - xfs_is_shutdown(cur->bc_mp)); + xfs_is_shutdown(cur->bc_mp) || error != 0); if (unlikely(cur->bc_flags & XFS_BTREE_STAGING)) kmem_free(cur->bc_ops); if (!(cur->bc_flags & XFS_BTREE_LONG_PTRS) && cur->bc_ag.pag) From patchwork Tue Feb 14 21:25:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140868 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 520D7C64ED6 for ; Tue, 14 Feb 2023 21:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232341AbjBNV1T (ORCPT ); Tue, 14 Feb 2023 16:27:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232918AbjBNV1Q (ORCPT ); Tue, 14 Feb 2023 16:27:16 -0500 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4B69303F7; Tue, 14 Feb 2023 13:26:39 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id v23so18378693plo.1; Tue, 14 Feb 2023 13:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hWHvXlH6c22+sRRcZ28NH0kxoU0BU+g37g3tI50FneA=; b=bHlXfqemrhwGLJt6S8eMf7MPu2BSL3eSlo/Np0wqlDZd+DunMUlQnoPUYX91zy89kU xfw23yawGwJsWwQFzCgOdJhJhuOv7tGc8F4rmJJ+AXYth2c72NTIkJFigILc9LGsRoFE j0UBY6Tmlr2snou5oyHYwjWPzj1FVfycREHYuyZ8ji6NYWA1IHVFzXFH8NYEW90YuSxp XB/GoTXjP/ah+ZekK6Uq2uxliIyL2znCdsslrcQT+ORLjgc7CjBTbg1ET3rISFvZRNrp jYxvjLaeTyMWI4ppjmnqLWQFdlSxxTHoOOU9crD+5lteL79iI4NqxGl0AJNvIhL1yWlM coFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hWHvXlH6c22+sRRcZ28NH0kxoU0BU+g37g3tI50FneA=; b=poZhkrrwvsVx1szYxIEdBEdSqtzOvzxjBqVSGG7j6cGT36ns3AVeoiJBEl6Eez5CEd GgUo+fPiCMibX2fms8UB8NQKDJCW+B5K3784RjAUvjOVCsQFm04yvSETO6FR7tpZ/imz COTwGiFg4//ttWg1ScfO5mSdjqi/Mm42XvM0gUazL1yFSjaSMu7IWY9NszK8EksLZZ+D khbr15pkh3gVfVuynvEcvVubWZn62+OFrsJE7J12/kVOslMyxzhdfo64tuBtTLnXT0a8 I92jLihnrdt3i3zJ98wjF4bdweDL7MtzzPZ6taEjxCH4IdMt1vmd8ujRzAt/ml7nDcCq uoGA== X-Gm-Message-State: AO0yUKW4lf7MkThC2PoIjOGOzSQFRbGL4Un0fi9aCuGxATmhP3GCtm6P sQm/713GLnSkn7Fh81eXxOP4ZbZdh3XK0w== X-Google-Smtp-Source: AK7set8xiNQeJvsI6KnYpjlOMHSZu2Y/MJueMbFL6v/qXPPX/CEaCWtFl1ypvNFCZc8axcDZOh0jAA== X-Received: by 2002:a17:902:ecc6:b0:19a:b4a9:9df7 with SMTP id a6-20020a170902ecc600b0019ab4a99df7mr35446plh.53.1676409975684; Tue, 14 Feb 2023 13:26:15 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:15 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 09/10] xfs: purge dquots after inode walk fails during quotacheck Date: Tue, 14 Feb 2023 13:25:33 -0800 Message-Id: <20230214212534.1420323-10-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 86d40f1e49e9a909d25c35ba01bea80dbcd758cb ] xfs/434 and xfs/436 have been reporting occasional memory leaks of xfs_dquot objects. These tests themselves were the messenger, not the culprit, since they unload the xfs module, which trips the slub debugging code while tearing down all the xfs slab caches: ============================================================================= BUG xfs_dquot (Tainted: G W ): Objects remaining in xfs_dquot on __kmem_cache_shutdown() ----------------------------------------------------------------------------- Slab 0xffffea000606de00 objects=30 used=5 fp=0xffff888181b78a78 flags=0x17ff80000010200(slab|head|node=0|zone=2|lastcpupid=0xfff) CPU: 0 PID: 3953166 Comm: modprobe Tainted: G W 5.18.0-rc6-djwx #rc6 d5824be9e46a2393677bda868f9b154d917ca6a7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20171121_152543-x86-ol7-builder-01.us.oracle.com-4.el7.1 04/01/2014 Since we don't generally rmmod the xfs module between fstests, this means that xfs/434 is really just the canary in the coal mine -- something leaked a dquot, but we don't know who. After days of pounding on fstests with kmemleak enabled, I finally got it to spit this out: unreferenced object 0xffff8880465654c0 (size 536): comm "u10:4", pid 88, jiffies 4294935810 (age 29.512s) hex dump (first 32 bytes): 60 4a 56 46 80 88 ff ff 58 ea e4 5c 80 88 ff ff `JVF....X..\.... 00 e0 52 49 80 88 ff ff 01 00 01 00 00 00 00 00 ..RI............ backtrace: [] xfs_dquot_alloc+0x2c/0x530 [xfs] [] xfs_qm_dqread+0x6f/0x330 [xfs] [] xfs_qm_dqget+0x132/0x4e0 [xfs] [] xfs_qm_quotacheck_dqadjust+0xa0/0x3e0 [xfs] [] xfs_qm_dqusage_adjust+0x35d/0x4f0 [xfs] [] xfs_iwalk_ag_recs+0x348/0x5d0 [xfs] [] xfs_iwalk_run_callbacks+0x273/0x540 [xfs] [] xfs_iwalk_ag+0x5ed/0x890 [xfs] [] xfs_iwalk_ag_work+0xff/0x170 [xfs] [] xfs_pwork_work+0x79/0x130 [xfs] [] process_one_work+0x672/0x1040 [] worker_thread+0x59b/0xec0 [] kthread+0x29e/0x340 [] ret_from_fork+0x1f/0x30 Now we know that quotacheck is at fault, but even this report was canaryish -- it was triggered by xfs/494, which doesn't actually mount any filesystems. (kmemleak can be a little slow to notice leaks, even with fstests repeatedly whacking it to look for them.) Looking at the *previous* fstest, however, showed that the test run before xfs/494 was xfs/117. The tipoff to the problem is in this excerpt from dmesg: XFS (sda4): Quotacheck needed: Please wait. XFS (sda4): Metadata corruption detected at xfs_dinode_verify.part.0+0xdb/0x7b0 [xfs], inode 0x119 dinode XFS (sda4): Unmount and run xfs_repair XFS (sda4): First 128 bytes of corrupted metadata buffer: 00000000: 49 4e 81 a4 03 02 00 00 00 00 00 00 00 00 00 00 IN.............. 00000010: 00 00 00 01 00 00 00 00 00 90 57 54 54 1a 4c 68 ..........WTT.Lh 00000020: 81 f9 7d e1 6d ee 16 00 34 bd 7d e1 6d ee 16 00 ..}.m...4.}.m... 00000030: 34 bd 7d e1 6d ee 16 00 00 00 00 00 00 00 00 00 4.}.m........... 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 02 00 00 00 00 00 00 00 00 96 80 f3 ab ................ 00000060: ff ff ff ff da 57 7b 11 00 00 00 00 00 00 00 03 .....W{......... 00000070: 00 00 00 01 00 00 00 10 00 00 00 00 00 00 00 08 ................ XFS (sda4): Quotacheck: Unsuccessful (Error -117): Disabling quotas. The dinode verifier decided that the inode was corrupt, which causes iget to return with EFSCORRUPTED. Since this happened during quotacheck, it is obvious that the kernel aborted the inode walk on account of the corruption error and disabled quotas. Unfortunately, we neglect to purge the dquot cache before doing that, which is how the dquots leaked. The problems started 10 years ago in commit b84a3a, when the dquot lists were converted to a radix tree, but the error handling behavior was not correctly preserved -- in that commit, if the bulkstat failed and usrquota was enabled, the bulkstat failure code would be overwritten by the result of flushing all the dquots to disk. As long as that succeeds, we'd continue the quota mount as if everything were ok, but instead we're now operating with a corrupt inode and incorrect quota usage counts. I didn't notice this bug in 2019 when I wrote commit ebd126a, which changed quotacheck to skip the dqflush when the scan doesn't complete due to inode walk failures. Introduced-by: b84a3a96751f ("xfs: remove the per-filesystem list of dquots") Fixes: ebd126a651f8 ("xfs: convert quotacheck to use the new iwalk functions") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_qm.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c index 5608066d6e53..623244650a2f 100644 --- a/fs/xfs/xfs_qm.c +++ b/fs/xfs/xfs_qm.c @@ -1317,8 +1317,15 @@ xfs_qm_quotacheck( error = xfs_iwalk_threaded(mp, 0, 0, xfs_qm_dqusage_adjust, 0, true, NULL); - if (error) + if (error) { + /* + * The inode walk may have partially populated the dquot + * caches. We must purge them before disabling quota and + * tearing down the quotainfo, or else the dquots will leak. + */ + xfs_qm_dqpurge_all(mp); goto error_return; + } /* * We've made all the changes that we need to make incore. Flush them From patchwork Tue Feb 14 21:25:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13140867 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 BD5FBC6379F for ; Tue, 14 Feb 2023 21:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232956AbjBNV1T (ORCPT ); Tue, 14 Feb 2023 16:27:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232890AbjBNV1Q (ORCPT ); Tue, 14 Feb 2023 16:27:16 -0500 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EAB32107; Tue, 14 Feb 2023 13:26:40 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id ja21so10764590plb.13; Tue, 14 Feb 2023 13:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=jZIp7USMvmmqB5f9NmVrSQj28kTFZM5zKd61/LPwcFk=; b=gbkb0p23ODyB/KVw7h8ZXEn0zBgKG2kCYMXtaLIMU/Ca9pcmAjnqwl7mopVImnZvYb boDeqH0aUaLAXIm8Gg3XPRdQWNIrHVm/oOVNAc9eWCkkMB0r8+QMCvJcH+UXddI0mPkg dBuELBIZPxeKdJBQ1tzR61UJan5bgqdbdHnTTIP9U6AO2ulKZ7O+k6y2UmWLXZYegNES S13UgDogThNTzvvOoGBj1AQLmjr3RjUujSuQ9VJlWlZRkGcUpQPS9ozVI7GYPQ1X1pMB fXVgTgWMhwQ9/bYaXm7N+qPKlxvwtjm3xXIQnkEJ5NvtHK/zz/z9xDQ4NeML+WJ0PRgc 3zvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jZIp7USMvmmqB5f9NmVrSQj28kTFZM5zKd61/LPwcFk=; b=VXhkbHLT72l9T1B8UiIrAulbCBchHUQS4CUc1Y3aRdbWC+seweJKKMzp3q+S3BkmlM EZJ4ZQS2A/L8dojpN1ALl5NllJDsYG6+pMgKfRGmuOO+xDbLqNOWSiOnfa9+sRe+nS8p 58R8+mpDNL3YRvCloY3HQ+yU3U/slvgC9SdgU2ezXtgioVKId9jRGgTwL3NOQ0pnLbw1 P032DfH35QNibNe5yoPGXby+DGci5OI/p7vAuZntv6MJJBmNl1Z0GMQWNjwZ7BMyhS/3 /PFLR0z4/wKr1Feqgqv7SJ097TvFGAe1/xy084vC2T/R9tr72TjQwIujpKXgS99uj4m5 Nemw== X-Gm-Message-State: AO0yUKWlCGgOOq/vhbArHPLwfKKkFKY44aXMslEJ5sckF+LNcw/mwTzG xHEQEY8oc6cwUbiWZNm04eHxNhUdCUWX5g== X-Google-Smtp-Source: AK7set9yb2lRi9+zjzzTmKpjlOphnWF/mIGOpSPyGj5vmWKmg9BXPJItMJsUDsuOWP2xRsMjhud57g== X-Received: by 2002:a17:902:f68f:b0:198:def1:62cc with SMTP id l15-20020a170902f68f00b00198def162ccmr145537plg.2.1676409976797; Tue, 14 Feb 2023 13:26:16 -0800 (PST) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:cf14:3756:2b5e:fb87]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b00195f0fb0c18sm6692569pln.31.2023.02.14.13.26.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 13:26:16 -0800 (PST) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 10/10] xfs: don't leak btree cursor when insrec fails after a split Date: Tue, 14 Feb 2023 13:25:34 -0800 Message-Id: <20230214212534.1420323-11-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog In-Reply-To: <20230214212534.1420323-1-leah.rumancik@gmail.com> References: <20230214212534.1420323-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit a54f78def73d847cb060b18c4e4a3d1d26c9ca6d ] The recent patch to improve btree cycle checking caused a regression when I rebased the in-memory btree branch atop the 5.19 for-next branch, because in-memory short-pointer btrees do not have AG numbers. This produced the following complaint from kmemleak: unreferenced object 0xffff88803d47dde8 (size 264): comm "xfs_io", pid 4889, jiffies 4294906764 (age 24.072s) hex dump (first 32 bytes): 90 4d 0b 0f 80 88 ff ff 00 a0 bd 05 80 88 ff ff .M.............. e0 44 3a a0 ff ff ff ff 00 df 08 06 80 88 ff ff .D:............. backtrace: [] xfbtree_dup_cursor+0x49/0xc0 [xfs] [] xfs_btree_dup_cursor+0x3b/0x200 [xfs] [] __xfs_btree_split+0x6ad/0x820 [xfs] [] xfs_btree_split+0x60/0x110 [xfs] [] xfs_btree_make_block_unfull+0x19a/0x1f0 [xfs] [] xfs_btree_insrec+0x3aa/0x810 [xfs] [] xfs_btree_insert+0xb3/0x240 [xfs] [] xfs_rmap_insert+0x99/0x200 [xfs] [] xfs_rmap_map_shared+0x192/0x5f0 [xfs] [] xfs_rmap_map_raw+0x6b/0x90 [xfs] [] xrep_rmap_stash+0xd5/0x1d0 [xfs] [] xrep_rmap_visit_bmbt+0xa0/0xf0 [xfs] [] xrep_rmap_scan_iext+0x56/0xa0 [xfs] [] xrep_rmap_scan_ifork+0xd8/0x160 [xfs] [] xrep_rmap_scan_inode+0x35/0x80 [xfs] [] xrep_rmap_find_rmaps+0x10e/0x270 [xfs] I noticed that xfs_btree_insrec has a bunch of debug code that return out of the function immediately, without freeing the "new" btree cursor that can be returned when _make_block_unfull calls xfs_btree_split. Fix the error return in this function to free the btree cursor. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_btree.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index 482a4ccc6568..dffe4ca58493 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -3266,7 +3266,7 @@ xfs_btree_insrec( struct xfs_btree_block *block; /* btree block */ struct xfs_buf *bp; /* buffer for block */ union xfs_btree_ptr nptr; /* new block ptr */ - struct xfs_btree_cur *ncur; /* new btree cursor */ + struct xfs_btree_cur *ncur = NULL; /* new btree cursor */ union xfs_btree_key nkey; /* new block key */ union xfs_btree_key *lkey; int optr; /* old key/record index */ @@ -3346,7 +3346,7 @@ xfs_btree_insrec( #ifdef DEBUG error = xfs_btree_check_block(cur, block, level, bp); if (error) - return error; + goto error0; #endif /* @@ -3366,7 +3366,7 @@ xfs_btree_insrec( for (i = numrecs - ptr; i >= 0; i--) { error = xfs_btree_debug_check_ptr(cur, pp, i, level); if (error) - return error; + goto error0; } xfs_btree_shift_keys(cur, kp, 1, numrecs - ptr + 1); @@ -3451,6 +3451,8 @@ xfs_btree_insrec( return 0; error0: + if (ncur) + xfs_btree_del_cursor(ncur, error); return error; }