Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp1932324rdb; Wed, 31 Jan 2024 13:46:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IH7C2oHf6Bt9wNS69M6mV+QRabxN/Hu0ZWFEB1fXAWafwpY+mnYBgi5HuiM4tcI3t3KFwts X-Received: by 2002:a17:902:b20a:b0:1d8:e64b:b544 with SMTP id t10-20020a170902b20a00b001d8e64bb544mr5093229plr.59.1706737565023; Wed, 31 Jan 2024 13:46:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706737565; cv=pass; d=google.com; s=arc-20160816; b=DdsWL9TXmWpMBQVipH5TkToncaCBjC8WVimlvpsWk3mhlZ2GJEpGI4RPKl+qWb/hNw 2zdpWvjYSrnyB/yt4Mx1qbHV9y7jUt3mkSwgholEiwQo3Yzfo70bo2Mx4btyVCBgp0Xg 2hrKnZYN2gBXzOQoCEqR/P3jo1GOazt342kzNaKXw4XX0cG30IcsvdoCGepPSVE0rWRh jLNnWZwkGwF5HiPHSbBq9h8iCJXDtLOmlGAAf23+ZE3HfGyuldw3kZwUPP1XoFJM+AqV 8mTteklcyB9J9PvORs2Ia2da9ew3RQ1QycGVQB40l+9UL48soIL4nDsMd7Uh1cA6H1dn Eflw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=jH5ltorO19gdIzaeVZlF+kHFM8VAXcL8PuYCh6jRXh4=; fh=2TU3kQMKUNU2UyHAPmdqAdksM9QXEUaxgvp0ZULvPQI=; b=T3HntGPFzq9Cd5ReHiVGo1SAokydAnR4fmMDj1SV9E+BJ7niHzEB0zciG85tWS5H2I cgNMVBeGpXJn9m6Las0FAc4X2so1LTHtRke6u4dIbjEoi/AxjYCyixawxyPk6CxIN3L4 Ya9uKmXcdeJJfirdPGuvCQ5lYKmdZAveMRPs9M23MruWF87TclM4k68Gtroz0ZP//yhd 17XDU5am29Vb88DO8qJ0FaeBoZ1G2mWDVu4QhW5eFB7LyMIbsPLaKym0Ij3jp/jT4ZEZ X3ZEpGTHqCys9j/9wCNff1QfY02f3q/fXp+iuDQA61Zt6aAg8x5zYtcWqZbsd3ARaMRP 2aZw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b="fOC//W4u"; 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-47181-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-47181-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com X-Forwarded-Encrypted: i=1; AJvYcCXXq7ViFlx7iRottnjX7Rn4HWrAdVp0TrO5CrMjJdpHem6OCS5BZI7bCzNHkefDBErQ0SJrW+6rbcbKXkSQ1eF6zUhkJO4dJhXUqCcmGA== Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id n188-20020a6327c5000000b005dbd253d1dbsi3336262pgn.292.2024.01.31.13.46.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Jan 2024 13:46:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-47181-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b="fOC//W4u"; 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-47181-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-47181-linux.lists.archive=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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 2443AB2374A for ; Wed, 31 Jan 2024 21:40:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B1A6D39AE6; Wed, 31 Jan 2024 21:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="fOC//W4u" 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 07FC139AD5; Wed, 31 Jan 2024 21:39:58 +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=1706737205; cv=none; b=SrNvB8ldP369edt93qyE3oAT/GUg/WDVpX3EwcPmeOxadjHTJ44dAbeCiJ6zrI9Q55WzljE6Nimr2ZDbjVtjV19avWg2ut+oxErPoNdamm8H14ZlqWGY1OX/jrbYnpAnBa8vXtSafZTrMXi5V2bLDFN52SIG7sHrjSI1jxPH8JY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706737205; c=relaxed/simple; bh=mE6IlMP08TpBgXOVDJUm71vva4w7+fEDZV65jtPKtXc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YwibD+Z+/v1bs6uMmkTlD4gvfntMN3EWbrldjhl2MraId/jE7SbsyOepiqb0C1WOSgVg3m0zjpmya7SahKwVedFlMY0N/Vv1yHKnxrx00XqHQKrTRD2IUAp/kKTgGgmRXLy1h4dhvQXz2/qKUfpGh5T+8trIkRDdwL1Fqo52bX0= 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=fOC//W4u; 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=1706737197; bh=mE6IlMP08TpBgXOVDJUm71vva4w7+fEDZV65jtPKtXc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fOC//W4u0F5vbdt+tU+rP15v/l0o/+CnIg+Ydp5bcNwGYw9ud2JP/HNwuD+X2eYWY AXE0QkkFuowfQF/N5KDNWKA1OtehwKwu++g42TntpSKmR0HWSQ8OE00hj0DK1lZL18 0noEqFv4pzYCqQ+J9lGKMSW8o44r71joP5nDgCjEpRokBxY0mzIcRAvO9I+M5X6Nje 0/WsjNt0cTRRaf74shtLNuDJXD/6td2e/pOr42o6HxQ8MWLaI1gQRslqQNLtk7faOo 2+zPZgyGqKquMsySa1E3H6j3vwxgx0Tn5FOmPizhrqqkpYnf8Hg+OKkQ2KbcVBQ7P1 HUgiw7TX/NJTg== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4TQFn93W8xzX1V; Wed, 31 Jan 2024 16:39:57 -0500 (EST) Message-ID: <0a38176b-c453-4be0-be83-f3e1bb897973@efficios.com> Date: Wed, 31 Jan 2024 16:39:57 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 2/4] dax: Check for data cache aliasing at runtime To: Dan Williams , Arnd Bergmann , Dave Chinner Cc: linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds , linux-mm@kvack.org, linux-arch@vger.kernel.org, Vishal Verma , Dave Jiang , Matthew Wilcox , Russell King , nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@lists.linux.dev References: <20240131162533.247710-1-mathieu.desnoyers@efficios.com> <20240131162533.247710-3-mathieu.desnoyers@efficios.com> <65bab567665f3_37ad2943c@dwillia2-xfh.jf.intel.com.notmuch> Content-Language: en-US From: Mathieu Desnoyers In-Reply-To: <65bab567665f3_37ad2943c@dwillia2-xfh.jf.intel.com.notmuch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2024-01-31 16:02, Dan Williams wrote: > Mathieu Desnoyers wrote: >> Replace the following fs/Kconfig:FS_DAX dependency: >> >> depends on !(ARM || MIPS || SPARC) >> >> By a runtime check within alloc_dax(). >> >> This is done in preparation for its use by each filesystem supporting >> the "dax" mount option to validate whether DAX is indeed supported. >> >> This is done in preparation for using cpu_dcache_is_aliasing() in a >> following change which will properly support architectures which detect >> data cache aliasing at runtime. >> >> Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches") >> Signed-off-by: Mathieu Desnoyers >> 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: Arnd Bergmann >> Cc: Russell King >> Cc: nvdimm@lists.linux.dev >> Cc: linux-cxl@vger.kernel.org >> Cc: linux-fsdevel@vger.kernel.org >> Cc: dm-devel@lists.linux.dev >> --- >> drivers/dax/super.c | 6 ++++++ >> fs/Kconfig | 1 - >> 2 files changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/dax/super.c b/drivers/dax/super.c >> index 0da9232ea175..e9f397b8a5a3 100644 >> --- a/drivers/dax/super.c >> +++ b/drivers/dax/super.c >> @@ -445,6 +445,12 @@ struct dax_device *alloc_dax(void *private, const struct dax_operations *ops) >> dev_t devt; >> int minor; >> >> + /* Unavailable on architectures with virtually aliased data caches. */ >> + if (IS_ENABLED(CONFIG_ARM) || >> + IS_ENABLED(CONFIG_MIPS) || >> + IS_ENABLED(CONFIG_SPARC)) >> + return NULL; > > This function returns ERR_PTR(), not NULL on failure. Except that it returns NULL in the CONFIG_DAX=n case as you noticed below. > > ...and I notice this mistake is also made in include/linux/dax.h in the > CONFIG_DAX=n case. That function also mentions: > > static inline struct dax_device *alloc_dax(void *private, > const struct dax_operations *ops) > { > /* > * Callers should check IS_ENABLED(CONFIG_DAX) to know if this > * NULL is an error or expected. > */ > return NULL; > } > > ...and none of the callers validate the result, but now runtime > validation is necessary. I.e. it is not enough to check > IS_ENABLED(CONFIG_DAX) it also needs to check cpu_dcache_is_aliasing(). If the callers select DAX in their Kconfig, then they don't have to explicitly check for IS_ENABLED(CONFIG_DAX). Things change for the introduced runtime check though. > > With that, there are a few more fixup places needed, pmem_attach_disk(), > dcssblk_add_store(), and virtio_fs_setup_dax(). Which approach should we take then ? Should we: A) Keep returning NULL from alloc_dax() for both cpu_dcache_is_aliasing() and CONFIG_DAX=n, and use IS_ERR_OR_NULL() in the caller. If we do this, then the callers need to somehow translate this NULL into a negative error value, or B) Replace this NULL return value in both cases by a ERR_PTR() (which error value should we return ?). I would favor approach B) which appears more robust and introduces fewer changes. If we go for that approach do we still need to change the callers ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com