Message ID | 20240202210019.88022-9-mathieu.desnoyers@efficios.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 1DA6FC4828E for <linux-mm@archiver.kernel.org>; Fri, 2 Feb 2024 21:00:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B7E06B0092; Fri, 2 Feb 2024 16:00:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 423066B009B; Fri, 2 Feb 2024 16:00:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19F806B009A; Fri, 2 Feb 2024 16:00:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CA7856B0099 for <linux-mm@kvack.org>; Fri, 2 Feb 2024 16:00:32 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9B88E14078A for <linux-mm@kvack.org>; Fri, 2 Feb 2024 21:00:32 +0000 (UTC) X-FDA: 81748082304.17.35370EA Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf08.hostedemail.com (Postfix) with ESMTP id F0E5E160002 for <linux-mm@kvack.org>; Fri, 2 Feb 2024 21:00:30 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=pmLoboe0; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf08.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706907631; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8wpHKT9Hi7IbUfkZ2WanEEBa5TZxfFZsQCKHq9VYM5A=; b=omdXkN+ANYU+fc16emvu0An8A+RQ7/YOypFMhoS2WgDNfmzez+ZMH0JuaMacbMK78SrFfF blY7gvJSNuYKi2J7kGJ4cQlrv0NYT31OAtWC4JkiWCsN4tx2uph/XaMHnKGQKfOIgRR0W3 DilfsaEJgpa/+tNtmBTFJWFXPz/zUBM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=pmLoboe0; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf08.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706907631; a=rsa-sha256; cv=none; b=qEHJokIZP2LEwqpsT2x2j2dA5XQmhvkc1ANfyJUCVBkbRPJktonqsadmRY+7+LTvXPGSCv BiIlH9zkkpcjEWvfKLZl5x6E96wl2jbDbpT9QD5ioJyyiDHjsplRn8ENs9tSVui0WoCVGn ytTZZ53Xht7zFTAgXJQUDGgalu2S0nw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1706907630; bh=MgteUY0CjaNYCNu4ZJjdjfbOYQwaLS6hDEa6C2rXhOI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pmLoboe0biQmKhxDQSLFLxe9fj2PBsN9j380mMLjyT2JWK4NKO5DYgC1oKms1hE2X mfyhAqyK/4sWjvu2qrc9U3QSqaqdyPHsaoH3DXLzgSTf2MpcJhENZ7zYoOFFmnOuBS gq8dm7ShaBHLybdKCaEnCossjL+YsNN4tFqYabm5/ufcyshuoiCyl85YvJNrai7hcD g/MvYLbhc2C8SRDi3vXOv1e/GsbbwcSRytwt5wh6vd4lIvjdXNaK3Rv4NQtXV9mGyQ qRZcVkbjwe9zctNTJvb9TxZ3hp1mRdRztkjvgnCT6YZP+6xeRdYi1Vjd3i0T8hyz6s 5wJOddiVYFkFw== 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 4TRSpk0JNRzX4W; Fri, 2 Feb 2024 16:00:30 -0500 (EST) From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Dan Williams <dan.j.williams@intel.com>, Arnd Bergmann <arnd@arndb.de>, Dave Chinner <david@fromorbit.com> Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Vishal Verma <vishal.l.verma@intel.com>, Dave Jiang <dave.jiang@intel.com>, Matthew Wilcox <willy@infradead.org>, Russell King <linux@armlinux.org.uk>, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, dm-devel@lists.linux.dev, nvdimm@lists.linux.dev, linux-s390@vger.kernel.org Subject: [RFC PATCH v4 08/12] dax: Fix incorrect list of data cache aliasing architectures Date: Fri, 2 Feb 2024 16:00:15 -0500 Message-Id: <20240202210019.88022-9-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240202210019.88022-1-mathieu.desnoyers@efficios.com> References: <20240202210019.88022-1-mathieu.desnoyers@efficios.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: F0E5E160002 X-Stat-Signature: 3o5b61mgyieyog5npe6dxhk5ja4ir9ud X-Rspam-User: X-HE-Tag: 1706907630-97069 X-HE-Meta: U2FsdGVkX1+xet3PxI4f3kb7eAHRPeX2h+lhS2S//5YDErLyozEtWOZy0vIWlh2UnWl0cO//xoKutQblNKwqzyOeImBi/2cjwQ5EaOA1QVXW3LnnAFMH1Sb2BjO26TfdCi/vIf35ajcs5bYJfVMLFjrzDbLsPeRfQy/EKvG1sFNkimfToIyjGCtr7HhX/umqTzWuLCXVdaPVmBfzxdJRICtRmgbHkO0Jo7jTvfCwsjuojVC5+olCxjwdNDd0CSDYg21usojdRnAKC2vV76yu9i1RXNUQbSMJ6xhxcBPi6u9Sz+xTLCV58gm6ZWxurAOK3nLT2iqcr5CYwRnjRgcnKp9GpV/bqW1zM0ASKMvk5FpCwtuKAFxB/Xf8Ev1TeUCncSmL9pnHutfR+cNHEbfr7H/tN9WMfs8XC+m5ImhPtH3oHu2iKOvnRxOzfOP7q2ao4a29Z/7JQgzMESVE8592HrwG250TEPz1bV/Dbh9BaF/Hhi3R75Vc/mxxgyd4lbirdlLjCL+zePLWNr4T6l1MyPDXvuHnZT8J2dq3m7dR8T5+YP/MZ58gSHHltKwXrahILMluJ6CE/PmF19J0Ci485TcgNeRXI+O6FWGLDLhxhJWAajbNyfHzoeH4l08OT57AYmbY2z0pOAFCHztI4odg2PsjV1Wj8cxeZxiYY0mYUV6CvPU7YVVNJ8qpNm20xSql1tnxQfKVeNTtPL8o4fDXiM0Gy/ihnW8F27Ni/8X2EW/eLly5BGDjUG/Nx2sgN36wtEGHASfRRiulaH7749D5POZsjVOhV66krdTOFKFsprrwy0GMxxz7l6mX0a1yUM+Duk3D3DU81MdSxJY5mxqNooQgjZC2f3Ofi6lU2udpKsch804Q0Jcb9QS73mWFHhS51RZPHKTTkDnL/DZd8HsXCFBipWqc7wlA1cPgxUVy7AzmenUmQzp5/e/27icw/fmI2Q6IeJ7Ksgehplp9mjF VKUu7Q97 ctLsdfBqdVTQ6c0mF2hRQQBh62RP+Asjg615psZSY7p1HrSb3I81DcU+XoUk15e3fBEQOxLVAFfVtHY7oJkOGE9PLiy4f5qWAuLmtNEKYXvnll1dCJIxyOvQDaMpUHUqOiJaj1lAF4KYJq1f5Jplq1HKDeDzlbwE3IQWWEcMPQNquzNa9dpByU3lUMAhbkkPvarl7Rsl7u1VbNLuz8EvqURa/sL+K+W/06FpI94o7IUa4XrAoWcZHJj9PVQr7S6eHuMvGtipYuhWoKloQDIKk9fbOYOW6zGyMjVEfbM8j0f9f5JGaRM/D2YE7pSn6bYdTxWX9tOTdzm2piwapu8vapWegddyJ0lruKFJ/j4V7Tk1zwhJNlWLeVeo3U9k+FiD7Jtc24zV+D5IMN75ZM0ix34RfwyEHrBqN5ZFHgOHBl3yHLLp2sqJgERD0EhAoTzIA2nj1eqhSseyzPeAxXNihiJYOLnS168EyAiaHuyDrHi3Y+DF3sztO1NT1gzahg+zGZDlRYMLygTHUfer7B4v+egar2Scvzq9gAACTaq8cf2Mih8JMbE7VUu/f+agyNjxPx+4k 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
Introduce cpu_dcache_is_aliasing() to fix DAX regression
|
expand
|
diff --git a/drivers/dax/super.c b/drivers/dax/super.c index ce5bffa86bba..a21a7c262382 100644 --- a/drivers/dax/super.c +++ b/drivers/dax/super.c @@ -13,6 +13,7 @@ #include <linux/uio.h> #include <linux/dax.h> #include <linux/fs.h> +#include <linux/cacheinfo.h> #include "dax-private.h" /** @@ -455,9 +456,7 @@ struct dax_device *alloc_dax(void *private, const struct dax_operations *ops) * except for device-dax (NULL operations pointer), which does * not use aliased mappings from the kernel. */ - if (ops && (IS_ENABLED(CONFIG_ARM) || - IS_ENABLED(CONFIG_MIPS) || - IS_ENABLED(CONFIG_SPARC))) + if (ops && cpu_dcache_is_aliasing()) return ERR_PTR(-EOPNOTSUPP); if (WARN_ON_ONCE(ops && !ops->zero_page_range))
commit d92576f1167c ("dax: does not work correctly with virtual aliasing caches") prevents DAX from building on architectures with virtually aliased dcache with: depends on !(ARM || MIPS || SPARC) This check is too broad (e.g. recent ARMv7 don't have virtually aliased dcaches), and also misses many other architectures with virtually aliased data cache. This is a regression introduced in the v4.0 Linux kernel where the dax mount option is removed for 32-bit ARMv7 boards which have no data cache aliasing, and therefore should work fine with FS_DAX. This was turned into the following check in alloc_dax() by a preparatory change: if (ops && (IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_MIPS) || IS_ENABLED(CONFIG_SPARC))) return NULL; Use cpu_dcache_is_aliasing() instead to figure out whether the environment has aliasing data caches. Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.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: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arch@vger.kernel.org Cc: linux-cxl@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-xfs@vger.kernel.org Cc: dm-devel@lists.linux.dev Cc: nvdimm@lists.linux.dev --- drivers/dax/super.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)