From patchwork Wed Jun 1 10:45:40 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866675 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 277BDC433FE for ; Wed, 1 Jun 2022 10:46:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352333AbiFAKqC (ORCPT ); Wed, 1 Jun 2022 06:46:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352264AbiFAKp7 (ORCPT ); Wed, 1 Jun 2022 06:45:59 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48888813C6; Wed, 1 Jun 2022 03:45:56 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id z17so737458wmf.1; Wed, 01 Jun 2022 03:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=dTtVKM9UT0CLXD1zwfcjWb0IVAoLGPcfVYgpuoOmr9I=; b=f7DxPeDuS8HGSyat8Ed08BgrgGjpLdyuBfoh6GpcEHsdj0t1uSwCjMeWJ44L6jDpjL ICH4FVLIlmkb97ICah1qsJlTJyVSeCprbh42N7FStXOS7gJJcWjt6/C2X7s73bKDzWsO pxrlRICgDKJHOUoezTEYdYL1e7kPQn4kDPcIGrsyLwPRsZhqizjNHqLTChByHEydj93I VeWprcatXOiO6HOGTMdHxSg9BYjnSYwYKAEq3d77ViQHdK7hMSq74huilwum30QAAGSM 5Sh4NEbH1PP51nAclMvZhIWasbwfgSlAYlV+nJ29FAi1b1JfJteKZU3NDXcxfXsCVfxR fKfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dTtVKM9UT0CLXD1zwfcjWb0IVAoLGPcfVYgpuoOmr9I=; b=jsDUEodCqLTkPSPISl4QdktW8JaMf9aVfCmQrXiYOeBedAgokpMz7hGI83zrxyu+Ec 42vVHtpJA0ZY4MUI63k/M4f+N3O89MkYhbX6Vkze9uOMpDGJHzdAIaK0SNwHOeeIaqHS WKd/bFo/XypFV62afnkz+4EteR1RIiWgMbglnRijidwByLdySHI21kt95h0mLUfSjxho HN0cyRas01JnnoVoPEfymgFpH42wbLEt8vN7khu31f+PKLKcKCgX7W+to31dkQnAUxy4 BntxL9rkFRWb6YRi/GFltWs2Ca3JosOULR1ow0OzEdC2Z9zVLEj+r86viMnxhUPT62kS 9HMQ== X-Gm-Message-State: AOAM532gGAfsSc6d3HqZ5x5PNAIi7/3MA64ZsVALwJoKaUPq6uOnhEsB WLk+nr7tFZJBpEhx+BtSaZc= X-Google-Smtp-Source: ABdhPJxSSaYbxMlqeAvyOWjTvhw3BpQAGjxNPmTKLqJlSjVA4egLp8rO1W2CyNU3o/+h1+pAxiQgVg== X-Received: by 2002:a05:600c:1e2a:b0:397:780a:b7f1 with SMTP id ay42-20020a05600c1e2a00b00397780ab7f1mr27948417wmb.188.1654080354517; Wed, 01 Jun 2022 03:45:54 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.45.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:45:54 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Christian Brauner Subject: [PATCH 5.10 CANDIDATE 1/8] xfs: fix up non-directory creation in SGID directories Date: Wed, 1 Jun 2022 13:45:40 +0300 Message-Id: <20220601104547.260949-2-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Christoph Hellwig commit 01ea173e103edd5ec41acec65b9261b87e123fc2 upstream. XFS always inherits the SGID bit if it is set on the parent inode, while the generic inode_init_owner does not do this in a few cases where it can create a possible security problem, see commit 0fa3ecd87848 ("Fix up non-directory creation in SGID directories") for details. Switch XFS to use the generic helper for the normal path to fix this, just keeping the simple field inheritance open coded for the case of the non-sgid case with the bsdgrpid mount option. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Christian Brauner Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein --- fs/xfs/xfs_inode.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index e958b1c74561..e20d8af80216 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -802,6 +802,7 @@ xfs_ialloc( xfs_buf_t **ialloc_context, xfs_inode_t **ipp) { + struct inode *dir = pip ? VFS_I(pip) : NULL; struct xfs_mount *mp = tp->t_mountp; xfs_ino_t ino; xfs_inode_t *ip; @@ -847,18 +848,17 @@ xfs_ialloc( return error; ASSERT(ip != NULL); inode = VFS_I(ip); - inode->i_mode = mode; set_nlink(inode, nlink); - inode->i_uid = current_fsuid(); inode->i_rdev = rdev; ip->i_d.di_projid = prid; - if (pip && XFS_INHERIT_GID(pip)) { - inode->i_gid = VFS_I(pip)->i_gid; - if ((VFS_I(pip)->i_mode & S_ISGID) && S_ISDIR(mode)) - inode->i_mode |= S_ISGID; + if (dir && !(dir->i_mode & S_ISGID) && + (mp->m_flags & XFS_MOUNT_GRPID)) { + inode->i_uid = current_fsuid(); + inode->i_gid = dir->i_gid; + inode->i_mode = mode; } else { - inode->i_gid = current_fsgid(); + inode_init_owner(inode, dir, mode); } /* From patchwork Wed Jun 1 10:45:41 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866677 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 67F8DC433F5 for ; Wed, 1 Jun 2022 10:46:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352419AbiFAKqN (ORCPT ); Wed, 1 Jun 2022 06:46:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352373AbiFAKqC (ORCPT ); Wed, 1 Jun 2022 06:46:02 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08D6281488; Wed, 1 Jun 2022 03:45:57 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id r9-20020a1c4409000000b00397345f2c6fso2763148wma.4; Wed, 01 Jun 2022 03:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DxI+KP/yP2c1dj72ZEf9XEZoYdpFMxSLMCxGwNL12Ug=; b=SSchd4ou2Qrd6oY3fcHH5+g1IFPuS2tvK+hrbnb0JWstRhc6AFH/rL8JMdhvkgLlHC ZQnMiyzGdrmz7zxpZycbRjhZEnAlUnJikj921NXo9WhKDeRM0kPeZPqyRt6mhnkAKbsI NhofRNZAJ21B7ZW5mb9Ai94DP+J2+9SpDz+IpdJvwY3nB4MzAnlQqeHAOb0wrmKZObkn GBtqfOkfPP4tTdFfs1Id/G/8oEw5QO47M4f+k1aXXd9RayTalDf/DDddsRI6HaQXdF2i F+DTcjHCU8Z7OBScDLfQe4v/NRF06Q1ZL9KBUJXXmLEqTHUZ+eLMUm4D+/7DzYFdeeSO 2Fnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DxI+KP/yP2c1dj72ZEf9XEZoYdpFMxSLMCxGwNL12Ug=; b=BFIiz/KM1W3luy1/ZGZPwQmlubkBqcbzZfiwhH17tRj8hCuFF89TZhmt7jwKoXMQt+ rKKqK5TZI0vBq6W5vbRuCXMhU0KzpqtL4bXJ4zze/aqFq+tZcQiiUNuDjawvWct/RckP NBvQqigj1m1GMxTgoMRVR2as2pD5A1w6PEldw3OwJDdcstXDp0ZZlM8ZlfXLXiPl0M26 HcnssYxeHRdgc4EKvC0FSoIkj3cclXRY4aRsHAVTr/y/vy6KsCSip/mS/SdQpG84N6jL w1ORKoOBzvBBLPrNJfwG4LSOBy54KiaP440teC6NLqFyjRitlApbcZMGbm51N9AzbYp5 pI6g== X-Gm-Message-State: AOAM5327pu9VgwsvIYmGKduWisjAt1dcQdZujNv37mxgTW02y0p7wV8p dGBs2jxL82GTUkLvvB505rI= X-Google-Smtp-Source: ABdhPJzBklGwj5Q+1v+rSCE4Qoyh0XYrgDTRYeslp8/xMqxEL+ImMzqNLyht0DgmF0I/9DJivB4GZw== X-Received: by 2002:a05:600c:350f:b0:397:7204:ce8e with SMTP id h15-20020a05600c350f00b003977204ce8emr27969597wmq.0.1654080356056; Wed, 01 Jun 2022 03:45:56 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.45.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:45:55 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Jeffrey Mitchell Subject: [PATCH 5.10 CANDIDATE 2/8] xfs: set inode size after creating symlink Date: Wed, 1 Jun 2022 13:45:41 +0300 Message-Id: <20220601104547.260949-3-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Jeffrey Mitchell commit 8aa921a95335d0a8c8e2be35a44467e7c91ec3e4 upstream. When XFS creates a new symlink, it writes its size to disk but not to the VFS inode. This causes i_size_read() to return 0 for that symlink until it is re-read from disk, for example when the system is rebooted. I found this inconsistency while protecting directories with eCryptFS. The command "stat path/to/symlink/in/ecryptfs" will report "Size: 0" if the symlink was created after the last reboot on an XFS root. Call i_size_write() in xfs_symlink() Signed-off-by: Jeffrey Mitchell Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Brian Foster Signed-off-by: Amir Goldstein --- fs/xfs/xfs_symlink.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c index 8e88a7ca387e..8d3abf06c54f 100644 --- a/fs/xfs/xfs_symlink.c +++ b/fs/xfs/xfs_symlink.c @@ -300,6 +300,7 @@ xfs_symlink( } ASSERT(pathlen == 0); } + i_size_write(VFS_I(ip), ip->i_d.di_size); /* * Create the directory entry for the symlink. From patchwork Wed Jun 1 10:45:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866683 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 03F3DC433F5 for ; Wed, 1 Jun 2022 10:46:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238933AbiFAKqr (ORCPT ); Wed, 1 Jun 2022 06:46:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352371AbiFAKqD (ORCPT ); Wed, 1 Jun 2022 06:46:03 -0400 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F2A3814AA; Wed, 1 Jun 2022 03:45:59 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id q21so1782180wra.2; Wed, 01 Jun 2022 03:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KtH8GLMcafEYSB20tONa+zJ9ioX5tusX1ZCZq7mMdkA=; b=OYiJF8IkYWo+pvv/QFkFP37snbX/mqn8II0s1X8xQb2d35XFOiBAuh488BYDaN7FDg gyTtI8HcppUQ1pZdoujy4P4EScBFCkFlmJS1akp6EdX8xTQKVJe+kfztdBygPZ1919vG A2FIAkseEcp2LBCllYtD/egpd1I+TC8WR56DpmUxDlWNq3oWgNmG0m0meLXkQGt4FHop TUQ4+s0eQrky7IkUOJrOifw7a2qjOPGOpb1BGbzYQP7ablN1aP3/Kb/6amGcon74uO8m oQZqkqcjxNg85hILHWggRsit71WmaLbcwG+Af2R49HiBn2oTcKUQy5a4DSwKNMxI1fXb LUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KtH8GLMcafEYSB20tONa+zJ9ioX5tusX1ZCZq7mMdkA=; b=Gtt/VtAnUhvW7Wqs1ITxw1CEsvBjwraw1cshEmXcggxiqu98Za10Q1/78AfMJwUop0 u/N1rzrV8zZgsXZ5jEXYJBGeOnShLc1hpivtpMcaVRr9jnKMpBMZScQkiMvv4qDxZC85 qAI1ft6sBXnhaE56fhJmf+9Sx9iGfSCu9hrwNkIjMuQZ0/CcdrHFG9HLfu+5Uvh6rDzH jbcFgbBWReANx235t7tSe0JHJ/4M4ZvSTI3H0MCS+8QOSPhIT4NWHWQ14m2/+DY4o2j6 W3YS86Yfp/msX6UbmYJIgUPORaVT8EEZOASwSKMAv04mDi+cmJ+LRWsN7jo0BEqeYsRi yg1A== X-Gm-Message-State: AOAM531b2woo9K7sUAKxMhq0x8blde/Gco1xiZL8yuq8zP5qKsP6kna7 X5ZtV5lXNX8iKiCkdLD5V08= X-Google-Smtp-Source: ABdhPJzq97m2fnUxvb1nKJQb59FtkhhKuNlswE1bx6aje3nVxPUXzUGUTvIdAdlF9BSdk4kZNzVeRw== X-Received: by 2002:adf:e8c3:0:b0:210:3dc0:6c8 with SMTP id k3-20020adfe8c3000000b002103dc006c8mr2649016wrn.611.1654080357827; Wed, 01 Jun 2022 03:45:57 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.45.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:45:57 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Gao Xiang , Allison Henderson , "Darrick J . Wong" , Bill O'Donnell Subject: [PATCH 5.10 CANDIDATE 3/8] xfs: sync lazy sb accounting on quiesce of read-only mounts Date: Wed, 1 Jun 2022 13:45:42 +0300 Message-Id: <20220601104547.260949-4-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Brian Foster commit 50d25484bebe94320c49dd1347d3330c7063bbdb upstream. xfs_log_sbcount() syncs the superblock specifically to accumulate the in-core percpu superblock counters and commit them to disk. This is required to maintain filesystem consistency across quiesce (freeze, read-only mount/remount) or unmount when lazy superblock accounting is enabled because individual transactions do not update the superblock directly. This mechanism works as expected for writable mounts, but xfs_log_sbcount() skips the update for read-only mounts. Read-only mounts otherwise still allow log recovery and write out an unmount record during log quiesce. If a read-only mount performs log recovery, it can modify the in-core superblock counters and write an unmount record when the filesystem unmounts without ever syncing the in-core counters. This leaves the filesystem with a clean log but in an inconsistent state with regard to lazy sb counters. Update xfs_log_sbcount() to use the same logic xfs_log_unmount_write() uses to determine when to write an unmount record. This ensures that lazy accounting is always synced before the log is cleaned. Refactor this logic into a new helper to distinguish between a writable filesystem and a writable log. Specifically, the log is writable unless the filesystem is mounted with the norecovery mount option, the underlying log device is read-only, or the filesystem is shutdown. Drop the freeze state check because the update is already allowed during the freezing process and no context calls this function on an already frozen fs. Also, retain the shutdown check in xfs_log_unmount_write() to catch the case where the preceding log force might have triggered a shutdown. Signed-off-by: Brian Foster Reviewed-by: Gao Xiang Reviewed-by: Allison Henderson Reviewed-by: Darrick J. Wong Reviewed-by: Bill O'Donnell Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein --- fs/xfs/xfs_log.c | 28 ++++++++++++++++++++-------- fs/xfs/xfs_log.h | 1 + fs/xfs/xfs_mount.c | 3 +-- 3 files changed, 22 insertions(+), 10 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index fa2d05e65ff1..b445e63cbc3c 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -347,6 +347,25 @@ xlog_tic_add_region(xlog_ticket_t *tic, uint len, uint type) tic->t_res_num++; } +bool +xfs_log_writable( + struct xfs_mount *mp) +{ + /* + * Never write to the log on norecovery mounts, if the block device is + * read-only, or if the filesystem is shutdown. Read-only mounts still + * allow internal writes for log recovery and unmount purposes, so don't + * restrict that case here. + */ + if (mp->m_flags & XFS_MOUNT_NORECOVERY) + return false; + if (xfs_readonly_buftarg(mp->m_log->l_targ)) + return false; + if (XFS_FORCED_SHUTDOWN(mp)) + return false; + return true; +} + /* * Replenish the byte reservation required by moving the grant write head. */ @@ -886,15 +905,8 @@ xfs_log_unmount_write( { struct xlog *log = mp->m_log; - /* - * Don't write out unmount record on norecovery mounts or ro devices. - * Or, if we are doing a forced umount (typically because of IO errors). - */ - if (mp->m_flags & XFS_MOUNT_NORECOVERY || - xfs_readonly_buftarg(log->l_targ)) { - ASSERT(mp->m_flags & XFS_MOUNT_RDONLY); + if (!xfs_log_writable(mp)) return; - } xfs_log_force(mp, XFS_LOG_SYNC); diff --git a/fs/xfs/xfs_log.h b/fs/xfs/xfs_log.h index 58c3fcbec94a..98c913da7587 100644 --- a/fs/xfs/xfs_log.h +++ b/fs/xfs/xfs_log.h @@ -127,6 +127,7 @@ int xfs_log_reserve(struct xfs_mount *mp, int xfs_log_regrant(struct xfs_mount *mp, struct xlog_ticket *tic); void xfs_log_unmount(struct xfs_mount *mp); int xfs_log_force_umount(struct xfs_mount *mp, int logerror); +bool xfs_log_writable(struct xfs_mount *mp); struct xlog_ticket *xfs_log_ticket_get(struct xlog_ticket *ticket); void xfs_log_ticket_put(struct xlog_ticket *ticket); diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 7110507a2b6b..a62b8a574409 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -1176,8 +1176,7 @@ xfs_fs_writable( int xfs_log_sbcount(xfs_mount_t *mp) { - /* allow this to proceed during the freeze sequence... */ - if (!xfs_fs_writable(mp, SB_FREEZE_COMPLETE)) + if (!xfs_log_writable(mp)) return 0; /* From patchwork Wed Jun 1 10:45:43 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866678 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 66E40C433EF for ; Wed, 1 Jun 2022 10:46:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352424AbiFAKqO (ORCPT ); Wed, 1 Jun 2022 06:46:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352256AbiFAKqF (ORCPT ); Wed, 1 Jun 2022 06:46:05 -0400 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B42980201; Wed, 1 Jun 2022 03:46:01 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id t6so1772919wra.4; Wed, 01 Jun 2022 03:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=v9bZ/oogoWoPQX2w9BuFOFgcjiIV4xqYgwERl5n3obI=; b=JH3JN35t8gUIVD5gD/t3vR8XdbsMT2ectwVKGHqZFksdi+RXnhYrqMff3Qqy5XMzH2 9RsE02JwACIHx6sx2C3/dTXEhy2zVLBjtUAe+kjz/+zeCjn4EQYvWCmKWiu8klp6Knjf 3jCm519DH0+bRF4Sqvt+XWzYqVCNi9lZzK6ZzX7loLfjHg7aCpU3AvMBGlU/1cxliiQJ SexK/iF/+7ddSAlWKZ6kwZFb0FjDFCAEn/BGQUEUZ9OJWEZyFNpqVNh9eBEaRYTz3x/W qnjqxgBqLFKXu85hRC/rwDXBzB1crA2qZ4+B0ccEB7IxjBOHvfq11mQDmzuLf+bKFG2h ikGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=v9bZ/oogoWoPQX2w9BuFOFgcjiIV4xqYgwERl5n3obI=; b=fIa7EQKobK9eWiY6kCULWewuTvgjHoZNKVJANoLmfBA4+47Fl+8lSTe0EwbaBjiEXE Q9UaE4PBYw1AOt4oR0FNUTgPS8KdA0aLjzZIDipbNtJWhmy2JXtGyxobk38nvHJZoXJL BQnpU2+KonjDaU8OtOQpM1f7LdtGO/PrATClQU4HZ8AObDfjq8JwFO4uGvNALWNI1rWI osijb3aj790G/XdtSdCSMUi7JFJkQQRWBBxg72u8obe93owRQwis2klJDav/d4mBcQQA iW9pCUckbjgxTUsPr2ckeHUC77Ti7F79eLs8bSNb8hoH+Hep7xFOal9aP1e3LjXKyfuB o+Wg== X-Gm-Message-State: AOAM531Sw7tVPFbU94oAubU0UyJ+dqQvR+TTHUAUVUaeKlwwj9eRbjCL 7gWf/UApd3qkimvWatBGWoY= X-Google-Smtp-Source: ABdhPJylX4igljmylj1H+c7yVoc6LUNus4KHZ1YGMXQlZ70t1Wz98xKBKsZT3bP4LOukKZ85pNQfww== X-Received: by 2002:a05:6000:18aa:b0:20c:7ec0:b804 with SMTP id b10-20020a05600018aa00b0020c7ec0b804mr51558933wri.128.1654080359423; Wed, 01 Jun 2022 03:45:59 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.45.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:45:58 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org Subject: [PATCH 5.10 CANDIDATE 4/8] xfs: fix chown leaking delalloc quota blocks when fssetxattr fails Date: Wed, 1 Jun 2022 13:45:43 +0300 Message-Id: <20220601104547.260949-5-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: "Darrick J. Wong" commit 1aecf3734a95f3c167d1495550ca57556d33f7ec upstream. While refactoring the quota code to create a function to allocate inode change transactions, I noticed that xfs_qm_vop_chown_reserve does more than just make reservations: it also *modifies* the incore counts directly to handle the owner id change for the delalloc blocks. I then observed that the fssetxattr code continues validating input arguments after making the quota reservation but before dirtying the transaction. If the routine decides to error out, it fails to undo the accounting switch! This leads to incorrect quota reservation and failure down the line. We can fix this by making the reservation function do only that -- for the new dquot, it reserves ondisk and delalloc blocks to the transaction, and the old dquot hangs on to its incore reservation for now. Once we actually switch the dquots, we can then update the incore reservations because we've dirtied the transaction and it's too late to turn back now. No fixes tag because this has been broken since the start of git. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Brian Foster Signed-off-by: Amir Goldstein --- fs/xfs/xfs_qm.c | 92 +++++++++++++++++++------------------------------ 1 file changed, 35 insertions(+), 57 deletions(-) diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c index b2a9abee8b2b..64e5da33733b 100644 --- a/fs/xfs/xfs_qm.c +++ b/fs/xfs/xfs_qm.c @@ -1785,6 +1785,29 @@ xfs_qm_vop_chown( xfs_trans_mod_dquot(tp, newdq, bfield, ip->i_d.di_nblocks); xfs_trans_mod_dquot(tp, newdq, XFS_TRANS_DQ_ICOUNT, 1); + /* + * Back when we made quota reservations for the chown, we reserved the + * ondisk blocks + delalloc blocks with the new dquot. Now that we've + * switched the dquots, decrease the new dquot's block reservation + * (having already bumped up the real counter) so that we don't have + * any reservation to give back when we commit. + */ + xfs_trans_mod_dquot(tp, newdq, XFS_TRANS_DQ_RES_BLKS, + -ip->i_delayed_blks); + + /* + * Give the incore reservation for delalloc blocks back to the old + * dquot. We don't normally handle delalloc quota reservations + * transactionally, so just lock the dquot and subtract from the + * reservation. Dirty the transaction because it's too late to turn + * back now. + */ + tp->t_flags |= XFS_TRANS_DIRTY; + xfs_dqlock(prevdq); + ASSERT(prevdq->q_blk.reserved >= ip->i_delayed_blks); + prevdq->q_blk.reserved -= ip->i_delayed_blks; + xfs_dqunlock(prevdq); + /* * Take an extra reference, because the inode is going to keep * this dquot pointer even after the trans_commit. @@ -1807,84 +1830,39 @@ xfs_qm_vop_chown_reserve( uint flags) { struct xfs_mount *mp = ip->i_mount; - uint64_t delblks; unsigned int blkflags; - struct xfs_dquot *udq_unres = NULL; - struct xfs_dquot *gdq_unres = NULL; - struct xfs_dquot *pdq_unres = NULL; struct xfs_dquot *udq_delblks = NULL; struct xfs_dquot *gdq_delblks = NULL; struct xfs_dquot *pdq_delblks = NULL; - int error; - ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); ASSERT(XFS_IS_QUOTA_RUNNING(mp)); - delblks = ip->i_delayed_blks; blkflags = XFS_IS_REALTIME_INODE(ip) ? XFS_QMOPT_RES_RTBLKS : XFS_QMOPT_RES_REGBLKS; if (XFS_IS_UQUOTA_ON(mp) && udqp && - i_uid_read(VFS_I(ip)) != udqp->q_id) { + i_uid_read(VFS_I(ip)) != udqp->q_id) udq_delblks = udqp; - /* - * If there are delayed allocation blocks, then we have to - * unreserve those from the old dquot, and add them to the - * new dquot. - */ - if (delblks) { - ASSERT(ip->i_udquot); - udq_unres = ip->i_udquot; - } - } + if (XFS_IS_GQUOTA_ON(ip->i_mount) && gdqp && - i_gid_read(VFS_I(ip)) != gdqp->q_id) { + i_gid_read(VFS_I(ip)) != gdqp->q_id) gdq_delblks = gdqp; - if (delblks) { - ASSERT(ip->i_gdquot); - gdq_unres = ip->i_gdquot; - } - } if (XFS_IS_PQUOTA_ON(ip->i_mount) && pdqp && - ip->i_d.di_projid != pdqp->q_id) { + ip->i_d.di_projid != pdqp->q_id) pdq_delblks = pdqp; - if (delblks) { - ASSERT(ip->i_pdquot); - pdq_unres = ip->i_pdquot; - } - } - - error = xfs_trans_reserve_quota_bydquots(tp, ip->i_mount, - udq_delblks, gdq_delblks, pdq_delblks, - ip->i_d.di_nblocks, 1, flags | blkflags); - if (error) - return error; /* - * Do the delayed blks reservations/unreservations now. Since, these - * are done without the help of a transaction, if a reservation fails - * its previous reservations won't be automatically undone by trans - * code. So, we have to do it manually here. + * Reserve enough quota to handle blocks on disk and reserved for a + * delayed allocation. We'll actually transfer the delalloc + * reservation between dquots at chown time, even though that part is + * only semi-transactional. */ - if (delblks) { - /* - * Do the reservations first. Unreservation can't fail. - */ - ASSERT(udq_delblks || gdq_delblks || pdq_delblks); - ASSERT(udq_unres || gdq_unres || pdq_unres); - error = xfs_trans_reserve_quota_bydquots(NULL, ip->i_mount, - udq_delblks, gdq_delblks, pdq_delblks, - (xfs_qcnt_t)delblks, 0, flags | blkflags); - if (error) - return error; - xfs_trans_reserve_quota_bydquots(NULL, ip->i_mount, - udq_unres, gdq_unres, pdq_unres, - -((xfs_qcnt_t)delblks), 0, blkflags); - } - - return 0; + return xfs_trans_reserve_quota_bydquots(tp, ip->i_mount, udq_delblks, + gdq_delblks, pdq_delblks, + ip->i_d.di_nblocks + ip->i_delayed_blks, + 1, blkflags | flags); } int From patchwork Wed Jun 1 10:45:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866679 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 1D41FC433FE for ; Wed, 1 Jun 2022 10:46:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352372AbiFAKqW (ORCPT ); Wed, 1 Jun 2022 06:46:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352294AbiFAKqK (ORCPT ); Wed, 1 Jun 2022 06:46:10 -0400 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A2AA813D5; Wed, 1 Jun 2022 03:46:02 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id d26so1740209wrb.13; Wed, 01 Jun 2022 03:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1QqcTEPtoODTXKz5bXn/012pkjfLEsGJrtDgaQa4Ijw=; b=ge9YS57gzpsq8hhTTsZJ+/HY0QFDlvdxjE6nDvCWNIdMY5aqdJVF3kD4ErsAlWUsO2 +Pdg+jRpXaXGLarElYQjN1FXUlqyDjsDAJqCqtKyNVVv+oUxzoMXVZE+Gdp67l8XMpeo 9P47Pngw45r272hQcKUeH85fNNLM6qaVhiOGHJHzmhdisCYKlQyOQzG4Zfreu1OhEttM IGOhW94rIY7BSMMjEWRcZOXJydlv24cftWan7dWHbh4Iz1YdNtczJdFPHQaoZZOWDYF+ eqdDPJHzMxSUhF+K+8goGQmbwrnXODIMWjjBxEosxCL62E13e1ly71xE7SZj15yVznOG ouRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1QqcTEPtoODTXKz5bXn/012pkjfLEsGJrtDgaQa4Ijw=; b=7611VmRhGcyzTGEM67ZqiQW9387pnMsHXch4t1XvdhhfDxVdSn8ledjjIYQApr0Fy0 J+b7TvYEV2PG2+MMDYrXucbJsQuBmcx0eGVXQbxg900P8MQA2aJdpfy9wbIuVsVlKKbU tqee8/G80z5Cp2rnfr8JXJCZjAQI1qKyT7JKLw8sBMpAsvwwrFGCcXthYUTRJzccSwUT M+PMhZSQT8bqu4qTOI9xXizTtV18QGMSsMr5arLKZJUoMk3m+7JEpv4hCJmfDndNfgDr g6ody4Q3B6lbmGNrPQQdATVbsXYXZzfI/nI+8KTO52gn9/mruKSsYYmcgncUcCRSuD/K Y5/A== X-Gm-Message-State: AOAM531ho+H0twMKd1D9M7tdV+jXAscVhSdv8z4tWacU6et6CfxGUSRy 5tcy/Du83aoQlnPEPtRlyWc= X-Google-Smtp-Source: ABdhPJyOaXPgqgziwE5Wcj2kcDEt0Y8NRW9ObIBSCQA36SprRKUu5Gf2S2d4WNi+er5G7fk4GvXJlg== X-Received: by 2002:a05:6000:1acd:b0:20f:d7df:a2a8 with SMTP id i13-20020a0560001acd00b0020fd7dfa2a8mr39815822wry.477.1654080361005; Wed, 01 Jun 2022 03:46:01 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.45.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:46:00 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Chandan Babu R Subject: [PATCH 5.10 CANDIDATE 5/8] xfs: fix incorrect root dquot corruption error when switching group/project quota types Date: Wed, 1 Jun 2022 13:45:44 +0300 Message-Id: <20220601104547.260949-6-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: "Darrick J. Wong" commit 45068063efb7dd0a8d115c106aa05d9ab0946257 upstream. While writing up a regression test for broken behavior when a chprojid request fails, I noticed that we were logging corruption notices about the root dquot of the group/project quota file at mount time when testing V4 filesystems. In commit afeda6000b0c, I was trying to improve ondisk dquot validation by making sure that when we load an ondisk dquot into memory on behalf of an incore dquot, the dquot id and type matches. Unfortunately, I forgot that V4 filesystems only have two quota files, and can switch that file between group and project quota types at mount time. When we perform that switch, we'll try to load the default quota limits from the root dquot prior to running quotacheck and log a corruption error when the types don't match. This is inconsequential because quotacheck will reset the second quota file as part of doing the switch, but we shouldn't leave scary messages in the kernel log. Fixes: afeda6000b0c ("xfs: validate ondisk/incore dquot flags") Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Reviewed-by: Chandan Babu R Signed-off-by: Amir Goldstein --- fs/xfs/xfs_dquot.c | 39 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_dquot.c b/fs/xfs/xfs_dquot.c index 1d95ed387d66..80c4579d6835 100644 --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -500,6 +500,42 @@ xfs_dquot_alloc( return dqp; } +/* Check the ondisk dquot's id and type match what the incore dquot expects. */ +static bool +xfs_dquot_check_type( + struct xfs_dquot *dqp, + struct xfs_disk_dquot *ddqp) +{ + uint8_t ddqp_type; + uint8_t dqp_type; + + ddqp_type = ddqp->d_type & XFS_DQTYPE_REC_MASK; + dqp_type = xfs_dquot_type(dqp); + + if (be32_to_cpu(ddqp->d_id) != dqp->q_id) + return false; + + /* + * V5 filesystems always expect an exact type match. V4 filesystems + * expect an exact match for user dquots and for non-root group and + * project dquots. + */ + if (xfs_sb_version_hascrc(&dqp->q_mount->m_sb) || + dqp_type == XFS_DQTYPE_USER || dqp->q_id != 0) + return ddqp_type == dqp_type; + + /* + * V4 filesystems support either group or project quotas, but not both + * at the same time. The non-user quota file can be switched between + * group and project quota uses depending on the mount options, which + * means that we can encounter the other type when we try to load quota + * defaults. Quotacheck will soon reset the the entire quota file + * (including the root dquot) anyway, but don't log scary corruption + * reports to dmesg. + */ + return ddqp_type == XFS_DQTYPE_GROUP || ddqp_type == XFS_DQTYPE_PROJ; +} + /* Copy the in-core quota fields in from the on-disk buffer. */ STATIC int xfs_dquot_from_disk( @@ -512,8 +548,7 @@ xfs_dquot_from_disk( * Ensure that we got the type and ID we were looking for. * Everything else was checked by the dquot buffer verifier. */ - if ((ddqp->d_type & XFS_DQTYPE_REC_MASK) != xfs_dquot_type(dqp) || - be32_to_cpu(ddqp->d_id) != dqp->q_id) { + if (!xfs_dquot_check_type(dqp, ddqp)) { xfs_alert_tag(bp->b_mount, XFS_PTAG_VERIFIER_ERROR, "Metadata corruption detected at %pS, quota %u", __this_address, dqp->q_id); From patchwork Wed Jun 1 10:45:45 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866680 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 BC1C2C433EF for ; Wed, 1 Jun 2022 10:46:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349344AbiFAKqZ (ORCPT ); Wed, 1 Jun 2022 06:46:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352392AbiFAKqM (ORCPT ); Wed, 1 Jun 2022 06:46:12 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE35082176; Wed, 1 Jun 2022 03:46:03 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id p10so1748211wrg.12; Wed, 01 Jun 2022 03:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SzyQsb1o4fSk85fpWvWY8/HRYw+PK4Y1RJ618LPBXOE=; b=RzG769fdg8raTun+uF0tVEDrp4nAp9ExnsLgDPRhpX3iU7p/C9+JgxA1g8MCuh9U+L CXS6+olCuALo70i+7qGPNvc+K6ZGk76vuAFkjGTvf32Gs3LnwCfrQBJqT5SfW9jKuky7 ISkcSC8Ic2nPg1CbAscD0EP7q5FT1ZQCO5c8Woxzy4vgRGO3eKmSzervHYFyciNMQ4nw GfXNwfAKJaNz9b/+MHxaiSfy5M+q7/6Zh5xPE0/hSnBGP9NQMFBR3dabqSZ7X0bEbrMH 0CZo7PqYRnofU8yzAb8YRP0DRpTsl7EAog7dnl/jvYwnCfq3SBfBsd5lCI+xEOCkI1cA x0Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SzyQsb1o4fSk85fpWvWY8/HRYw+PK4Y1RJ618LPBXOE=; b=z7S548PmR7oEc7V9qx3SUhRyFmlbtjYEj7yw3HsDnjtcjMn0YzHwQdoD/yOJi29gOz UPIPV13xLRTng2jD2HGIViwX8T+MPSJE7/Hqh5sSEDwp58fMOrNRQhOlwVPh8JGDUPK9 w6DYKU7G06TXlGb+2ubscmB87oqvbfH7e/GK5Hrwbv5wkzTAvAP3zu/zeUPHR4GmLqRu Xp7r+PxWXsGrZYv1IuNrA717ymySLJu9j4Uc8QJi+EZ47TpREkhvQW4r3mhN0pvbEdXJ GzID0HRPekl8GIlKKS1Ow+ShqY7BTxtfPML4XXX8OdXXcra7m3FMElWnvyTAnLGk3Ear JMvw== X-Gm-Message-State: AOAM532tHTvqoXxLMly94pWAY4xLEkObGDpFncn8sfgZc3k/i5ge7FZ9 TM5dwuuGQnpROTqZjKfh8vk= X-Google-Smtp-Source: ABdhPJxVktF5m5x2CT3UBq6WKXUJf5O+5QpGyqL5yUSHWy4+CxHwFz+Sdti5Fq6ndYZgz62W28uSQg== X-Received: by 2002:a5d:6b45:0:b0:210:514:579e with SMTP id x5-20020a5d6b45000000b002100514579emr27514375wrw.400.1654080362542; Wed, 01 Jun 2022 03:46:02 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.46.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:46:02 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Eric Sandeen Subject: [PATCH 5.10 CANDIDATE 6/8] xfs: restore shutdown check in mapped write fault path Date: Wed, 1 Jun 2022 13:45:45 +0300 Message-Id: <20220601104547.260949-7-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Brian Foster commit e4826691cc7e5458bcb659935d0092bcf3f08c20 upstream. XFS triggers an iomap warning in the write fault path due to a !PageUptodate() page if a write fault happens to occur on a page that recently failed writeback. The iomap writeback error handling code can clear the Uptodate flag if no portion of the page is submitted for I/O. This is reproduced by fstest generic/019, which combines various forms of I/O with simulated disk failures that inevitably lead to filesystem shutdown (which then unconditionally fails page writeback). This is a regression introduced by commit f150b4234397 ("xfs: split the iomap ops for buffered vs direct writes") due to the removal of a shutdown check and explicit error return in the ->iomap_begin() path used by the write fault path. The explicit error return historically translated to a SIGBUS, but now carries on with iomap processing where it complains about the unexpected state. Restore the shutdown check to xfs_buffered_write_iomap_begin() to restore historical behavior. Fixes: f150b4234397 ("xfs: split the iomap ops for buffered vs direct writes") Signed-off-by: Brian Foster Reviewed-by: Eric Sandeen Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein --- fs/xfs/xfs_iomap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 7b9ff824e82d..74bc2beadc23 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -870,6 +870,9 @@ xfs_buffered_write_iomap_begin( int allocfork = XFS_DATA_FORK; int error = 0; + if (XFS_FORCED_SHUTDOWN(mp)) + return -EIO; + /* we can't use delayed allocations when using extent size hints */ if (xfs_get_extsz_hint(ip)) return xfs_direct_write_iomap_begin(inode, offset, count, From patchwork Wed Jun 1 10:45:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866682 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 77DEEC433F5 for ; Wed, 1 Jun 2022 10:46:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352406AbiFAKqd (ORCPT ); Wed, 1 Jun 2022 06:46:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352397AbiFAKqM (ORCPT ); Wed, 1 Jun 2022 06:46:12 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D411A814B4; Wed, 1 Jun 2022 03:46:05 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id h62-20020a1c2141000000b0039aa4d054e2so2780247wmh.1; Wed, 01 Jun 2022 03:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=H8xbwTR16tvG4U/ddVZgdCLGD5EiTHqSz9fp9YwAxOk=; b=Q0b7TyXJI4zCLpmxgDcZKS6gSGJFCZ9kOQ+l1SYhd7Z5B3lI0x7mH0qai4YE8SiGYc fbwbv5kEEzSGhIzLzQc/oAy+cRNuPecBBTRyy6kcmGEa1DxPw/jP0JuN7mn2pPMgxGC8 eUj7idUCqCrMiZ/gJBoSJbGTea+gd8eg/RF421N3tTuABkm1eT1kf+Sk9Zeb0b0KHMtD hzA/jqib2sQabDHCxmtBsXEZ3hs+zyTAmygL1fbgMYcb0I76jbM9KILbW7oiu2ijwOtT foIS1y7EASu11kuOyC8OU151Z7t3n3KLgU7/SwEWMoGwhBQeXrnPlyjUR8dkyWcVChdO Yz+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=H8xbwTR16tvG4U/ddVZgdCLGD5EiTHqSz9fp9YwAxOk=; b=CGFKmmvbeRdgx1+Dw4k/hjtdqUNRAGVTucauqKpQnzJlcNp2C80tffdcRim+jNEl0v 0ObBpn2+Fxs9ac3rLXRMqs1pg3y3lwa74qNsJchi5Ccd8dBRqgHLd2wlCC062nyKx2zx o2SSJnHXeFtBWVH22V/bD+cxqpW3uuW1nMyCESKyKotpyH0vqWtnk72I4uT3YdDo0VAV M8WN7LGRZaCB6ciZktvCD+zQW56tCvbeYoYdN38nEerD86iCNfI6lS3oMEg07jSojFRI vueRL3ePqPV5qeVBBqqlri7Qv066ExdfWu4F2VJPfJaN+zJ4VpNy2RQv6PyUFfVfNd61 DEZg== X-Gm-Message-State: AOAM5303oFS9UaBASlf6s+DobMD3tTpe693zs2UadF3daFf3sL2PAY01 jKQrxSOzaDx3BjW2tpkUGJsj1hosoXH1nA== X-Google-Smtp-Source: ABdhPJzfstTQw50S3DeNDxhSnp4O983WemhFLKSkRUSXRxdPvg7+3xH5nL/UoaNNXGaMMw4djdypew== X-Received: by 2002:a05:600c:1c86:b0:39c:eeb:39a3 with SMTP id k6-20020a05600c1c8600b0039c0eeb39a3mr13973476wms.40.1654080364106; Wed, 01 Jun 2022 03:46:04 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.46.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:46:03 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org Subject: [PATCH 5.10 CANDIDATE 7/8] xfs: consider shutdown in bmapbt cursor delete assert Date: Wed, 1 Jun 2022 13:45:46 +0300 Message-Id: <20220601104547.260949-8-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Brian Foster commit 1cd738b13ae9b29e03d6149f0246c61f76e81fcf upstream. The assert in xfs_btree_del_cursor() checks that the bmapbt block allocation field has been handled correctly before the cursor is freed. This field is used for accurate calculation of indirect block reservation requirements (for delayed allocations), for example. generic/019 reproduces a scenario where this assert fails because the filesystem has shutdown while in the middle of a bmbt record insertion. This occurs after a bmbt block has been allocated via the cursor but before the higher level bmap function (i.e. xfs_bmap_add_extent_hole_real()) completes and resets the field. Update the assert to accommodate the transient state if the filesystem has shutdown. While here, clean up the indentation and comments in the function. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein --- fs/xfs/libxfs/xfs_btree.c | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index 2d25bab68764..9f9f9feccbcd 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -353,20 +353,17 @@ xfs_btree_free_block( */ void xfs_btree_del_cursor( - xfs_btree_cur_t *cur, /* btree cursor */ - int error) /* del because of error */ + struct xfs_btree_cur *cur, /* btree cursor */ + int error) /* del because of error */ { - int i; /* btree level */ + int i; /* btree level */ /* - * Clear the buffer pointers, and release the buffers. - * If we're doing this in the face of an error, we - * need to make sure to inspect all of the entries - * in the bc_bufs array for buffers to be unlocked. - * This is because some of the btree code works from - * level n down to 0, and if we get an error along - * the way we won't have initialized all the entries - * down to 0. + * Clear the buffer pointers and release the buffers. If we're doing + * this because of an error, inspect all of the entries in the bc_bufs + * array for buffers to be unlocked. This is because some of the btree + * code works from level n down to 0, and if we get an error along the + * way we won't have initialized all the entries down to 0. */ for (i = 0; i < cur->bc_nlevels; i++) { if (cur->bc_bufs[i]) @@ -374,17 +371,11 @@ xfs_btree_del_cursor( else if (!error) break; } - /* - * Can't free a bmap cursor without having dealt with the - * allocated indirect blocks' accounting. - */ - ASSERT(cur->bc_btnum != XFS_BTNUM_BMAP || - cur->bc_ino.allocated == 0); - /* - * Free the cursor. - */ + + ASSERT(cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_ino.allocated == 0 || + XFS_FORCED_SHUTDOWN(cur->bc_mp)); if (unlikely(cur->bc_flags & XFS_BTREE_STAGING)) - kmem_free((void *)cur->bc_ops); + kmem_free(cur->bc_ops); kmem_cache_free(xfs_btree_cur_zone, cur); } From patchwork Wed Jun 1 10:45:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12866681 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 0D176C433FE for ; Wed, 1 Jun 2022 10:46:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352399AbiFAKqa (ORCPT ); Wed, 1 Jun 2022 06:46:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352402AbiFAKqM (ORCPT ); Wed, 1 Jun 2022 06:46:12 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E86CC84A35; Wed, 1 Jun 2022 03:46:07 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id q7so1768066wrg.5; Wed, 01 Jun 2022 03:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=b2pvl9UHk0Z4rkTZyge+oGFzFbTSQ4HA4DjZnHNbMzc=; b=Oj57oflIWLIstVRtrdtOyhqk2wQfpCO4Gul0cfqenCE18Msr2ZOYrDdAfZh4MnxfzH sMseUWCfuGS9krRMGLn5tWphTRX9bJd2YZkfkR0wHcaqrDXTehb2hBQ0ovC77r8mPucf 3cEYvbzd9x9tJUWINaOZlOF/5k+OeuDrHL9eINY6OnSMM0MfS7aMlUYyleT8OQSfwyEl vw65qgbLuq/AYeuMBfi88FT9codLlAzIHEt2FpJhF8YoWEy3yRF5Q/YUHbA3rGY5ftn0 mMfjs/bT0Hpgp1LJ3c0+vVaCvbfmhXJZwyw714XMIdtX/7OCKACzJgJBb+ukEOeQGRON fd1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=b2pvl9UHk0Z4rkTZyge+oGFzFbTSQ4HA4DjZnHNbMzc=; b=dcIDRbL28txWnoSsHb3uZbLxifGsQhwRarvoDoI6C2CtB8aJyB5qCGg489CirzVONU POI0hHTExH5JtvcJcCtN5Mr1msirOy3dGVSZaH8OZIwEmC+/SApfhkeKVpFQD9Nf8a3+ trya62rz7N0UaXMMjijUE5SnpyqAGb8Ot3zqKeKT/EEjHVLI8TuWu436CjH+WkF0KCt/ a46VLmWiPvHE3NHRutS4ADPvDz2d2p6VhOR8zw9ms+IZlmcDOX1Bo7Hj/Tx8LOnhccaF xH5HjXY1Z+H5WBkwp3kvYH+NLfKHDnlSTpu4RoKa9B2nSR30KaFv3EVtitTj827/s+++ izVw== X-Gm-Message-State: AOAM531XtuqPyNbXZfZQhdLEvSPVnfjNl3sshpFa6Ubk2Aew1Ch2f5HE hI14ysnHam0aIP0QSkcV9XY= X-Google-Smtp-Source: ABdhPJwXtfEDgNR3RZSIsxQqHlreRhUU/8jLWP5c5p1euc9vogWKg5K34hI26sJzU9bqe0eGKSJ4bQ== X-Received: by 2002:adf:fc01:0:b0:20c:ff9a:2c53 with SMTP id i1-20020adffc01000000b0020cff9a2c53mr53206420wrr.142.1654080365855; Wed, 01 Jun 2022 03:46:05 -0700 (PDT) Received: from localhost.localdomain ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id h9-20020a5d4309000000b002102af52a2csm1562150wrq.9.2022.06.01.03.46.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 03:46:05 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Dave Chinner , Brian Foster , Christoph Hellwig , Luis Chamberlain , Adam Manzanares , Tyler Hicks , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 CANDIDATE 8/8] xfs: force log and push AIL to clear pinned inodes when aborting mount Date: Wed, 1 Jun 2022 13:45:47 +0300 Message-Id: <20220601104547.260949-9-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220601104547.260949-1-amir73il@gmail.com> References: <20220601104547.260949-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: "Darrick J. Wong" commit d336f7ebc65007f5831e2297e6f3383ae8dbf8ed upstream. If we allocate quota inodes in the process of mounting a filesystem but then decide to abort the mount, it's possible that the quota inodes are sitting around pinned by the log. Now that inode reclaim relies on the AIL to flush inodes, we have to force the log and push the AIL in between releasing the quota inodes and kicking off reclaim to tear down all the incore inodes. Do this by extracting the bits we need from the unmount path and reusing them. As an added bonus, failed writes during a failed mount will not retry forever now. This was originally found during a fuzz test of metadata directories (xfs/1546), but the actual symptom was that reclaim hung up on the quota inodes. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_mount.c | 90 +++++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 46 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index a62b8a574409..44b05e1d5d32 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -631,6 +631,47 @@ xfs_check_summary_counts( return xfs_initialize_perag_data(mp, mp->m_sb.sb_agcount); } +/* + * Flush and reclaim dirty inodes in preparation for unmount. Inodes and + * internal inode structures can be sitting in the CIL and AIL at this point, + * so we need to unpin them, write them back and/or reclaim them before unmount + * can proceed. + * + * An inode cluster that has been freed can have its buffer still pinned in + * memory because the transaction is still sitting in a iclog. The stale inodes + * on that buffer will be pinned to the buffer until the transaction hits the + * disk and the callbacks run. Pushing the AIL will skip the stale inodes and + * may never see the pinned buffer, so nothing will push out the iclog and + * unpin the buffer. + * + * Hence we need to force the log to unpin everything first. However, log + * forces don't wait for the discards they issue to complete, so we have to + * explicitly wait for them to complete here as well. + * + * Then we can tell the world we are unmounting so that error handling knows + * that the filesystem is going away and we should error out anything that we + * have been retrying in the background. This will prevent never-ending + * retries in AIL pushing from hanging the unmount. + * + * Finally, we can push the AIL to clean all the remaining dirty objects, then + * reclaim the remaining inodes that are still in memory at this point in time. + */ +static void +xfs_unmount_flush_inodes( + struct xfs_mount *mp) +{ + xfs_log_force(mp, XFS_LOG_SYNC); + xfs_extent_busy_wait_all(mp); + flush_workqueue(xfs_discard_wq); + + mp->m_flags |= XFS_MOUNT_UNMOUNTING; + + xfs_ail_push_all_sync(mp->m_ail); + cancel_delayed_work_sync(&mp->m_reclaim_work); + xfs_reclaim_inodes(mp); + xfs_health_unmount(mp); +} + /* * This function does the following on an initial mount of a file system: * - reads the superblock from disk and init the mount struct @@ -1005,7 +1046,7 @@ xfs_mountfs( /* Clean out dquots that might be in memory after quotacheck. */ xfs_qm_unmount(mp); /* - * Cancel all delayed reclaim work and reclaim the inodes directly. + * Flush all inode reclamation work and flush the log. * We have to do this /after/ rtunmount and qm_unmount because those * two will have scheduled delayed reclaim for the rt/quota inodes. * @@ -1015,11 +1056,8 @@ xfs_mountfs( * qm_unmount_quotas and therefore rely on qm_unmount to release the * quota inodes. */ - cancel_delayed_work_sync(&mp->m_reclaim_work); - xfs_reclaim_inodes(mp); - xfs_health_unmount(mp); + xfs_unmount_flush_inodes(mp); out_log_dealloc: - mp->m_flags |= XFS_MOUNT_UNMOUNTING; xfs_log_mount_cancel(mp); out_fail_wait: if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) @@ -1060,47 +1098,7 @@ xfs_unmountfs( xfs_rtunmount_inodes(mp); xfs_irele(mp->m_rootip); - /* - * We can potentially deadlock here if we have an inode cluster - * that has been freed has its buffer still pinned in memory because - * the transaction is still sitting in a iclog. The stale inodes - * on that buffer will be pinned to the buffer until the - * transaction hits the disk and the callbacks run. Pushing the AIL will - * skip the stale inodes and may never see the pinned buffer, so - * nothing will push out the iclog and unpin the buffer. Hence we - * need to force the log here to ensure all items are flushed into the - * AIL before we go any further. - */ - xfs_log_force(mp, XFS_LOG_SYNC); - - /* - * Wait for all busy extents to be freed, including completion of - * any discard operation. - */ - xfs_extent_busy_wait_all(mp); - flush_workqueue(xfs_discard_wq); - - /* - * We now need to tell the world we are unmounting. This will allow - * us to detect that the filesystem is going away and we should error - * out anything that we have been retrying in the background. This will - * prevent neverending retries in AIL pushing from hanging the unmount. - */ - mp->m_flags |= XFS_MOUNT_UNMOUNTING; - - /* - * Flush all pending changes from the AIL. - */ - xfs_ail_push_all_sync(mp->m_ail); - - /* - * Reclaim all inodes. At this point there should be no dirty inodes and - * none should be pinned or locked. Stop background inode reclaim here - * if it is still running. - */ - cancel_delayed_work_sync(&mp->m_reclaim_work); - xfs_reclaim_inodes(mp); - xfs_health_unmount(mp); + xfs_unmount_flush_inodes(mp); xfs_qm_unmount(mp);