From patchwork Wed Jul 13 01:09:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12915873 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 04276C43334 for ; Wed, 13 Jul 2022 01:09:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232823AbiGMBJp (ORCPT ); Tue, 12 Jul 2022 21:09:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230491AbiGMBJo (ORCPT ); Tue, 12 Jul 2022 21:09:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36660C9130 for ; Tue, 12 Jul 2022 18:09:44 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C583E618C9 for ; Wed, 13 Jul 2022 01:09:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E205C3411E; Wed, 13 Jul 2022 01:09:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657674583; bh=zHgt8M39DaBHfbVsCo9H4gFPg6hQaSk5pclu/PWwmeQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=JrVfEAVyMJ+jyUNK3O3B3NNtAA40GsClMYKmv4pgXri9R6y2R4sUwAs3edNQbE1dq qBdVvq9VRHRI68y+mcDP8al2l4ZB4n5UzTPBVNmA1UCXo7MUMxFNeo0JgMp203OnJL JFf+82zZy8+JINApoBRnSl0v1cgnGZj0AOz7tx1eReFHGXM+EqSmIP1ugNMbgNyIr/ An+ow7rQyl5PFWldlQ9gpzSvvipAGyDevz87hJxUlejaCSLq8gonS4tLg/GTHMmBHN GTmjQSOpg7feDrhOEEBhsZ5kpoq4Vfh5oIguHFhWv7OXpS+3bJHyKQT8Ab+hn3NYIg 9yyDp/IlQmbyA== Subject: [PATCH 1/4] xfs_repair: ignore empty xattr leaf blocks From: "Darrick J. Wong" To: sandeen@sandeen.net, djwong@kernel.org Cc: linux-xfs@vger.kernel.org Date: Tue, 12 Jul 2022 18:09:42 -0700 Message-ID: <165767458269.891854.14449036597530410382.stgit@magnolia> In-Reply-To: <165767457703.891854.2108521135190969641.stgit@magnolia> References: <165767457703.891854.2108521135190969641.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong As detailed in the previous commit, empty xattr leaf blocks can be the benign byproduct of the system going down during the multi-step process of adding a large xattr to a file that has no xattrs. If we find one at attr fork offset 0, we should clear it, but this isn't a corruption. Signed-off-by: Darrick J. Wong --- repair/attr_repair.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 2055d96e..c3a6d502 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -579,6 +579,26 @@ process_leaf_attr_block( firstb = mp->m_sb.sb_blocksize; stop = xfs_attr3_leaf_hdr_size(leaf); + /* + * Empty leaf blocks at offset zero can occur as a race between + * setxattr and the system going down, so we only take action if we're + * running in modify mode. See xfs_attr3_leaf_verify for details of + * how we've screwed this up many times. + */ + if (!leafhdr.count && da_bno == 0) { + if (no_modify) { + do_log( + _("would clear empty leaf attr block 0, inode %" PRIu64 "\n"), + ino); + return 0; + } + + do_warn( + _("will clear empty leaf attr block 0, inode %" PRIu64 "\n"), + ino); + return 1; + } + /* does the count look sorta valid? */ if (!leafhdr.count || leafhdr.count * sizeof(xfs_attr_leaf_entry_t) + stop > From patchwork Wed Jul 13 01:09:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12915874 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 70082C43334 for ; Wed, 13 Jul 2022 01:09:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230491AbiGMBJz (ORCPT ); Tue, 12 Jul 2022 21:09:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232834AbiGMBJv (ORCPT ); Tue, 12 Jul 2022 21:09:51 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C486D0397 for ; Tue, 12 Jul 2022 18:09:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6B1B8618CC for ; Wed, 13 Jul 2022 01:09:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C03D9C341C0; Wed, 13 Jul 2022 01:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657674588; bh=ss/rI7le1p8mwTPLA1Hy5fvy6lEaMlKBSD/kzEWWznI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=iDIY4Ht6oSBXhX+RtUwCPUkAFl+kUCfGoirdySsdQaFt6A/l+BujC2IOfoG/l15se D4iuzCV0QtKzu+2KjZMaydIL/a5EVF5Co23ENFdx1TFKOUaamJ0uwJSKMWqA6CV15h idjK/fz/HtkxhejfLtNqoej7vOJvw38sETpGzjiUWqWn0Xz5Sk0DtJahzdDIDJivRJ NQah/W6vusYSSpGXJ/qW8rGmTbltpt9rqzbtW6KCB9JoY3k2ZShkvpvWk6+H6RiaWX F6B5eGUNK7WuGBQMpEPTDimQOKdwejLz0G1C9OJSLtCnNLBUUNr37DCxxO+g+hLSQa DUOGCTkA0lRyA== Subject: [PATCH 2/4] xfs_repair: Search for conflicts in inode_tree_ptrs[] when processing uncertain inodes From: "Darrick J. Wong" To: sandeen@sandeen.net, djwong@kernel.org Cc: Chandan Babu R , linux-xfs@vger.kernel.org Date: Tue, 12 Jul 2022 18:09:48 -0700 Message-ID: <165767458835.891854.9721217597094009246.stgit@magnolia> In-Reply-To: <165767457703.891854.2108521135190969641.stgit@magnolia> References: <165767457703.891854.2108521135190969641.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Chandan Babu R When processing an uncertain inode chunk record, if we lose 2 blocks worth of inodes or 25% of the chunk, xfs_repair decides to ignore the chunk. Otherwise, xfs_repair adds a new chunk record to inode_tree_ptrs[agno], marking each inode as either free or used. However, before adding the new chunk record, xfs_repair has to check for the existance of a conflicting record. The existing code incorrectly checks for the conflicting record in inode_uncertain_tree_ptrs[agno]. This check will succeed since the inode chunk record being processed was originally obtained from inode_uncertain_tree_ptrs[agno]. This commit fixes the bug by changing xfs_repair to search inode_tree_ptrs[agno] for conflicts. Signed-off-by: Chandan Babu R Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong --- repair/dino_chunks.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/repair/dino_chunks.c b/repair/dino_chunks.c index 11b0eb5f..80c52a43 100644 --- a/repair/dino_chunks.c +++ b/repair/dino_chunks.c @@ -229,8 +229,7 @@ verify_inode_chunk(xfs_mount_t *mp, /* * ok, put the record into the tree, if no conflict. */ - if (find_uncertain_inode_rec(agno, - XFS_AGB_TO_AGINO(mp, start_agbno))) + if (find_inode_rec(mp, agno, XFS_AGB_TO_AGINO(mp, start_agbno))) return(0); start_agino = XFS_AGB_TO_AGINO(mp, start_agbno); From patchwork Wed Jul 13 01:09:53 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12915875 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 44FF7CCA47F for ; Wed, 13 Jul 2022 01:09:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231322AbiGMBJ5 (ORCPT ); Tue, 12 Jul 2022 21:09:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232833AbiGMBJ4 (ORCPT ); Tue, 12 Jul 2022 21:09:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78A59C9128 for ; Tue, 12 Jul 2022 18:09:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1272E618CD for ; Wed, 13 Jul 2022 01:09:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65ABBC3411E; Wed, 13 Jul 2022 01:09:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657674594; bh=nbBf7JjaeNH12QruEGFcXfHUA8yI8IFv1NKFHvB9GTc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=AATGEaOOBLEhNk4yi88hSAZB+yBWWJSJr3tzKm9k8hqX/T8PixpfOOBgRhus1k43X 3+CiORTZPq9mJFfNJ4fskW1KD58iwlpQjxcqoaUy/SqXaWXyI2ViwW4iLPndRbuBnZ iDKiIGT6gQeOZrW8B8WqR7ezqtgoj9HZbPAVNCl8SOt8uR9jmMvyfoRb2qYF3bp2f2 plSY8QpS0GCwbVj43y+KUGI23NwUJq9XX/npQLWJzwywn+CZNY1ZFGsNXCkFfdVlxC /kYiu2PSobF7DNceG+mlL/A/WecYSlzKgKUcPbvjMXINJQ5WFrRA6RZ5eqkn3lrOY5 o888FFfoyvI0A== Subject: [PATCH 3/4] mkfs: complain about impossible log size constraints From: "Darrick J. Wong" To: sandeen@sandeen.net, djwong@kernel.org Cc: linux-xfs@vger.kernel.org Date: Tue, 12 Jul 2022 18:09:53 -0700 Message-ID: <165767459394.891854.2338822152912053034.stgit@magnolia> In-Reply-To: <165767457703.891854.2108521135190969641.stgit@magnolia> References: <165767457703.891854.2108521135190969641.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong xfs/042 trips over an impossible fs geometry when nrext64 is enabled. The minimum log size calculation comes out to 4287 blocks, but the mkfs parameters specify an AG size of 4096 blocks. This eventually causes mkfs to complain that the autoselected log size doesn't meet the minimum size, but we could be a little more explicit in pointing out that the two size constraints make for an impossible geometry. Signed-off-by: Darrick J. Wong --- mkfs/xfs_mkfs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index db322b3a..61ac1a4a 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -3401,6 +3401,13 @@ _("external log device size %lld blocks too small, must be at least %lld blocks\ * an AG. */ max_logblocks = libxfs_alloc_ag_max_usable(mp) - 1; + if (max_logblocks < min_logblocks) { + fprintf(stderr, +_("max log size %d smaller than min log size %d\n"), + max_logblocks, + min_logblocks); + usage(); + } /* internal log - if no size specified, calculate automatically */ if (!cfg->logblocks) { From patchwork Wed Jul 13 01:09:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12915876 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 62E36C43334 for ; Wed, 13 Jul 2022 01:10:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231672AbiGMBKC (ORCPT ); Tue, 12 Jul 2022 21:10:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231567AbiGMBKB (ORCPT ); Tue, 12 Jul 2022 21:10:01 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12062CEB8C for ; Tue, 12 Jul 2022 18:10:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A4230618CD for ; Wed, 13 Jul 2022 01:10:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08E55C3411E; Wed, 13 Jul 2022 01:10:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657674600; bh=CQPNrqiDvFNpUIrSoRVT9Mjl3ing8zxzCYljsacsPso=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=beK9wFq5zOe7kQTIbieaULLOBxEIJhUkazOKGMN4ZbW08r8Tn2s3iJsaG4Bsa0Eij 1x0LkqKNMsdjOwW8Ccz/CfHeOTy0UyH+BaFWVs0XErjpCDV30I7oYWv1DuIguwUlv0 d7AhudbYLgEh+0s9eWYBVovjhZ88hBhfQYR3qRQGPy/UReL23rjK2tU43AnsKuB8hW KydM44QdCVhXJRDqBnNSm6WjWBmQaLK7blTZVJ8PLx9pZ3Fnl/65ihwV/VdcAyW9AU vo/Vvd0fTDeO0btBRcjVsAlIkERU5iLo0DWOe9XmLCZTqj0YUJSitjvI6lZlzHHFM6 HYrv+fDbQ15Yg== Subject: [PATCH 4/4] mkfs: terminate getsubopt arrays properly From: "Darrick J. Wong" To: sandeen@sandeen.net, djwong@kernel.org Cc: linux-xfs@vger.kernel.org Date: Tue, 12 Jul 2022 18:09:59 -0700 Message-ID: <165767459958.891854.15344618102582353193.stgit@magnolia> In-Reply-To: <165767457703.891854.2108521135190969641.stgit@magnolia> References: <165767457703.891854.2108521135190969641.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong Having not drank any (or maybe too much) coffee this morning, I typed: $ mkfs.xfs -d agcount=3 -d nrext64=0 Segmentation fault I traced this down to getsubopt walking off the end of the dopts.subopts array. The manpage says you're supposed to terminate the suboptions string array with a NULL entry, but the structure definition uses MAX_SUBOPTS/D_MAX_OPTS directly, which means there is no terminator. Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen --- mkfs/xfs_mkfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index 61ac1a4a..9a58ff8b 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -141,7 +141,7 @@ enum { }; /* Just define the max options array size manually right now */ -#define MAX_SUBOPTS D_MAX_OPTS +#define MAX_SUBOPTS (D_MAX_OPTS + 1) #define SUBOPT_NEEDS_VAL (-1LL) #define MAX_CONFLICTS 8