From patchwork Fri Jun 24 06:36:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12894014 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 2E22CCCA473 for ; Fri, 24 Jun 2022 06:37:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230092AbiFXGhM (ORCPT ); Fri, 24 Jun 2022 02:37:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230281AbiFXGhL (ORCPT ); Fri, 24 Jun 2022 02:37:11 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DE466270D; Thu, 23 Jun 2022 23:37:09 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id p6-20020a05600c1d8600b0039c630b8d96so2873822wms.1; Thu, 23 Jun 2022 23:37:09 -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=X6hunTx6t84e1RH7TuIwMAVJt14IU7tMQ/ZDFHTvWjE=; b=ZyCRg4GWAXGUtf3Z2N1++vgG8NWM5m70FpRceKMSPYG3E2gS52XfB8jWTKfh/KUucW 3k9szx9jp44HPPrwRzya/EBsjdnZJE9rhZ2SSdNfNR3Ltdzl+YcC9wCLAYOUe+fRRbPt RVTNPt/Xg7h0U9zFReAp7BZQEO8IlPDGQ+WESwN+MhKoK5FgRSZctZ3wlb+CEeIdmzzE RTXVkK4mtustOIpCPn773p80bpcWHuAiz3b0gC3l42Zrn0+pccq38MA4d9JjxGgx2JMJ dd+ViQI8tD5JTlGjeuVtx4jurdcLWA2WFro7lUbm3jRMLaGC8EwJA9tbCTfJYKE7HF4B oxOg== 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=X6hunTx6t84e1RH7TuIwMAVJt14IU7tMQ/ZDFHTvWjE=; b=FlUSJk00zv2nQsKyN5usRYFZsNGnitbcJOPY+mRaFms8vHY3M9IkU6rT8ZmvJiKm1s k2h+c3p8QnTX0Nen+i2Q58NYK1LFM4c7XuIdjLg9g9pPwWC6OyVc7BAlmfYpYKQ+RwQ4 AHGy42x6McPrXHTzTRG34ijP2CrTVTHXTtz52d36ApBrkMAykoXDj18tYZnCMjKpO0+2 yo1EO5UyHnH1D8eyww389x8QpNkLYK+MgI8qug9IkHfG060O6Ja5zove70DAftAFTDDs 81KGLrVrsbi9yOMJmh7oZxVzXLaEOhJhK0nVSsX3PUs+77Fa022rVHDWQc0VUW+j5RxE 7EWw== X-Gm-Message-State: AJIora8OrQraEtkev+Yj/O0ECCYxFu1VmKIhXhGqavIdOzQ4odTKNZoX WrBjF0YLf+e0MWSvIG+28ysimSZScN8lxQ== X-Google-Smtp-Source: AGRyM1u3AG1crJ5vqgFUF2vqOHUW0mKmfMFkGZNv/OqTLUdsA1zAWRmxHwuuE5moZDnlJ7w1FT+Myg== X-Received: by 2002:a7b:cb03:0:b0:39e:e826:ce6d with SMTP id u3-20020a7bcb03000000b0039ee826ce6dmr1890278wmj.102.1656052628580; Thu, 23 Jun 2022 23:37:08 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([5.29.8.191]) by smtp.gmail.com with ESMTPSA id n14-20020a5d67ce000000b0021b89c07b6asm1540653wrw.108.2022.06.23.23.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 23:37:08 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Luis Chamberlain , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Rustam Kovhaev Subject: [5.10 CANDIDATE v2 1/5] xfs: use kmem_cache_free() for kmem_cache objects Date: Fri, 24 Jun 2022 09:36:58 +0300 Message-Id: <20220624063702.2380990-2-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220624063702.2380990-1-amir73il@gmail.com> References: <20220624063702.2380990-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Rustam Kovhaev commit c30a0cbd07ecc0eec7b3cd568f7b1c7bb7913f93 upstream. For kmalloc() allocations SLOB prepends the blocks with a 4-byte header, and it puts the size of the allocated blocks in that header. Blocks allocated with kmem_cache_alloc() allocations do not have that header. SLOB explodes when you allocate memory with kmem_cache_alloc() and then try to free it with kfree() instead of kmem_cache_free(). SLOB will assume that there is a header when there is none, read some garbage to size variable and corrupt the adjacent objects, which eventually leads to hang or panic. Let's make XFS work with SLOB by using proper free function. Fixes: 9749fee83f38 ("xfs: enable the xfs_defer mechanism to process extents to free") Signed-off-by: Rustam Kovhaev Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/xfs_extfree_item.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_extfree_item.c b/fs/xfs/xfs_extfree_item.c index 5c0395256bd1..11474770d630 100644 --- a/fs/xfs/xfs_extfree_item.c +++ b/fs/xfs/xfs_extfree_item.c @@ -482,7 +482,7 @@ xfs_extent_free_finish_item( free->xefi_startblock, free->xefi_blockcount, &free->xefi_oinfo, free->xefi_skip_discard); - kmem_free(free); + kmem_cache_free(xfs_bmap_free_item_zone, free); return error; } @@ -502,7 +502,7 @@ xfs_extent_free_cancel_item( struct xfs_extent_free_item *free; free = container_of(item, struct xfs_extent_free_item, xefi_list); - kmem_free(free); + kmem_cache_free(xfs_bmap_free_item_zone, free); } const struct xfs_defer_op_type xfs_extent_free_defer_type = { @@ -564,7 +564,7 @@ xfs_agfl_free_finish_item( extp->ext_len = free->xefi_blockcount; efdp->efd_next_extent++; - kmem_free(free); + kmem_cache_free(xfs_bmap_free_item_zone, free); return error; } From patchwork Fri Jun 24 06:36:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12894015 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 D01A5C433EF for ; Fri, 24 Jun 2022 06:37:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229745AbiFXGhN (ORCPT ); Fri, 24 Jun 2022 02:37:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230296AbiFXGhM (ORCPT ); Fri, 24 Jun 2022 02:37:12 -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 8449A60F17; Thu, 23 Jun 2022 23:37:11 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id n185so703584wmn.4; Thu, 23 Jun 2022 23:37:11 -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=SO7FU+0OUbBLhswG2cCvyF6AplpoM05NubU1LyceI0s=; b=UYdq+NO1MfX9KeZlN3pf7cunWQ5bORh/0kTYzCI8gbVTtIOKj0rTQ7zMfOywBjkQli xj7kbU1FUKWdkypQmMBpd4iFsBTBdvCQNfPT1evxdXB7Vz/N7qUw7X5x0S6m0WiD0Pdw PkTXldy0TIgivcxu6WzykCJl+VP/DZbpkopzKoHiXUS2JvPstabTl2kCGPu3gEa4yoVv 89hHuRWflpZqKq85DK9VKRwJBjbVjhh7fgNWdcGauYDEPsvApZ9z82jTJ9UcW9thdw74 XgGV0amOok2rCW16y9Rklzup781Lp/PFkYiI0O/cisl5NdyXpvQ/ADK/tCYO0y+t1BFI h5XA== 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=SO7FU+0OUbBLhswG2cCvyF6AplpoM05NubU1LyceI0s=; b=BtADwHuI/xKKI9rNM6/crB+gjuFtIpgsavQ9HTuu1+WpoG58vrUuWVViQjvtupQpjZ IZyTqThbeUXpUDFpzZsGwE2G0EJkpZuCtxlZNrPwfopU1Dqt3pMAyHS0W/rl7jbnjvT0 u9Nwz0clwINP0uJXXtGIZpoImrobDbifIJOg3H2g/hEKlWw3IJMuT8vlZz3aOhh9uESq RJXq/xp1NRmQ/IkFbF3Q4hhfoWvaCFy9wb6PBwjq6dii9JhX9ZVaxSoCfZK0ORy4aM/g QUw2VCdFNUVnV61FhZ1f5JEyNeKXjErvSe6tJReb0ZrqKkVhfkTaAdXScjAcum3CpRh+ bFxw== X-Gm-Message-State: AJIora/e+5lGO9wnWSQh6Pol4/jLBNuloNLQyiouP+6OxRAGuCUV98sj uMKjmz7ZXeZF3+YQGOljrTc= X-Google-Smtp-Source: AGRyM1vULihLp3IRnQw52s1Whds5jfJ+PsCLUgsHRgl+rJs8WZWGajqgVzQrHJLATSiY3sOICAN8ew== X-Received: by 2002:a05:600c:3505:b0:39c:93d4:5eec with SMTP id h5-20020a05600c350500b0039c93d45eecmr1802191wmq.179.1656052629973; Thu, 23 Jun 2022 23:37:09 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([5.29.8.191]) by smtp.gmail.com with ESMTPSA id n14-20020a5d67ce000000b0021b89c07b6asm1540653wrw.108.2022.06.23.23.37.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 23:37:09 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Luis Chamberlain , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Brian Foster Subject: [5.10 CANDIDATE v2 2/5] xfs: punch out data fork delalloc blocks on COW writeback failure Date: Fri, 24 Jun 2022 09:36:59 +0300 Message-Id: <20220624063702.2380990-3-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220624063702.2380990-1-amir73il@gmail.com> References: <20220624063702.2380990-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Brian Foster commit 5ca5916b6bc93577c360c06cb7cdf71adb9b5faf upstream. If writeback I/O to a COW extent fails, the COW fork blocks are punched out and the data fork blocks left alone. It is possible for COW fork blocks to overlap non-shared data fork blocks (due to cowextsz hint prealloc), however, and writeback unconditionally maps to the COW fork whenever blocks exist at the corresponding offset of the page undergoing writeback. This means it's quite possible for a COW fork extent to overlap delalloc data fork blocks, writeback to convert and map to the COW fork blocks, writeback to fail, and finally for ioend completion to cancel the COW fork blocks and leave stale data fork delalloc blocks around in the inode. The blocks are effectively stale because writeback failure also discards dirty page state. If this occurs, it is likely to trigger assert failures, free space accounting corruption and failures in unrelated file operations. For example, a subsequent reflink attempt of the affected file to a new target file will trip over the stale delalloc in the source file and fail. Several of these issues are occasionally reproduced by generic/648, but are reproducible on demand with the right sequence of operations and timely I/O error injection. To fix this problem, update the ioend failure path to also punch out underlying data fork delalloc blocks on I/O error. This is analogous to the writeback submission failure path in xfs_discard_page() where we might fail to map data fork delalloc blocks and consistent with the successful COW writeback completion path, which is responsible for unmapping from the data fork and remapping in COW fork blocks. Fixes: 787eb485509f ("xfs: fix and streamline error handling in xfs_end_io") Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/xfs_aops.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index 4304c6416fbb..4b76a32d2f16 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -145,6 +145,7 @@ xfs_end_ioend( struct iomap_ioend *ioend) { struct xfs_inode *ip = XFS_I(ioend->io_inode); + struct xfs_mount *mp = ip->i_mount; xfs_off_t offset = ioend->io_offset; size_t size = ioend->io_size; unsigned int nofs_flag; @@ -160,18 +161,26 @@ xfs_end_ioend( /* * Just clean up the in-memory strutures if the fs has been shut down. */ - if (XFS_FORCED_SHUTDOWN(ip->i_mount)) { + if (XFS_FORCED_SHUTDOWN(mp)) { error = -EIO; goto done; } /* - * Clean up any COW blocks on an I/O error. + * Clean up all COW blocks and underlying data fork delalloc blocks on + * I/O error. The delalloc punch is required because this ioend was + * mapped to blocks in the COW fork and the associated pages are no + * longer dirty. If we don't remove delalloc blocks here, they become + * stale and can corrupt free space accounting on unmount. */ error = blk_status_to_errno(ioend->io_bio->bi_status); if (unlikely(error)) { - if (ioend->io_flags & IOMAP_F_SHARED) + if (ioend->io_flags & IOMAP_F_SHARED) { xfs_reflink_cancel_cow_range(ip, offset, size, true); + xfs_bmap_punch_delalloc_range(ip, + XFS_B_TO_FSBT(mp, offset), + XFS_B_TO_FSB(mp, size)); + } goto done; } From patchwork Fri Jun 24 06:37:00 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12894016 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 DACDDC433EF for ; Fri, 24 Jun 2022 06:37:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230296AbiFXGhS (ORCPT ); Fri, 24 Jun 2022 02:37:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230281AbiFXGhR (ORCPT ); Fri, 24 Jun 2022 02:37:17 -0400 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E963F60F3E; Thu, 23 Jun 2022 23:37:12 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id s1so1755057wra.9; Thu, 23 Jun 2022 23:37:12 -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=cXA+/dAUwgRQc5EpwS/X0n2pUieK6tax4HxbsNJh6Rw=; b=VI+zEtVyTmOhxCUIDMOMa5boIHqHhIPsPa6USozweynCAoyPWGQI/56Rzr3hCBHMyB L7qeJONawjJOaN6CvCi0iXgPdEfwbhD2F96avDkcOBmIH9n6kJQjnZmauvRj6TbOQFnU 5W5EusPGGmMR8j2I+qjAdc0Fi2f8IL28inb7K9SfWpMyOtkQezD7J9pEtJZeAVOUGwfZ jynjW2rZX3cJ712VB0t6hKQpe6rCDwpd1VWdckihCz6J1Wa4VyC9YIGfoJCfJ24jdfSn QmfqDk4ZLXQ0H7VDC1IIT+Ttxpn94BjboxFl1vCPQh+KtRZ9hnV4H2HWfDWFrnoEScUR 5GIA== 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=cXA+/dAUwgRQc5EpwS/X0n2pUieK6tax4HxbsNJh6Rw=; b=uqIexGBIBjOwpl7WXzP484BVpPgr0slGpwDGRzyDDzq9r8fnkChvhUFHZNiY4xDUUr QC+Sfh/WZBPDnPvk3r3pglPJacDP1DzJzpWyjU4qpg3uqNe0ZiBEOs/DXv8wDt0vbTvO 8HK/Yzl2PVNATkscc4gZHFxcmApKKnbYU4XiSu3lyXdMZILLdczAfvtpSEfMkTcJ2bqi 6zEkQZjnzO6bU6rH/8OIFTUO26LzWe78SJklvwPtxOETTwAZNXQL167ghfo8b3u35o/W O0snhaY4Ei1b5/9GPjxRt5rczeOrJQBuPVPaSGw9nvfTCHxppiR6YgGMq/guv4z3IMYK /UMA== X-Gm-Message-State: AJIora9hxknTdlnJBZmFpfdWN64s65sFXNnc6FMp8a3TOIf8PhXZvdk/ Kt7LWWPXbxNC+ci7pZE/GAbtwlbPreiFAQ== X-Google-Smtp-Source: AGRyM1vC6/VC4gvf00Yn0I00d0VApJrBNhSlA6cL8O0p+hRgkRAppTrd846qFsTdieIyjSU/8CzvGQ== X-Received: by 2002:adf:d084:0:b0:21b:8a7c:d260 with SMTP id y4-20020adfd084000000b0021b8a7cd260mr11798639wrh.68.1656052631409; Thu, 23 Jun 2022 23:37:11 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([5.29.8.191]) by smtp.gmail.com with ESMTPSA id n14-20020a5d67ce000000b0021b89c07b6asm1540653wrw.108.2022.06.23.23.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 23:37:10 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Luis Chamberlain , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Yang Xu Subject: [5.10 CANDIDATE v2 3/5] xfs: Fix the free logic of state in xfs_attr_node_hasname Date: Fri, 24 Jun 2022 09:37:00 +0300 Message-Id: <20220624063702.2380990-4-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220624063702.2380990-1-amir73il@gmail.com> References: <20220624063702.2380990-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Yang Xu commit a1de97fe296c52eafc6590a3506f4bbd44ecb19a upstream. When testing xfstests xfs/126 on lastest upstream kernel, it will hang on some machine. Adding a getxattr operation after xattr corrupted, I can reproduce it 100%. The deadlock as below: [983.923403] task:setfattr state:D stack: 0 pid:17639 ppid: 14687 flags:0x00000080 [ 983.923405] Call Trace: [ 983.923410] __schedule+0x2c4/0x700 [ 983.923412] schedule+0x37/0xa0 [ 983.923414] schedule_timeout+0x274/0x300 [ 983.923416] __down+0x9b/0xf0 [ 983.923451] ? xfs_buf_find.isra.29+0x3c8/0x5f0 [xfs] [ 983.923453] down+0x3b/0x50 [ 983.923471] xfs_buf_lock+0x33/0xf0 [xfs] [ 983.923490] xfs_buf_find.isra.29+0x3c8/0x5f0 [xfs] [ 983.923508] xfs_buf_get_map+0x4c/0x320 [xfs] [ 983.923525] xfs_buf_read_map+0x53/0x310 [xfs] [ 983.923541] ? xfs_da_read_buf+0xcf/0x120 [xfs] [ 983.923560] xfs_trans_read_buf_map+0x1cf/0x360 [xfs] [ 983.923575] ? xfs_da_read_buf+0xcf/0x120 [xfs] [ 983.923590] xfs_da_read_buf+0xcf/0x120 [xfs] [ 983.923606] xfs_da3_node_read+0x1f/0x40 [xfs] [ 983.923621] xfs_da3_node_lookup_int+0x69/0x4a0 [xfs] [ 983.923624] ? kmem_cache_alloc+0x12e/0x270 [ 983.923637] xfs_attr_node_hasname+0x6e/0xa0 [xfs] [ 983.923651] xfs_has_attr+0x6e/0xd0 [xfs] [ 983.923664] xfs_attr_set+0x273/0x320 [xfs] [ 983.923683] xfs_xattr_set+0x87/0xd0 [xfs] [ 983.923686] __vfs_removexattr+0x4d/0x60 [ 983.923688] __vfs_removexattr_locked+0xac/0x130 [ 983.923689] vfs_removexattr+0x4e/0xf0 [ 983.923690] removexattr+0x4d/0x80 [ 983.923693] ? __check_object_size+0xa8/0x16b [ 983.923695] ? strncpy_from_user+0x47/0x1a0 [ 983.923696] ? getname_flags+0x6a/0x1e0 [ 983.923697] ? _cond_resched+0x15/0x30 [ 983.923699] ? __sb_start_write+0x1e/0x70 [ 983.923700] ? mnt_want_write+0x28/0x50 [ 983.923701] path_removexattr+0x9b/0xb0 [ 983.923702] __x64_sys_removexattr+0x17/0x20 [ 983.923704] do_syscall_64+0x5b/0x1a0 [ 983.923705] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 983.923707] RIP: 0033:0x7f080f10ee1b When getxattr calls xfs_attr_node_get function, xfs_da3_node_lookup_int fails with EFSCORRUPTED in xfs_attr_node_hasname because we have use blocktrash to random it in xfs/126. So it free state in internal and xfs_attr_node_get doesn't do xfs_buf_trans release job. Then subsequent removexattr will hang because of it. This bug was introduced by kernel commit 07120f1abdff ("xfs: Add xfs_has_attr and subroutines"). It adds xfs_attr_node_hasname helper and said caller will be responsible for freeing the state in this case. But xfs_attr_node_hasname will free state itself instead of caller if xfs_da3_node_lookup_int fails. Fix this bug by moving the step of free state into caller. [amir: this text from original commit is not relevant for 5.10 backport: Also, use "goto error/out" instead of returning error directly in xfs_attr_node_addname_find_attr and xfs_attr_node_removename_setup function because we should free state ourselves. ] Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Signed-off-by: Yang Xu Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_attr.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c index 96ac7e562b87..fcca36bbd997 100644 --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -876,21 +876,18 @@ xfs_attr_node_hasname( state = xfs_da_state_alloc(args); if (statep != NULL) - *statep = NULL; + *statep = state; /* * Search to see if name exists, and get back a pointer to it. */ error = xfs_da3_node_lookup_int(state, &retval); - if (error) { - xfs_da_state_free(state); - return error; - } + if (error) + retval = error; - if (statep != NULL) - *statep = state; - else + if (!statep) xfs_da_state_free(state); + return retval; } From patchwork Fri Jun 24 06:37:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12894017 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 E65FDCCA47E for ; Fri, 24 Jun 2022 06:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230306AbiFXGhT (ORCPT ); Fri, 24 Jun 2022 02:37:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230281AbiFXGhT (ORCPT ); Fri, 24 Jun 2022 02:37:19 -0400 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 627A5609E2; Thu, 23 Jun 2022 23:37:14 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id i67-20020a1c3b46000000b003a03567d5e9so1118466wma.1; Thu, 23 Jun 2022 23:37:14 -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=XaAYZ6qH2eW6SbCvz+SG+Z2d1NX2G9RI3Gz0+O4UvMc=; b=Ss8g9sg8tfi2jCkfUtmbFabnMNm1BjX9paSgHwH4M6+WA6ZHkRDJ0q5Eltq/1u/Syh ALad4GnTC2xLf9ISiyiox2323zegRrrqZMvjtvSr0O3CrvOv/U+jBwxWyCFCtemD9EYm KkiYKRMgVLn7TLEWEQdpdAmbtJ4v/rtxTq/Dc3y25RIKP57AgtZfKIQfugJo48AQpG9i Fy33NF7bwvsEm9jp490WTfvKVRyGMSJVXadyikTgg4Ht+TU92O25HaMjbKzijL/5mL4M 2SQusb1BEwVSIyCbjgRfQr0zevBErqhTy+todVBeMDxnZagY/LuH5JDFbydQ6WOpXtpB wy9A== 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=XaAYZ6qH2eW6SbCvz+SG+Z2d1NX2G9RI3Gz0+O4UvMc=; b=qo6LwPpGPe3KxRKXwWZWsd+i60CmFw7N/j3oXfCPkspUCsCMntCRDSI6/3RchDcWH2 G1FKfY7YDwrr4V9ZZBGSArRopAJRWdMin5ozSekjwfcLInl5kQPocwFAZ/q122XojHbH B2JjtCrFB8FSCkQNWW0mFW7YATaQ1Yz72XaIME2qqTDEuq67t6AlNr++zPM3zO9hmn7f aDNk+UWLlIzphqQtIhgM3a+ABePQ227jBFMrsqPAN34a7CKJNNWqI8P4GUrrOuATMpe9 B4Nz2waVkLVgTVp8lYlEJG2qjxLDhe/KWKbcN8xYJpUFhKRbgjF4QfMZNop73IVz0Abi iKEQ== X-Gm-Message-State: AJIora870LxkSlnCLq5abNjf5q1mIquE15AM3rB8RsRFTGB7LNbkTGk3 +XXUnbTUS+uCawN1k/3a1vc= X-Google-Smtp-Source: AGRyM1sEAZrXiAnZ+2Xn/wXvrovRXWXy9oeo/rn0lh6K+sviHDh67UzkpgM2l4nLGTnUbx/Xlcgd9w== X-Received: by 2002:a05:600c:1589:b0:3a0:2da9:bac0 with SMTP id r9-20020a05600c158900b003a02da9bac0mr1880553wmf.178.1656052632830; Thu, 23 Jun 2022 23:37:12 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([5.29.8.191]) by smtp.gmail.com with ESMTPSA id n14-20020a5d67ce000000b0021b89c07b6asm1540653wrw.108.2022.06.23.23.37.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 23:37:12 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Luis Chamberlain , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner , Chandan Babu R Subject: [5.10 CANDIDATE v2 4/5] xfs: remove all COW fork extents when remounting readonly Date: Fri, 24 Jun 2022 09:37:01 +0300 Message-Id: <20220624063702.2380990-5-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220624063702.2380990-1-amir73il@gmail.com> References: <20220624063702.2380990-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: "Darrick J. Wong" commit 089558bc7ba785c03815a49c89e28ad9b8de51f9 upstream. [backport xfs_icwalk -> xfs_eofblocks for 5.10.y] As part of multiple customer escalations due to file data corruption after copy on write operations, I wrote some fstests that use fsstress to hammer on COW to shake things loose. Regrettably, I caught some filesystem shutdowns due to incorrect rmap operations with the following loop: mount # (0) fsstress & # (1) while true; do fsstress mount -o remount,ro # (2) fsstress mount -o remount,rw # (3) done When (2) happens, notice that (1) is still running. xfs_remount_ro will call xfs_blockgc_stop to walk the inode cache to free all the COW extents, but the blockgc mechanism races with (1)'s reader threads to take IOLOCKs and loses, which means that it doesn't clean them all out. Call such a file (A). When (3) happens, xfs_remount_rw calls xfs_reflink_recover_cow, which walks the ondisk refcount btree and frees any COW extent that it finds. This function does not check the inode cache, which means that incore COW forks of inode (A) is now inconsistent with the ondisk metadata. If one of those former COW extents are allocated and mapped into another file (B) and someone triggers a COW to the stale reservation in (A), A's dirty data will be written into (B) and once that's done, those blocks will be transferred to (A)'s data fork without bumping the refcount. The results are catastrophic -- file (B) and the refcount btree are now corrupt. Solve this race by forcing the xfs_blockgc_free_space to run synchronously, which causes xfs_icwalk to return to inodes that were skipped because the blockgc code couldn't take the IOLOCK. This is safe to do here because the VFS has already prohibited new writer threads. Fixes: 10ddf64e420f ("xfs: remove leftover CoW reservations when remounting ro") Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Chandan Babu R Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/xfs_super.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 5ebd6cdc44a7..05cea7788d49 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1695,7 +1695,10 @@ static int xfs_remount_ro( struct xfs_mount *mp) { - int error; + struct xfs_eofblocks eofb = { + .eof_flags = XFS_EOF_FLAGS_SYNC, + }; + int error; /* * Cancel background eofb scanning so it cannot race with the final @@ -1703,8 +1706,13 @@ xfs_remount_ro( */ xfs_stop_block_reaping(mp); - /* Get rid of any leftover CoW reservations... */ - error = xfs_icache_free_cowblocks(mp, NULL); + /* + * Clear out all remaining COW staging extents and speculative post-EOF + * preallocations so that we don't leave inodes requiring inactivation + * cleanups during reclaim on a read-only mount. We must process every + * cached inode, so this requires a synchronous cache scan. + */ + error = xfs_icache_free_cowblocks(mp, &eofb); if (error) { xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); return error; From patchwork Fri Jun 24 06:37:02 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12894018 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 CA459C43334 for ; Fri, 24 Jun 2022 06:37:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230337AbiFXGhV (ORCPT ); Fri, 24 Jun 2022 02:37:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230165AbiFXGhU (ORCPT ); Fri, 24 Jun 2022 02:37:20 -0400 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C598562722; Thu, 23 Jun 2022 23:37:15 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id l2-20020a05600c4f0200b0039c55c50482so2790700wmq.0; Thu, 23 Jun 2022 23:37:15 -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=7rlLJigxsmTZtJ4R8DtANGAf44bp6QS5yoCTt0RR5Z8=; b=cLZzlaGIrc63eP0gS62EWcw1aOAsdieRvLank/MHXlcEwZL/kAPZ6epZ/WSn7fxpn6 s6fqceRX4GE+b5kLZPAiA8IldtIeY6JMHL+fsXPv+VDBFiw/6YdE3hZbpLx+FcwBjDhF 4gr7QsooxzlJi9AiY0aPiCtTevFU+xsOFxOvb8EGsfAbruN4a3Yptss5kDQEYLiDFu7s fOxXEttlZRDmFAa5p5xwLP70ePB7jrJLG79O71Gqrng7kELmsMoZqffZqKgmKGw+KwDQ RTz7zQqV1jeMe76rz0hrmMXNhR5+jxLoqpFi1AzQZMwr9seirxHCaGzjrYY7loc/0uKH SikA== 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=7rlLJigxsmTZtJ4R8DtANGAf44bp6QS5yoCTt0RR5Z8=; b=za+Rya8f1quW+1Pm7WmnUtjOC5Xjk9Kb2NvrnIOya9MDhDURCo98YuGCb0l6/JBfGm T1crD9od4XpLbnJlVm+GYdids00HIC1sZF2/yqu/mXTkXZxyKN5PFCzLQCUNiBszBNac VqOTQ7VV8QMRRpKqe1JZmAzSZd4sc+KErTYeidlydUphHzKWGAvMyk9OehfOsIRanZAy oowIhuDGfll2ogQrTFMEeG77R3uwsvDgJYD/Y/q+i/S03+G6dLDF/6wugZfH2TmAiSv6 MV0hkbMpJBSgdVHRy/UwpBrKrBG5XnTRbrqLLZVohIMzelnPeA/ip6BRh48SxILXFiyV 01/g== X-Gm-Message-State: AJIora+C9NgrjvSTLfLTa11QDT6z6F1NFu+WB1nJkTBE+60iowkJNMkw ALxxbQwkJrTie7PG21Z3410= X-Google-Smtp-Source: AGRyM1uHebUAQGDzUEn9gKzgSQ0B70dHjpSWMYgjYhk5FTJhhqWRL5+MdolCX+g+FsaWfoq9zku3Hg== X-Received: by 2002:a05:600c:646:b0:397:77ab:5eb7 with SMTP id p6-20020a05600c064600b0039777ab5eb7mr1941309wmm.166.1656052634299; Thu, 23 Jun 2022 23:37:14 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([5.29.8.191]) by smtp.gmail.com with ESMTPSA id n14-20020a5d67ce000000b0021b89c07b6asm1540653wrw.108.2022.06.23.23.37.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 23:37:13 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Luis Chamberlain , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner Subject: [5.10 CANDIDATE v2 5/5] xfs: check sb_meta_uuid for dabuf buffer recovery Date: Fri, 24 Jun 2022 09:37:02 +0300 Message-Id: <20220624063702.2380990-6-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220624063702.2380990-1-amir73il@gmail.com> References: <20220624063702.2380990-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Dave Chinner commit 09654ed8a18cfd45027a67d6cbca45c9ea54feab upstream. Got a report that a repeated crash test of a container host would eventually fail with a log recovery error preventing the system from mounting the root filesystem. It manifested as a directory leaf node corruption on writeback like so: XFS (loop0): Mounting V5 Filesystem XFS (loop0): Starting recovery (logdev: internal) XFS (loop0): Metadata corruption detected at xfs_dir3_leaf_check_int+0x99/0xf0, xfs_dir3_leaf1 block 0x12faa158 XFS (loop0): Unmount and run xfs_repair XFS (loop0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 3d f1 00 00 e1 9e d5 8b ........=....... 00000010: 00 00 00 00 12 fa a1 58 00 00 00 29 00 00 1b cc .......X...).... 00000020: 91 06 78 ff f7 7e 4a 7d 8d 53 86 f2 ac 47 a8 23 ..x..~J}.S...G.# 00000030: 00 00 00 00 17 e0 00 80 00 43 00 00 00 00 00 00 .........C...... 00000040: 00 00 00 2e 00 00 00 08 00 00 17 2e 00 00 00 0a ................ 00000050: 02 35 79 83 00 00 00 30 04 d3 b4 80 00 00 01 50 .5y....0.......P 00000060: 08 40 95 7f 00 00 02 98 08 41 fe b7 00 00 02 d4 .@.......A...... 00000070: 0d 62 ef a7 00 00 01 f2 14 50 21 41 00 00 00 0c .b.......P!A.... XFS (loop0): Corruption of in-memory data (0x8) detected at xfs_do_force_shutdown+0x1a/0x20 (fs/xfs/xfs_buf.c:1514). Shutting down. XFS (loop0): Please unmount the filesystem and rectify the problem(s) XFS (loop0): log mount/recovery failed: error -117 XFS (loop0): log mount failed Tracing indicated that we were recovering changes from a transaction at LSN 0x29/0x1c16 into a buffer that had an LSN of 0x29/0x1d57. That is, log recovery was overwriting a buffer with newer changes on disk than was in the transaction. Tracing indicated that we were hitting the "recovery immediately" case in xfs_buf_log_recovery_lsn(), and hence it was ignoring the LSN in the buffer. The code was extracting the LSN correctly, then ignoring it because the UUID in the buffer did not match the superblock UUID. The problem arises because the UUID check uses the wrong UUID - it should be checking the sb_meta_uuid, not sb_uuid. This filesystem has sb_uuid != sb_meta_uuid (which is fine), and the buffer has the correct matching sb_meta_uuid in it, it's just the code checked it against the wrong superblock uuid. The is no corruption in the filesystem, and failing to recover the buffer due to a write verifier failure means the recovery bug did not propagate the corruption to disk. Hence there is no corruption before or after this bug has manifested, the impact is limited simply to an unmountable filesystem.... This was missed back in 2015 during an audit of incorrect sb_uuid usage that resulted in commit fcfbe2c4ef42 ("xfs: log recovery needs to validate against sb_meta_uuid") that fixed the magic32 buffers to validate against sb_meta_uuid instead of sb_uuid. It missed the magicda buffers.... Fixes: ce748eaa65f2 ("xfs: create new metadata UUID field and incompat flag") Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/xfs_buf_item_recover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index d44e8b4a3391..1d649462d731 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -805,7 +805,7 @@ xlog_recover_get_buf_lsn( } if (lsn != (xfs_lsn_t)-1) { - if (!uuid_equal(&mp->m_sb.sb_uuid, uuid)) + if (!uuid_equal(&mp->m_sb.sb_meta_uuid, uuid)) goto recover_immediately; return lsn; }