From patchwork Wed Aug 10 14:15:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12940615 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 0103EC3F6B0 for ; Wed, 10 Aug 2022 14:16:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232119AbiHJOQC (ORCPT ); Wed, 10 Aug 2022 10:16:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231135AbiHJOQC (ORCPT ); Wed, 10 Aug 2022 10:16:02 -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 20EDF6051B; Wed, 10 Aug 2022 07:16:01 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id z12so17906662wrs.9; Wed, 10 Aug 2022 07:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=kKLVpIdsRy5TMWtiB5ZaP6V18ibVcn9e+fK2DzTcFxQ=; b=BumslBWwvg8KyrxOsGDuztgkN0YS1dRH2Ws55oBlCsYv2+TALUbzNcPDSy3V8T/guu q4rW8VMt18R0Sb/KLAQwUid2iYmERAH0iHF9MGpK9lKdF5CHuFGnInXUXCIXfoOrHtP0 k/2vD6KixV/4ppOTp1YqX8MDgGttg0PkD3T6xfH1W1/Rgxazj2Tv2/oD6WnQpNnCDe9V dSWz8Yd4WgY2nUEExuUYPHa4IUQOHmL57SXiInol+sv3u1hRn6Hhhv9/Y0qpSxsXe8PL 1+KbML1VLM6yABhpujvPTOOv7HEU/AiQ+5cIjYpEs1tuT2YCEzzzFxL2BRkcbDvq37M5 mHSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=kKLVpIdsRy5TMWtiB5ZaP6V18ibVcn9e+fK2DzTcFxQ=; b=3eNXd8iADt84DdvSj/4J0eC5xagU/ku638QU7WG/lTFJzlShKqawRtoYPCvUeBHoxH eTTxPPxePqtEGAvEzAEd72O77YSbG3oQHGu/AL39jsRn2MlCe6fPIyEac2gKv+LtP5we kDg/sV9JvAnywD4LsiSs/MbrdVnU0RWJAJQxwLFOrWmxF9QS1G5U87Mz0lI2EDxFrLGE 1QaBEEPhW2Qyp3by+N+XEw/+SffGvB58DcrB/qtIy4S2o/Hqm57AZl0Uw9eLIkj/wt+m FSrGVLdDfUelZD46glyMZlJxEfUAJn0//defgSTc7BlZ4LGuNlVReBD3edYAvKAybZXd pQRg== X-Gm-Message-State: ACgBeo32tFc8dFEBuIu5jrf58FKsxBRm5w7wZzZnq19wON2F6htZupBh KTExYhN/QzptY8tdjoZAm5Q= X-Google-Smtp-Source: AA6agR5hf/oTVvHUucj+RCk7YZHXvUuLwiZT2QduyqHxZLniT6vUN7gvf9tUPuTU5FGLXVJRW1BzLA== X-Received: by 2002:adf:ecc7:0:b0:220:5fef:6d40 with SMTP id s7-20020adfecc7000000b002205fef6d40mr17500256wro.5.1660140959670; Wed, 10 Aug 2022 07:15:59 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id x13-20020adfdccd000000b0021d65675583sm16902969wrm.52.2022.08.10.07.15.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 07:15:59 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , Mel Gorman Subject: [PATCH 5.10 v2 1/3] mm: Add kvrealloc() Date: Wed, 10 Aug 2022 16:15:50 +0200 Message-Id: <20220810141552.168763-2-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220810141552.168763-1-amir73il@gmail.com> References: <20220810141552.168763-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner commit de2860f4636256836450c6543be744a50118fc66 upstream. During log recovery of an XFS filesystem with 64kB directory buffers, rebuilding a buffer split across two log records results in a memory allocation warning from krealloc like this: xfs filesystem being mounted at /mnt/scratch supports timestamps until 2038 (0x7fffffff) XFS (dm-0): Unmounting Filesystem XFS (dm-0): Mounting V5 Filesystem XFS (dm-0): Starting recovery (logdev: internal) ------------[ cut here ]------------ WARNING: CPU: 5 PID: 3435170 at mm/page_alloc.c:3539 get_page_from_freelist+0xdee/0xe40 ..... RIP: 0010:get_page_from_freelist+0xdee/0xe40 Call Trace: ? complete+0x3f/0x50 __alloc_pages+0x16f/0x300 alloc_pages+0x87/0x110 kmalloc_order+0x2c/0x90 kmalloc_order_trace+0x1d/0x90 __kmalloc_track_caller+0x215/0x270 ? xlog_recover_add_to_cont_trans+0x63/0x1f0 krealloc+0x54/0xb0 xlog_recover_add_to_cont_trans+0x63/0x1f0 xlog_recovery_process_trans+0xc1/0xd0 xlog_recover_process_ophdr+0x86/0x130 xlog_recover_process_data+0x9f/0x160 xlog_recover_process+0xa2/0x120 xlog_do_recovery_pass+0x40b/0x7d0 ? __irq_work_queue_local+0x4f/0x60 ? irq_work_queue+0x3a/0x50 xlog_do_log_recovery+0x70/0x150 xlog_do_recover+0x38/0x1d0 xlog_recover+0xd8/0x170 xfs_log_mount+0x181/0x300 xfs_mountfs+0x4a1/0x9b0 xfs_fs_fill_super+0x3c0/0x7b0 get_tree_bdev+0x171/0x270 ? suffix_kstrtoint.constprop.0+0xf0/0xf0 xfs_fs_get_tree+0x15/0x20 vfs_get_tree+0x24/0xc0 path_mount+0x2f5/0xaf0 __x64_sys_mount+0x108/0x140 do_syscall_64+0x3a/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae Essentially, we are taking a multi-order allocation from kmem_alloc() (which has an open coded no fail, no warn loop) and then reallocating it out to 64kB using krealloc(__GFP_NOFAIL) and that is then triggering the above warning. This is a regression caused by converting this code from an open coded no fail/no warn reallocation loop to using __GFP_NOFAIL. What we actually need here is kvrealloc(), so that if contiguous page allocation fails we fall back to vmalloc() and we don't get nasty warnings happening in XFS. Fixes: 771915c4f688 ("xfs: remove kmem_realloc()") Signed-off-by: Dave Chinner Acked-by: Mel Gorman Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/xfs_log_recover.c | 4 +++- include/linux/mm.h | 2 ++ mm/util.c | 15 +++++++++++++++ 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index 69408782019e..e61f28ce3e44 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -2061,7 +2061,9 @@ xlog_recover_add_to_cont_trans( old_ptr = item->ri_buf[item->ri_cnt-1].i_addr; old_len = item->ri_buf[item->ri_cnt-1].i_len; - ptr = krealloc(old_ptr, len + old_len, GFP_KERNEL | __GFP_NOFAIL); + ptr = kvrealloc(old_ptr, old_len, len + old_len, GFP_KERNEL); + if (!ptr) + return -ENOMEM; memcpy(&ptr[old_len], dp, len); item->ri_buf[item->ri_cnt-1].i_len += len; item->ri_buf[item->ri_cnt-1].i_addr = ptr; diff --git a/include/linux/mm.h b/include/linux/mm.h index 5b4d88faf114..b8b677f47a8d 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -788,6 +788,8 @@ static inline void *kvcalloc(size_t n, size_t size, gfp_t flags) return kvmalloc_array(n, size, flags | __GFP_ZERO); } +extern void *kvrealloc(const void *p, size_t oldsize, size_t newsize, + gfp_t flags); extern void kvfree(const void *addr); extern void kvfree_sensitive(const void *addr, size_t len); diff --git a/mm/util.c b/mm/util.c index ba9643de689e..25bfda774f6f 100644 --- a/mm/util.c +++ b/mm/util.c @@ -661,6 +661,21 @@ void kvfree_sensitive(const void *addr, size_t len) } EXPORT_SYMBOL(kvfree_sensitive); +void *kvrealloc(const void *p, size_t oldsize, size_t newsize, gfp_t flags) +{ + void *newp; + + if (oldsize >= newsize) + return (void *)p; + newp = kvmalloc(newsize, flags); + if (!newp) + return NULL; + memcpy(newp, p, oldsize); + kvfree(p); + return newp; +} +EXPORT_SYMBOL(kvrealloc); + static inline void *__page_rmapping(struct page *page) { unsigned long mapping; From patchwork Wed Aug 10 14:15:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12940616 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 9788DC25B0C for ; Wed, 10 Aug 2022 14:16:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232335AbiHJOQE (ORCPT ); Wed, 10 Aug 2022 10:16:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232260AbiHJOQD (ORCPT ); Wed, 10 Aug 2022 10:16:03 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BE835FAFE; Wed, 10 Aug 2022 07:16:02 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id l22so17922160wrz.7; Wed, 10 Aug 2022 07:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=j7Qb4aUyvVNFaR2MvIyBKGEChv9dWRFrx3II0DQKzX4=; b=WXgkltJ84ZiIApjSZWpKWeqnabW6ZdRO33gtor9uKAFBZ0hMOsts4MW/vijoIxU+V5 pWsvF2Oeb9IMMz1C39R9Sykpxx6l3NyQk9fQDIO5n4XsZ42XR4PcGT5svqjxM6bakcCg WL7MLZoxP6GlUpEkn1NogrjJ6svFykWXEQ/dxegXFBD8Kcho7I3PsCSyfxIHqIihBd8i CeQtI/NQRE7WYNMYJ8qlkjygw2Ic+0boWrB1LoLIueGAffoMdXik03W/KEnufn9feeb4 jE7UQ7iKeqqDt6UtoHcrG2dE+n/oQgZ1ilR302/5QKRLaOiqHkBqSPlHPzE+HuyElI/c incQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=j7Qb4aUyvVNFaR2MvIyBKGEChv9dWRFrx3II0DQKzX4=; b=OwngOzbjAlabsEAvzmYoVMpa9SdDVFegJFiFtHetC4pezA2P65eesa5Bykycc81A1u 2GKBpiXrvCOQZc0EoYB8bDnNyGaDfUglc8JNq+tK+/JiwP09VbHesziklIJ6byoHFc6g JQBrswmA0jZnnUf2HMo1+RRSvwA2rCXfYXd0DW1oN5pJiAlOs4oQip9XiIRBohpRpI9C 7O9H94bHmzoPuw5RsaYqCGZsNzP5gVlkq/JW1WNFV5YAh3cmAkHxCV5ZuBBzi8VpTKC3 Bjg5ILJYZjxwz67utQLZ+W3/4WEbbIPRGBdgasPgMUFHBnWYvVH+EMfROu9DNipj/xiX Xz2w== X-Gm-Message-State: ACgBeo2i1eufXh05r1jYqGylXGSi5+gqDxYRgWL1gJB4GX0D79A5QxcN JAeoLpcaQ7QrJvphRp6pnMk= X-Google-Smtp-Source: AA6agR63R4iyVX/3VIdMiAxoCixCERtFzZ0LbCNPzFZDWi9p1bPOR7gT60ey2KaQ7M4bpGy9DkFDQQ== X-Received: by 2002:a05:6000:2cb:b0:21e:d9ce:fd76 with SMTP id o11-20020a05600002cb00b0021ed9cefd76mr17980457wry.482.1660140961509; Wed, 10 Aug 2022 07:16:01 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id x13-20020adfdccd000000b0021d65675583sm16902969wrm.52.2022.08.10.07.15.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 07:16:01 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Christoph Hellwig , Chandan Babu R Subject: [PATCH 5.10 v2 2/3] xfs: only set IOMAP_F_SHARED when providing a srcmap to a write Date: Wed, 10 Aug 2022 16:15:51 +0200 Message-Id: <20220810141552.168763-3-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220810141552.168763-1-amir73il@gmail.com> References: <20220810141552.168763-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" commit 72a048c1056a72e37ea2ee34cc73d8c6d6cb4290 upstream. While prototyping a free space defragmentation tool, I observed an unexpected IO error while running a sequence of commands that can be recreated by the following sequence of commands: $ xfs_io -f -c "pwrite -S 0x58 -b 10m 0 10m" file1 $ cp --reflink=always file1 file2 $ punch-alternating -o 1 file2 $ xfs_io -c "funshare 0 10m" file2 fallocate: Input/output error I then scraped this (abbreviated) stack trace from dmesg: WARNING: CPU: 0 PID: 30788 at fs/iomap/buffered-io.c:577 iomap_write_begin+0x376/0x450 CPU: 0 PID: 30788 Comm: xfs_io Not tainted 5.14.0-rc6-xfsx #rc6 5ef57b62a900814b3e4d885c755e9014541c8732 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:iomap_write_begin+0x376/0x450 RSP: 0018:ffffc90000c0fc20 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffffc90000c0fd10 RCX: 0000000000001000 RDX: ffffc90000c0fc54 RSI: 000000000000000c RDI: 000000000000000c RBP: ffff888005d5dbd8 R08: 0000000000102000 R09: ffffc90000c0fc50 R10: 0000000000b00000 R11: 0000000000101000 R12: ffffea0000336c40 R13: 0000000000001000 R14: ffffc90000c0fd10 R15: 0000000000101000 FS: 00007f4b8f62fe40(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056361c554108 CR3: 000000000524e004 CR4: 00000000001706f0 Call Trace: iomap_unshare_actor+0x95/0x140 iomap_apply+0xfa/0x300 iomap_file_unshare+0x44/0x60 xfs_reflink_unshare+0x50/0x140 [xfs 61947ea9b3a73e79d747dbc1b90205e7987e4195] xfs_file_fallocate+0x27c/0x610 [xfs 61947ea9b3a73e79d747dbc1b90205e7987e4195] vfs_fallocate+0x133/0x330 __x64_sys_fallocate+0x3e/0x70 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4b8f79140a Looking at the iomap tracepoints, I saw this: iomap_iter: dev 8:64 ino 0x100 pos 0 length 0 flags WRITE|0x80 (0x81) ops xfs_buffered_write_iomap_ops caller iomap_file_unshare iomap_iter_dstmap: dev 8:64 ino 0x100 bdev 8:64 addr -1 offset 0 length 131072 type DELALLOC flags SHARED iomap_iter_srcmap: dev 8:64 ino 0x100 bdev 8:64 addr 147456 offset 0 length 4096 type MAPPED flags iomap_iter: dev 8:64 ino 0x100 pos 0 length 4096 flags WRITE|0x80 (0x81) ops xfs_buffered_write_iomap_ops caller iomap_file_unshare iomap_iter_dstmap: dev 8:64 ino 0x100 bdev 8:64 addr -1 offset 4096 length 4096 type DELALLOC flags SHARED console: WARNING: CPU: 0 PID: 30788 at fs/iomap/buffered-io.c:577 iomap_write_begin+0x376/0x450 The first time funshare calls ->iomap_begin, xfs sees that the first block is shared and creates a 128k delalloc reservation in the COW fork. The delalloc reservation is returned as dstmap, and the shared block is returned as srcmap. So far so good. funshare calls ->iomap_begin to try the second block. This time there's no srcmap (punch-alternating punched it out!) but we still have the delalloc reservation in the COW fork. Therefore, we again return the reservation as dstmap and the hole as srcmap. iomap_unshare_iter incorrectly tries to unshare the hole, which __iomap_write_begin rejects because shared regions must be fully written and therefore cannot require zeroing. Therefore, change the buffered write iomap_begin function not to set IOMAP_F_SHARED when there isn't a source mapping to read from for the unsharing. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Chandan Babu R Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong --- fs/xfs/xfs_iomap.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 74bc2beadc23..bd5a25f4952d 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -1062,11 +1062,11 @@ xfs_buffered_write_iomap_begin( error = xfs_bmbt_to_iomap(ip, srcmap, &imap, 0); if (error) return error; - } else { - xfs_trim_extent(&cmap, offset_fsb, - imap.br_startoff - offset_fsb); + return xfs_bmbt_to_iomap(ip, iomap, &cmap, IOMAP_F_SHARED); } - return xfs_bmbt_to_iomap(ip, iomap, &cmap, IOMAP_F_SHARED); + + xfs_trim_extent(&cmap, offset_fsb, imap.br_startoff - offset_fsb); + return xfs_bmbt_to_iomap(ip, iomap, &cmap, 0); out_unlock: xfs_iunlock(ip, XFS_ILOCK_EXCL); From patchwork Wed Aug 10 14:15:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12940617 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 09530C00140 for ; Wed, 10 Aug 2022 14:16:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232418AbiHJOQH (ORCPT ); Wed, 10 Aug 2022 10:16:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232260AbiHJOQF (ORCPT ); Wed, 10 Aug 2022 10:16:05 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3BD8606AC; Wed, 10 Aug 2022 07:16:04 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id k17so1007897wmr.2; Wed, 10 Aug 2022 07:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=yJTJeBH5eeBX44c6u9JN3IXpz+84tiTBfFtmfUlzynY=; b=oVEhjsE1xaUL6CNE1ZYzJmvscAV8O3UV7s84oAlp+Be/ONAQF6B08sw4st1cvSORKz X8oNphFqB0ViE2R1MSVL7MdJ1vJM2bNBarPspuXKRcLvngEb3uY6dUcOdQ8DbCvr6JEo wJ3Aaf9larVJXVtTIztuQLdqRScvynu4zNzCwqqYO4QJDZHg3jfSRcBvBzrf+wRpiELQ EQHx15qwXdV3lEsQREbGkuur9vgsR1HCU3o2OC2dr5ghO8C5vd4jPbX/v/0OUNRvA0m6 mEtRTjEo28HWt3Y7M3CRnIZCA15tCntyGAqjSBzFPictamrw/pkgDKDtDB/HdzvRFUuU sNFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=yJTJeBH5eeBX44c6u9JN3IXpz+84tiTBfFtmfUlzynY=; b=ashnc1pH45jK+zTMdS6/SPhxIerOuN6DK7c+R/XIU3jXTBiTyiMkeMl1iGDQ/quNOf UYeV9Icrg5ACWiMPcRdmnV93/isLWeoPra8nA0Sc8csDjaQyOt2wLOfSLT/7I1G4B4/l s2DD/FopAaER4FoAkaFbokoi/zUy9KLV8e0g20M+jD5kCRVm5OQ368QXj15/vDctM23B Ox1bwQmhQ/ez9WphJ2LGaocNgRfnjgiUc5pcjljOhYOVuEhm3LIAgQ7IUg4wqNf2uqlT nRAvCFq69miRDLrq63U0S9GVcqh+uIyrmqw8Qe4++Kr9Qf6SpOnCzmk7y1fDFmAaAnbT NODQ== X-Gm-Message-State: ACgBeo0dmDFhJvPCsvwF6G/3V0enuOFhz0pRAESq7yGofEHlN58hXw8R oBLwXc2qyLF/FRm0LGrtTHBNFMjY7m0= X-Google-Smtp-Source: AA6agR7XFjoYEgACthjIx/gtejcteZhlFex/qI3X7AHTeQZneGRpdphjNmE3Q5rbG6kUBBzc0F5urQ== X-Received: by 2002:a05:600c:a41:b0:39c:1512:98bd with SMTP id c1-20020a05600c0a4100b0039c151298bdmr2666051wmq.88.1660140963213; Wed, 10 Aug 2022 07:16:03 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id x13-20020adfdccd000000b0021d65675583sm16902969wrm.52.2022.08.10.07.16.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 07:16:02 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 v2 3/3] xfs: fix I_DONTCACHE Date: Wed, 10 Aug 2022 16:15:52 +0200 Message-Id: <20220810141552.168763-4-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220810141552.168763-1-amir73il@gmail.com> References: <20220810141552.168763-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner commit f38a032b165d812b0ba8378a5cd237c0888ff65f upstream. Yup, the VFS hoist broke it, and nobody noticed. Bulkstat workloads make it clear that it doesn't work as it should. Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer") 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_icache.c | 3 ++- fs/xfs/xfs_iops.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index deb99300d171..e69a08ed7de4 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -47,8 +47,9 @@ xfs_inode_alloc( return NULL; } - /* VFS doesn't initialise i_mode! */ + /* VFS doesn't initialise i_mode or i_state! */ VFS_I(ip)->i_mode = 0; + VFS_I(ip)->i_state = 0; XFS_STATS_INC(mp, vn_active); ASSERT(atomic_read(&ip->i_pincount) == 0); diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index b7f7b31a77d5..6a3026e78a9b 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -1328,7 +1328,7 @@ xfs_setup_inode( gfp_t gfp_mask; inode->i_ino = ip->i_ino; - inode->i_state = I_NEW; + inode->i_state |= I_NEW; inode_sb_list_add(inode); /* make the inode look hashed for the writeback code */