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 574A9C47258 for ; Wed, 31 Jan 2024 15:14:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D829A6B0085; Wed, 31 Jan 2024 10:14:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D32876B0087; Wed, 31 Jan 2024 10:14:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD2A36B009F; Wed, 31 Jan 2024 10:14:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id ACDB56B0085 for ; Wed, 31 Jan 2024 10:14:28 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 32459160583 for ; Wed, 31 Jan 2024 15:14:28 +0000 (UTC) X-FDA: 81739952616.05.F5BEAFD Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf13.hostedemail.com (Postfix) with ESMTP id 6933520015 for ; Wed, 31 Jan 2024 15:14:24 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b="mi4L/ndK"; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf13.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=1706714064; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4h4Yom7PGeqeHberPybkgdo/udulVd69s4rx+63Rs/s=; b=KUJGr60TsqHtPNnMfL/T+KY22G7D5EH/JZu9sf3TeHSJ6Wf2fRCiPX+nOGHBVTFUa3rMwP F+FxqmwtLL/5oenwghCCyu6W1vsdQB4uuUxxc6+l7L3AXchMvuCbbJ25ZBNQ1ARL4Yz7Zw rlB8pkeWRH5d9LEwCbJuoK5jEhZDkb0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b="mi4L/ndK"; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf13.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=1706714064; a=rsa-sha256; cv=none; b=7tlMNgMo4uICnsWlnIoxdc1GHG+535DVP4mChwgoZysY/EwHmyPiE5pkLLecEAraIAsIh+ X5+wdhayGmdiXHRUPQuzV2jDkmGuIcNBWa2nhEcGn6Nl3MuRZPfFOJxxhgxrAJsdf/iJl7 byrefSLMi8qKII8Un+NsFrPX6EnMGWk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1706714063; bh=LN6ptRJUKoEZK47ZsEQ7EYUHNkUE/4Zcp52rPav6Q98=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mi4L/ndKJYIE2tvied3UllOOolXpuP+5XJkhxDlpOjXFz9eVyM+OxizFpTHo7dlzc H92J3JjtdsfeHnmpa2eKx7E0S/kfA1pLWmUg8qwt2zujs81BZ5WdFEMDRsLuuT05C5 Lz6Q/JxTiSnCL5+MxcTDJHK8LWWfz+qSgMcfBMHfvCXvTCzzNPycjZ690RDkMf9hml vWVYO3IT3UJHXyg/GBxWp4DfG7Rq/AxQl3X0cVo/fOTDc8xkQ5m7R015zRazXmurV/ BqLAtP/1E63aNpekcxTtzLBTvH50ikczfmB43w1kTs//Lck6MZ4zUuK9jWW8iwjWUz IJT94AyP2XvQw== 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 4TQ5DH1bjkzVrT; Wed, 31 Jan 2024 10:14:23 -0500 (EST) Message-ID: <654c13fd-8c54-48e7-921b-1503e37f1455@efficios.com> Date: Wed, 31 Jan 2024 10:14:22 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 8/8] dax: Fix incorrect list of dcache aliasing architectures Content-Language: en-US To: Dan Williams , Dave Chinner Cc: Vishal Verma , Dave Jiang , linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds , linux-mm@kvack.org, linux-arch@vger.kernel.org, Matthew Wilcox , Arnd Bergmann , Russell King , nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20240130165255.212591-1-mathieu.desnoyers@efficios.com> <20240130165255.212591-9-mathieu.desnoyers@efficios.com> <65b9babf6b3de_5a9dd294de@dwillia2-mobl3.amr.corp.intel.com.notmuch> From: Mathieu Desnoyers In-Reply-To: <65b9babf6b3de_5a9dd294de@dwillia2-mobl3.amr.corp.intel.com.notmuch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6933520015 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jfwtoo967eg93dgp7hqikh8swk8djfy9 X-HE-Tag: 1706714064-396465 X-HE-Meta: U2FsdGVkX19qBw+jAnV6BEkpQQuOc/Cth2EVCeRI+kf+dIVmDsOtjW4lG17zThrXxUfZvqEzLtds1bNNmy2x+BLks/i4eZq+kzt1y4FZsTbtB1EVTHloywiytVMqs+NW+xlXPWhfwZx45aOlDrxuG6bL0J5ABp8PmVSQym+8ICzYzzz7O95FNMvPDkWhYGkrNJK+/6zPeNunshU5M6lMqfOTKHYO83AcQIB3l1TualCKIF/yKlgPuKxTDJymIsT0ljZxNrXHmBx1MvhY5OhrIxUnI9Sfdetuvu6/C+nYmSPlbo7gcV408PV4CIGTMbsUc7YuIbI0BRPN/AhrE+V/m0Qpt7aAa59tkuZc9th8UD11MN6gKXN/jOP+uCBOihokvmeMAW2CqiGX/WyXLWLIRsBxoZxDbNQzj01wDWD8pKMKm8mERzdTzUBGF0wNMHSqPoLEfw2GteM81wyZjiffsWK5rh2kRz/0bsS8yZojQb2WyFEk3PxGuQQKxDikw1Jn+UQWTjecOLFrXxZGx8fKsxbdE2GcfVjyS1Lzw41/rgHtUU6uNlWH3O8gzlZtTguPgguQ2oxmzk/NgPf0tpnZzCKprddnJmCI8Dx2UxukMZiuO0Hf5RvAUphBNwxwbIG6vaNTxICFKW23dLip3OAxvXo4/v7CXHMddzZHjUEwjz5ZHfZV/ThKGkti7D1WtFG7u9Y8pfHHIGWQeL7nkrX/oxh7073eARrJG/axqiF+Y07MM2DZiifOIvph6tjjCn0D2AaiSMgXYjzfX7k9J1EQbuAQmj35HtHOGTJ903E59YwiYkaujvOVDpzonHQhbu4mI9nxdx9m7hWdxVT5Bf4PsmTh6oHnjv8OsztFG4Gv1Z9oWq8RQ1AsESrSUIGbP4tHJBLU/EPLpnAF8FN/91NBkKJTfX/DyOCb1XeEHBPsR5O/O+4q2r6DZA4BSbCtqStdH+EU39eOp8f84kX/6+z UF206GwE rSZQN98w5mhSArxTrkbwEuhnfzYEyVNQNXM5NRp9MDeG5mKLRu0cihAdytgNGsX4C24fRyLF0iF4JfQxEvk1H2c4J2xlG6ktnwX7mCEPW6cPV4RIjbB8ONfymytJRdX6xWV7RJZVS0NuB2CvHjQKQHwtxcTG6G0T6P+yewXKg0GsozaVuhRfqC3lOEMxipS3n0vfetjxKWMOkhbl77LeN7yvLJhiMj32rdhlxqJ0S6uw/v/4njKgBgyazd6lcrAPWVL60bjxgJC2dFObXHKcTfDOxZJgjBgN6cJ8q16nJifv8X24QUSErxcs7/0KknASGqcNUxhmDGK8GH2O3lTD1AdYkGI2fhCyxOdbrY9jcQrzipk8rIdf2anA8WsBvfaw/PWPk6anCylNBatiAI4+S8gqNohLHOYMzerASw8oz1zdewBcvXE/qHgOYyANcdD3g9xLCh87DVhBgjn9D9eHFLq6/KqCIGs5hO3PI0vf4j0yJs6AzLb6SmRs3cOMpDHERodpLY7DvmkAzbVRKkuS99S5KyrW4EDV37JPKucTuJHwlXP6AvJyD1ecYvxtiUxwsObpA+r6HatpNNqOZTGWn/pB9nFk4oDv+ASeT4xmCGuEABi2VCS7RzFicgQ== 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 2024-01-30 22:13, Dan Williams wrote: > Dave Chinner wrote: >> On Tue, Jan 30, 2024 at 11:52:55AM -0500, Mathieu Desnoyers wrote: >>> 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 dcache. >>> >>> This is a regression introduced in the v5.13 Linux kernel where the >>> dax mount option is removed for 32-bit ARMv7 boards which have no dcache >>> aliasing, and therefore should work fine with FS_DAX. >>> >>> This was turned into the following implementation of dax_is_supported() >>> by a preparatory change: >>> >>> return !IS_ENABLED(CONFIG_ARM) && >>> !IS_ENABLED(CONFIG_MIPS) && >>> !IS_ENABLED(CONFIG_SPARC); >>> >>> Use dcache_is_aliasing() instead to figure out whether the environment >>> has aliasing dcaches. >>> >>> 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 >>> --- >>> include/linux/dax.h | 5 ++--- >>> 1 file changed, 2 insertions(+), 3 deletions(-) >>> >>> diff --git a/include/linux/dax.h b/include/linux/dax.h >>> index cfc8cd4a3eae..f59e604662e4 100644 >>> --- a/include/linux/dax.h >>> +++ b/include/linux/dax.h >>> @@ -5,6 +5,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> typedef unsigned long dax_entry_t; >>> >>> @@ -80,9 +81,7 @@ static inline bool daxdev_mapping_supported(struct vm_area_struct *vma, >>> } >>> static inline bool dax_is_supported(void) >>> { >>> - return !IS_ENABLED(CONFIG_ARM) && >>> - !IS_ENABLED(CONFIG_MIPS) && >>> - !IS_ENABLED(CONFIG_SPARC); >>> + return !dcache_is_aliasing(); >> >> Yeah, if this is just a one liner should go into >> fs_dax_get_by_bdev(), similar to the blk_queue_dax() check at the >> start of the function. >> >> I also noticed that device mapper uses fs_dax_get_by_bdev() to >> determine if it can support DAX, but this patch set does not address >> that case. Hence it really seems to me like fs_dax_get_by_bdev() is >> the right place to put this check. > > Oh, good catch. Yes, I agree this can definitely be pushed down, but > then I think it should be pushed down all the way to make alloc_dax() > fail. That will need some additional fixups like: > > diff --git a/drivers/md/dm.c b/drivers/md/dm.c > index 8dcabf84d866..a35e60e62440 100644 > --- a/drivers/md/dm.c > +++ b/drivers/md/dm.c > @@ -2126,12 +2126,12 @@ static struct mapped_device *alloc_dev(int minor) > md->dax_dev = alloc_dax(md, &dm_dax_ops); > if (IS_ERR(md->dax_dev)) { > md->dax_dev = NULL; > - goto bad; > + } else { > + set_dax_nocache(md->dax_dev); > + set_dax_nomc(md->dax_dev); > + if (dax_add_host(md->dax_dev, md->disk)) > + goto bad; > } > - set_dax_nocache(md->dax_dev); > - set_dax_nomc(md->dax_dev); > - if (dax_add_host(md->dax_dev, md->disk)) > - goto bad; > } > > format_dev_t(md->name, MKDEV(_major, minor)); > > ...to make it not fatal to fail to register the dax_dev. I've had a quick look at other users of alloc_dax() and alloc_dax_region(), and so far I figure that all of those really want to bail out on alloc_dax failure. Is dm.c the only special-case we need to fix to make it non-fatal ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com