From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E24CAC47DA9 for ; Tue, 30 Jan 2024 02:38:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7685E6B00CC; Mon, 29 Jan 2024 21:38:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 718406B00CD; Mon, 29 Jan 2024 21:38:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B9946B00CE; Mon, 29 Jan 2024 21:38:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4A5C76B00CC for ; Mon, 29 Jan 2024 21:38:53 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E466A1405E2 for ; Tue, 30 Jan 2024 02:38:52 +0000 (UTC) X-FDA: 81734419704.23.33C240C Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf16.hostedemail.com (Postfix) with ESMTP id 2FFA3180004 for ; Tue, 30 Jan 2024 02:38:50 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=Et6YdpUx; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf16.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706582331; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hqxjY1ElxNAwoveLPHwWFoaAKo7t78H+KCuILCPEg64=; b=JApOf0kwPcSV7u/H8GLs+5xgRqCtdP7dViWHM1zryFQs33BGpQKdXGpXWCCJzC4xgT/Twm /YsW8P/F7l5dekZCBLqVsU9ix6W7Z0rJSimjEHL7DULzCZNek7/NAX/boq1i5k9WGuQRjd JSmDn6c3T7xQl8pabRhVDqzqJ3sqg/4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=Et6YdpUx; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf16.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706582331; a=rsa-sha256; cv=none; b=HFIbD7LR2yu8sfbQn1OTn35+tC/aSKofqWdMSDm6epefGLKpjOITvCoYRxyEY3ogV/syee 8OATNPJGVSKz7M2IYcS6heWW0NrHcHkgXRpFiycjARJ2eR4u+1Xx6d9HwmDsRCx4pRvFC+ ZOVvN4MUszBNXGbXgJg6PWpKfOgwo8M= Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1d8e78270c1so9623375ad.0 for ; Mon, 29 Jan 2024 18:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1706582330; x=1707187130; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hqxjY1ElxNAwoveLPHwWFoaAKo7t78H+KCuILCPEg64=; b=Et6YdpUxTULoBb+LtFSaG8+BuIraWfh1QKFxHsTc1+7FO3x8aq65qdHGBH3tsskBq8 JHciDuuMOd0ByomQhMNW/1dAcftm7CQOnVhV380Vs3/aILUagwdRDDhWAvl+vLw9fJT1 IzAvVNxrhYPS9dZ+JZuIVydSybqnCHIkmRnqjfHAfpdd5tUojKPHOdJEsg5/YV7RP7dr wj5gFhXyOFOjTvRidHg3TusEAJX66gDtZov4J3qAcYglsM5YSOJzmAd6Yq6MBnn/+QBW 4COzQC/fkb+hpvRIjGJB5WQRJm4Z7VinlRHPz48dazcAigQEQITV4sVkMkFlXrznt9NV 2eTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706582330; x=1707187130; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hqxjY1ElxNAwoveLPHwWFoaAKo7t78H+KCuILCPEg64=; b=smCeJmiOmd8o+CMPKFQvbpxSiov2wqHOrZYQUscAG2gGLWz4BKAvXoAAMziOu9NZZC HgzbjRHsL9WYIZs1ObfxvYpPv0SpL1ssd7gjuZ/eBuVbV+lTpRhT0cDBDrTd/vEhti5b BDXCl0dEnc45D6QxepvQpm3zkmowLUzuBeJ1+Cnkw68TquDKcGkRMymHUqqXNgta+eyA CQm2zdhUkzGy+Ti7bi39E3Oa4wIeGcMIbgGKPRHBw/cohtivLcSElaPLFspo3GlHFisB UHL0NdRW7akXGeicCwFwUXv+aRcvKFBlAHGpHDJNLCIXn1u+sjseJ9YU12yMFkRAz+BE SB3Q== X-Gm-Message-State: AOJu0YzVifo+/lMLLxmvkjVN9d4vL1huRgGNnzsSHRyMTrBuNeXHNjUH Qyr3/H+umsan6zI5qgQv8AM/bvH/3T+pcDCmdkMfrGCN0Wm6Hj5GCv2pxp3mIUc= X-Google-Smtp-Source: AGHT+IG3Tf1LicjzS4Qa3v1HBWJ0okdxx8XgE9n1laWHdO3qtQvRbO5N3KnA5oTi64pctq5hmJtDrA== X-Received: by 2002:a17:902:d550:b0:1d7:1a90:65ba with SMTP id z16-20020a170902d55000b001d71a9065bamr500304plf.25.1706582329913; Mon, 29 Jan 2024 18:38:49 -0800 (PST) Received: from dread.disaster.area (pa49-181-38-249.pa.nsw.optusnet.com.au. [49.181.38.249]) by smtp.gmail.com with ESMTPSA id ml8-20020a17090334c800b001d8fb16118csm1038823plb.267.2024.01.29.18.38.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 18:38:49 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rUe1O-00H85k-2a; Tue, 30 Jan 2024 13:38:46 +1100 Date: Tue, 30 Jan 2024 13:38:46 +1100 From: Dave Chinner To: Mathieu Desnoyers Cc: Dan Williams , Vishal Verma , Dave Jiang , linux-kernel@vger.kernel.org, Chandan Babu R , "Darrick J . Wong" , linux-xfs@vger.kernel.org, Andrew Morton , Linus Torvalds , linux-mm@kvack.org, linux-arch@vger.kernel.org, Matthew Wilcox , nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org Subject: Re: [RFC PATCH 7/7] xfs: Use dax_is_supported() Message-ID: References: <20240129210631.193493-1-mathieu.desnoyers@efficios.com> <20240129210631.193493-8-mathieu.desnoyers@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240129210631.193493-8-mathieu.desnoyers@efficios.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2FFA3180004 X-Stat-Signature: h5mdrephpsjy9y4tnnophq4ame1urap8 X-Rspam-User: X-HE-Tag: 1706582330-323747 X-HE-Meta: U2FsdGVkX1+uimhbysFm4An9wP7gRjXFIx1r4XuSHGnS1DG32z9WHSTB7r4nE/uzKb/FhcEMm+0x+pq2qTWaRLRTX24RFZBBqumfjswpp5VctJ1A83lnrVzxxX6YxLOCqwZx/gvkwl7ewnULfSGqEiwtPzjf7jeBxSA5sBSkHhIq0oGDB8n4efOvBjLW3ERlnZqw2XD6ghZhYR+OtAt973+X31xA1pIKfeI8Bqdk0h9x1gkGriH/55HRXWlLZ22lMlexyIpoFC2jQJ1O34r64gUvHPhl0HwKxhIKPAH7exIgUTEU0MUTcz/+APLkdTQ5IPdDOEsz1yLQHwnVXSMsKLJ0wUIFA/UWK0UDzG+v7VNMnJHv+xv4ZQlZ0kdqT9k4GXH14XudmrPIRn4nqUwr+bbGybqTlWxq9rVlyn33zNnZcX9byUVWzplL1GXr4MCUJHg5RdFKKlD5/ljeub4AVk0BXBVBKd3eOXhZrqpsCXslSkFcGKFJ8gP4/1sTyDC828lGc3yDk2b7ezhsd1SDVV/8oD2OOJ633PkBTJyn8zNY+Z0iTc7lNt8a48ZWIxw2JQyu5KeCJof91J4mNx7rqO63MY+3yYQmaYCkKnjNVxSLIVvsElF3ywYz1dwN6OB+M0dtDEhpIUqx7EZmA64dcsShIkG84F5Wc6ZB5fiAlB8soZmPZw8SFCSn7v5BnSUuYBrM45AsGBU6WQVSpcCC+uSQTf/WH+/L/+5fKEcethFt9Dj0EvoEAWL2+049n3C8X1EhCmSHW2DA/ljCjbKQNMulog4oaieGnXGRGKhs4tXFuzKc2NbfG9qmKef9UExHEHJz/5WLBXUe04NsaCehJ9oyRYk70+RFTuK4Qd416JHX00NtJRoMILI7RXKPxPLhwj5qNdu10LUwuZFW+i1T5EQuvaehIiMH/wDIHLnH8Bnqbp8UtF1Qdph4mC2DKdli1WI++pMxkxcRlUHk1Xp ZQX63CkT YfmuqStQzx/k0p5hdVtbPEsc88DLkhVhlWncr/q3cJ5iuZHVp0kDKw5CsZeSLxM3Z2CQqtvZZfvUymejw8IuwjuH2FBWMdNgkOCqHRW9EbkEPkdiEOOHHz6a2okVYLk1U+1HcHK/O+9/0Wq4uHH1L4OZkqqxJh+CdIGAfGJqxj5qbMQs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 > Cc: Chandan Babu R > Cc: Darrick J. Wong > Cc: linux-xfs@vger.kernel.org > Cc: Andrew Morton > Cc: Linus Torvalds > Cc: linux-mm@kvack.org > Cc: linux-arch@vger.kernel.org > Cc: Dan Williams > Cc: Vishal Verma > Cc: Dave Jiang > Cc: Matthew Wilcox > 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. -- Dave Chinner david@fromorbit.com