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 3A9ABC47422 for ; Fri, 26 Jan 2024 19:34:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1A266B0093; Fri, 26 Jan 2024 14:34:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BCBBE6B0096; Fri, 26 Jan 2024 14:34:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A92006B0098; Fri, 26 Jan 2024 14:34:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9A8BA6B0093 for ; Fri, 26 Jan 2024 14:34:02 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7AF4C40568 for ; Fri, 26 Jan 2024 19:34:02 +0000 (UTC) X-FDA: 81722462724.06.B2DC615 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf11.hostedemail.com (Postfix) with ESMTP id C34B54000A for ; Fri, 26 Jan 2024 19:34:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=CYryvNhP; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf11.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=1706297641; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=h8pmL9jLWvvPTG0B7Jp8sr7EMU0Kb5koC3fZOQWO2zY=; b=adShzmgSBEo64BPb2uw9jzGwhA4ljzpfsv9sI+IsqfqTYnfUZMcQ0GTXHL6aQAOG9j7DD/ KBo46vhwuq+twItaJ/dRWvp34fitc/pXmY0cIE0P+/mQSpnHS4jF0WRDMwlO3c3uQPXeI0 X1WjhLzxsOaqNa3SE45rkL9W1rYfwtc= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=CYryvNhP; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf11.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=1706297641; a=rsa-sha256; cv=none; b=b+3Yb6MB+LMXFBJWsmfjQOXvwOf2B0EEDqrg52o66eDsw7fMo0WoLXf12h8gaPxoNZB/Oa TEK6QLzambOweSoLHuA7rJDxHlILp4VyGgaPYJ2l/dySIYY3UREcTbrQWgSJAOdnCO+0vh 32otLF0GRdXcKzBAyewE+xmPddGjztk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1706297639; bh=X2tv7YC7rvxoUUooCnssnmB276xID1n7i+KGcjgXyaY=; h=Date:From:To:Subject:From; b=CYryvNhPZbC7x2vM29ob6YlU9y7XqdYN1eE+S0JMTNZyFT6FwPl1FFNqD+a7/3OUg 363JrNqGqicCxn1V0gzmJktc5SGfN5Q8hC5GwNmbXcb319GcfZRSAdMDf2LQIX6oC+ lSxIcSLX3c/Ymagubv0PVRA6dDJJAjaAz/H1FkwBC/ixYQx0tXlnzCzCx5cOvEkold HkWWXgW0zcyim0acOvi0AoVPw1CIgk4mbGbJYNaEAr8+JhoLp0wx9vgkrPYTNu79IF KbWX5iKoCx6k/HjFrH1cjNfKeof6FDhCfoj/1KDcMcAr8o0JhZK5J+EMm/O1D8m9xo XOnbGShcIXNUQ== 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 4TM7D72M8NzVDZ; Fri, 26 Jan 2024 14:33:59 -0500 (EST) Message-ID: Date: Fri, 26 Jan 2024 14:33:57 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Mathieu Desnoyers To: Dan Williams , Vishal Verma , Dave Jiang , Matthew Wilcox , Andrew Morton , Linus Torvalds , linux-mm , linux-arch@vger.kernel.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-kernel , Russell King , Arnd Bergmann Subject: [REGRESSION] v5.13: FS_DAX unavailable on 32-bit ARM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C34B54000A X-Stat-Signature: 1h1uu3wh4ro978ww7rpwb7tyaett9rfh X-HE-Tag: 1706297640-154666 X-HE-Meta: U2FsdGVkX1+7QHL80VTJNKoJWywEQRizRXnef4JOjtQRdGejUbJIwspQigrFjImMY4WZHyx5RWVuRlIF8eSl62TUlRGuc1AhUgtmy8j2lHUVEyFkmDeLlvdWiFbTGb8dt4W8S29rY8OGFOJ9q9b80yLhbCQcmrD+jIPLIzffXAZifWiisyrkDl36WEkBoBglMEoRjpt9WS8k6req3cbe0FGskSwk952NqvDmmPTLB6iOpjmEDN5nhAdT+eq6J5c4HK5u2kcSqxYYxfjUhVKVo79F7Jg2cUJ/fu9pa4Km0Vt9FHnlvGT5SaaW3WsXUSGN23vwl1gQnpfRnjkH6i7zk7aL8yaYzrUebm8XHCqKZHRk3wjyRrDE80XePOB5rxYfhWrY3BV2QOiddr1+1BByelthI30wO2O7xs1LqKmTOIf5TaP0ic3L2k/QDJK+eGdLXFjOVN+SaMrTN+72am/bANMvrpPLemhjieZicWd419dYx61RDcj529YWikCdVEHmwA8tEGuYFqr+6tkqk5m9BaeftWckwMhlOS2asY+tLmlyNI6pjkFYfEFiQJZVc22Q2aUYE4j/E8QTj7QAmqZ8rKLP+GpwH3fcBLoa57WPGPeX2MJEy4ad54/YSwvLZ8odckeESlCIoXCD1DFndrCHj51gzpdGhOYjLIZQChPy0CFxbIOer16zhLnNsBpRRlnUcRXV5SNRSwsonaRcp/kBo5sihE4J+d8WpAtlsffIhikWh2FZquAjvfLKPqI04CZV2Oepv/0M+ZVLUIHso6asFzVsnbNRoAz+2zPekywu5oYxO0LVYx5u5LaLLpD7Ds0JPPGXWxIC5LQk/Nu67dH/jLRgYqfcprYz3alK6SG7+nBQ1agheaLamffCDWDXdemGcSiXVdiIm4DASLS8YXP1qMBdQIz64DGrUPOolwWBJ6i8ROSFELkWHt8qRRkOKQWfLCvDF5pTSRbviPij4bb ZH0eSY1P S2tdvHVPCurADWawOPbUOtDGo6cyu2pnrkJEUGaZXwd+hJ1BktIDnt4QEg0CdPgkKA/OqM/jIMa8BjLFCfCI3/ol+vj4BUgXt7A0/eambU/DX2bffw6GNboUMaGmFrGdpY61wJy/WwrP1a78aRjerzsdE3f1pzHPAuLTbbb4O3CB+2zod4uSkHSdiTWJ3Qi6xHC9jB22Ebo1Kbkl/Dtx+DFLbEhvyQoBVDqB9P91Xt9EGBrMMbdGJqkf2JKgqlg4ADc21zySIUXD+OKrnt8WfCXFnZAdxGwLQuzD76GEkRAOTNWHdn63pOQzMj4dYzqmqtvTqOmbOmvo/m2Gmlx+8ZP5YoA== 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: Hi, This commit introduced in v5.13 prevents building FS_DAX on 32-bit ARM, even on ARMv7 which does not have virtually aliased dcaches: commit d92576f1167c ("dax: does not work correctly with virtual aliasing caches") It used to work fine before: I have customers using dax over pmem on ARMv7, but this regression will likely prevent them from upgrading their kernel. The root of the issue here is the fact that DAX was never designed to handle virtually aliased dcache (VIVT and VIPT with aliased dcache). It touches the pages through their linear mapping, which is not consistent with the userspace mappings on virtually aliased dcaches. I can see a few ways forward to address this: A) I have prepared a patch series introducing cache_is_aliasing() with new Kconfig options: * ARCH_HAS_CACHE_ALIASING * ARCH_HAS_CACHE_ALIASING_DYNAMIC and implemented it for all architectures. The "DYNAMIC" implementation implements cache_is_aliasing() as a runtime check, which is what is needed on architectures like 32-bit ARM. With this we can basically narrow down the list of architectures which are unsupported by DAX to those which are really affected, without actually solving the issue for architectures with virtually aliased dcaches. B) Another approach would be to dig into what exactly DAX is doing with the linear mapping, and try to fix this. I see two options there: B.1) Either we extend vmap to allow vmap'd pages to be aligned on specific multiples, and use a coloring trick based on SHMLBA like userspace mappings do for all DAX internal pages accesses, or B.2) We introduce flush_dcache_folio() at relevant spots (perhaps dax_flush() ?) to synchronize the linear mapping wrt userspace mappings. (would this work ?) Any thoughts on how to best move forward with this issue are welcome. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com