Message ID | 20240129210631.193493-8-mathieu.desnoyers@efficios.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-43507-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp833554dyb; Mon, 29 Jan 2024 13:09:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IGsyw9wEy1F11QpGlyObQjlMkm+FXUsjyA2XgUEOVZGzciVyD3b7EKcYVLblZ2X2gcvfOvv X-Received: by 2002:a17:906:2516:b0:a35:d73f:7a88 with SMTP id i22-20020a170906251600b00a35d73f7a88mr1906764ejb.25.1706562566221; Mon, 29 Jan 2024 13:09:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706562566; cv=pass; d=google.com; s=arc-20160816; b=Fw91m2dLyjrhpjKMVstTeftGua8sZlqGlxOGXsozCkZpGz4Cq5aYoxWGl2Ti+/TH1z LKR9WRnFUTCdgvXw3yead0W0WrPORv81YwGn5inLheeQC+Rg16/3yuMLbBDTxuRdSBI2 mk5FKf0B7kR/BuFsOjVaWSJhiVsQ33QlsLIiC0yYKNYKtjO46Spz3B+/F2fNTpE8Tisy bhf7WIMVxwiOVPqn4ESsVj68JrdX3G7whFV/az7IfACdxahHYO0SdmfkT0HEqv2/9X5Y /VNwYeD984vM47sESqt/7ISGQTwe/uIo+J59MUfHEtBdZwLQrtc9vzP7ZK4n2ST2KtzQ 5g5Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=h7fxtm6Dz7MxzniRp8UbYNumQbLRlmJV1CMVtnUarkc=; fh=P8sZSSpb90fbUtBPm3T3+HKLXL6bUS6wwfy2Ih7se1I=; b=1Fhan39n5kUKNvNsMVU4YVUUtyTz3EwWfmfsvgDQX9FheNIi/mc9OabymNh/QB4pbs mHu0vrbt+5dJ4fct4ue4fjYmVSya68iPF61BlFBKz8ijX/sOK4IR0doXXr+gAtyms8zf 65jN40EVG0pNQbRKB/0qNJPz0sJgaFvWwDIlf9EPYtAEU5IPqvkgqq5YYdRnjuZhfo9x 5RXbfkv6nKFuw3gtbaL31BE/yweWpgKABThIbivpxnJz9k6OxrkGp6SCB5Q9VOliiBbb wUegwQ0pQqnvjowT2FHmQfltAwKDwE+ko4Xe/PMdyBOoG6bG8AMpwTX/Xp/Rh0hC2h0J FX1A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=CcOYTXBC; arc=pass (i=1 spf=pass spfdomain=efficios.com dkim=pass dkdomain=efficios.com dmarc=pass fromdomain=efficios.com); spf=pass (google.com: domain of linux-kernel+bounces-43507-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43507-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id by8-20020a170906a2c800b00a331d7fb523si3684438ejb.185.2024.01.29.13.09.26 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 13:09:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-43507-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=CcOYTXBC; arc=pass (i=1 spf=pass spfdomain=efficios.com dkim=pass dkdomain=efficios.com dmarc=pass fromdomain=efficios.com); spf=pass (google.com: domain of linux-kernel+bounces-43507-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43507-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CBC6B1F25A8A for <ouuuleilei@gmail.com>; Mon, 29 Jan 2024 21:09:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 53E9115B30F; Mon, 29 Jan 2024 21:07:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="CcOYTXBC" Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89212158D9E; Mon, 29 Jan 2024 21:06:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=167.114.26.122 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706562416; cv=none; b=IcuF6SZE4MfJtURYRwlr8Oc4Vg4mkhRHAbqwbRK3Bo1dnhHN8Ifp2XVdSe9nfhuZdtvlj/PNT1Mu2f8Erw+3xy8GME2irfU33Q5+w1KuamGCnc7SFEnQ4He0woxl4o5lkifYqyUt5wfCobl/Xp+QXaCdwyLl6WtKLF2nvcloZD8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706562416; c=relaxed/simple; bh=+9KVNYBLuRYpTotbk2zGsoJXymuo5SYIdtEsNtMMAo8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Wia5Kdbl0lskrOHtEZ1N04JXKVz6hCh8gslubX2SPWxW54bZQ8QG2tR6TL1YE4JKbHdZUqaZjZ1pJKmMFZAnkAVnU7TYJfllDRDZ4faP7t9orggM0Qh0ZQ0QvzJRbbfSWv82G6pMBAGHowBMcrDcFF018Uue84lEUh5r+9gBDy0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=CcOYTXBC; arc=none smtp.client-ip=167.114.26.122 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1706562411; bh=+9KVNYBLuRYpTotbk2zGsoJXymuo5SYIdtEsNtMMAo8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CcOYTXBC+giecQFAnLXwCTdIA57noQj2OFLZSCDKOIqpDr07dTVy1a8yJ3JryQJFV 2W5WB4QDkxTlNWbKpDcCfDCV1Yk9/dIKfFXxGJuTQcgowNhMsO3Yukg02bjPIMQFRv /baVDZYZtLVEz5A+3KUgQ0PgbI8sFNR5jmvB/7Vj1O8CCBTsO3bSZG9kBumQzDZiac Bm8evVOKtcBoj9wUdK5Wg/PiFVXjpfyrc41vpv1g5ItzalsHpw3MmQJYQPi57b1jWs DvIBjtghpS+h8EJifX32P3NqBz5VyeY9kNGlqU4+zvabpczDg6wWwsmvAwIDe9N3Eq k/288u39p8m6w== Received: from thinkos.internal.efficios.com (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4TP17v2W6RzVfr; Mon, 29 Jan 2024 16:06:51 -0500 (EST) From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Dan Williams <dan.j.williams@intel.com>, Vishal Verma <vishal.l.verma@intel.com>, Dave Jiang <dave.jiang@intel.com> Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Chandan Babu R <chandan.babu@oracle.com>, "Darrick J . Wong" <djwong@kernel.org>, linux-xfs@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, linux-mm@kvack.org, linux-arch@vger.kernel.org, Matthew Wilcox <willy@infradead.org>, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org Subject: [RFC PATCH 7/7] xfs: Use dax_is_supported() Date: Mon, 29 Jan 2024 16:06:31 -0500 Message-Id: <20240129210631.193493-8-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240129210631.193493-1-mathieu.desnoyers@efficios.com> References: <20240129210631.193493-1-mathieu.desnoyers@efficios.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789460549749989040 X-GMAIL-MSGID: 1789460549749989040 |
Series |
Introduce cache_is_aliasing() to fix DAX regression
|
|
Commit Message
Mathieu Desnoyers
Jan. 29, 2024, 9:06 p.m. UTC
Use dax_is_supported() to validate whether the architecture has
virtually aliased caches at mount time.
This is relevant for architectures which require a dynamic check
to validate whether they have virtually aliased data caches
(ARCH_HAS_CACHE_ALIASING_DYNAMIC=y).
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Chandan Babu R <chandan.babu@oracle.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-mm@kvack.org
Cc: linux-arch@vger.kernel.org
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: nvdimm@lists.linux.dev
Cc: linux-cxl@vger.kernel.org
---
fs/xfs/xfs_super.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
Comments
On Mon, Jan 29, 2024 at 04:06:31PM -0500, Mathieu Desnoyers wrote: > Use dax_is_supported() to validate whether the architecture has > virtually aliased caches at mount time. > > This is relevant for architectures which require a dynamic check > to validate whether they have virtually aliased data caches > (ARCH_HAS_CACHE_ALIASING_DYNAMIC=y). Where's the rest of this patchset? I have no idea what dax_is_supported() actually does, how it interacts with CONFIG_FS_DAX, etc. If you are changing anything to do with FSDAX, the cc-ing the -entire- patchset to linux-fsdevel is absolutely necessary so the entire patchset lands in our inboxes and not just a random patch from the middle of a bigger change. > Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches") > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> > Cc: Chandan Babu R <chandan.babu@oracle.com> > Cc: Darrick J. Wong <djwong@kernel.org> > Cc: linux-xfs@vger.kernel.org > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: linux-mm@kvack.org > Cc: linux-arch@vger.kernel.org > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Vishal Verma <vishal.l.verma@intel.com> > Cc: Dave Jiang <dave.jiang@intel.com> > Cc: Matthew Wilcox <willy@infradead.org> > Cc: nvdimm@lists.linux.dev > Cc: linux-cxl@vger.kernel.org > --- > fs/xfs/xfs_super.c | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 764304595e8b..b27ecb11db66 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -1376,14 +1376,22 @@ xfs_fs_parse_param( > case Opt_nodiscard: > parsing_mp->m_features &= ~XFS_FEAT_DISCARD; > return 0; > -#ifdef CONFIG_FS_DAX > case Opt_dax: > - xfs_mount_set_dax_mode(parsing_mp, XFS_DAX_ALWAYS); > - return 0; > + if (dax_is_supported()) { > + xfs_mount_set_dax_mode(parsing_mp, XFS_DAX_ALWAYS); > + return 0; > + } else { > + xfs_warn(parsing_mp, "dax option not supported."); > + return -EINVAL; > + } > case Opt_dax_enum: > - xfs_mount_set_dax_mode(parsing_mp, result.uint_32); > - return 0; > -#endif > + if (dax_is_supported()) { > + xfs_mount_set_dax_mode(parsing_mp, result.uint_32); > + return 0; > + } else { > + xfs_warn(parsing_mp, "dax option not supported."); > + return -EINVAL; > + } Assuming that I understand what dax_is_supported() is doing, this change isn't right. We're just setting the DAX configuration flags from the mount options here, we don't validate them until we've parsed all options and eliminated conflicts and rejected conflicting options. We validate whether the options are appropriate for the underlying hardware configuration later in the mount process. dax=always suitability is check in xfs_setup_dax_always() called later in the mount process when we have enough context and support to open storage devices and check them for DAX support. If the hardware does not support DAX then we simply we turn off DAX support, we do not reject the mount as this change does. dax=inode and dax=never are valid options on all configurations, even those with without FSDAX support or have hardware that is not capable of using DAX. dax=inode only affects how an inode is instantiated in cache - if the inode has a flag that says "use DAX" and dax is suppoortable by the hardware, then the turn on DAX for that inode. Otherwise we just use the normal non-dax IO paths. Again, we don't error out the filesystem if DAX is not supported, we just don't turn it on. This check is done in xfs_inode_should_enable_dax() and I think all you need to do is replace the IS_ENABLED(CONFIG_FS_DAX) with a dax_is_supported() call... -Dave.
On 2024-01-29 21:38, Dave Chinner wrote: > On Mon, Jan 29, 2024 at 04:06:31PM -0500, Mathieu Desnoyers wrote: >> Use dax_is_supported() to validate whether the architecture has >> virtually aliased caches at mount time. >> >> This is relevant for architectures which require a dynamic check >> to validate whether they have virtually aliased data caches >> (ARCH_HAS_CACHE_ALIASING_DYNAMIC=y). > > Where's the rest of this patchset? I have no idea what > dax_is_supported() actually does, how it interacts with > CONFIG_FS_DAX, etc. > > If you are changing anything to do with FSDAX, the cc-ing the > -entire- patchset to linux-fsdevel is absolutely necessary so the > entire patchset lands in our inboxes and not just a random patch > from the middle of a bigger change. Sorry, I will Cc linux-fsdevel on all patches for the next round. Meanwhile you can find the whole series on lore: https://lore.kernel.org/lkml/20240129210631.193493-1-mathieu.desnoyers@efficios.com/ [...] > > Assuming that I understand what dax_is_supported() is doing, this > change isn't right. We're just setting the DAX configuration flags > from the mount options here, we don't validate them until > we've parsed all options and eliminated conflicts and rejected > conflicting options. We validate whether the options are > appropriate for the underlying hardware configuration later in the > mount process. > > dax=always suitability is check in xfs_setup_dax_always() called > later in the mount process when we have enough context and support > to open storage devices and check them for DAX support. If the > hardware does not support DAX then we simply we turn off DAX > support, we do not reject the mount as this change does. > > dax=inode and dax=never are valid options on all configurations, > even those with without FSDAX support or have hardware that is not > capable of using DAX. dax=inode only affects how an inode is > instantiated in cache - if the inode has a flag that says "use DAX" > and dax is suppoortable by the hardware, then the turn on DAX for > that inode. Otherwise we just use the normal non-dax IO paths. > > Again, we don't error out the filesystem if DAX is not supported, > we just don't turn it on. This check is done in > xfs_inode_should_enable_dax() and I think all you need to do is > replace the IS_ENABLED(CONFIG_FS_DAX) with a dax_is_supported() > call... Thanks a lot for the detailed explanation. You are right, I will move the dax_is_supported() check to xfs_inode_should_enable_dax(). Mathieu
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 764304595e8b..b27ecb11db66 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1376,14 +1376,22 @@ xfs_fs_parse_param( case Opt_nodiscard: parsing_mp->m_features &= ~XFS_FEAT_DISCARD; return 0; -#ifdef CONFIG_FS_DAX case Opt_dax: - xfs_mount_set_dax_mode(parsing_mp, XFS_DAX_ALWAYS); - return 0; + if (dax_is_supported()) { + xfs_mount_set_dax_mode(parsing_mp, XFS_DAX_ALWAYS); + return 0; + } else { + xfs_warn(parsing_mp, "dax option not supported."); + return -EINVAL; + } case Opt_dax_enum: - xfs_mount_set_dax_mode(parsing_mp, result.uint_32); - return 0; -#endif + if (dax_is_supported()) { + xfs_mount_set_dax_mode(parsing_mp, result.uint_32); + return 0; + } else { + xfs_warn(parsing_mp, "dax option not supported."); + return -EINVAL; + } /* Following mount options will be removed in September 2025 */ case Opt_ikeep: xfs_fs_warn_deprecated(fc, param, XFS_FEAT_IKEEP, true);