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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1671CC2BD09 for ; Mon, 1 Jul 2024 04:25:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=q8FaXxeW49XxQjIVoOOnJuKPW6Isofg2ljkc7tdAOtU=; b=jBC9fwJ2hAKUu3byheS2ibsycb whZdIUYPmnOYSaNa+yQEFy6E9nzBRA4qltIZTj92KP+1+ay2iwIJ5/8XdYGGuLdQzxCYc7SUY96Eb zSHlSzkSTNaT6KZlGO17z10iJaLqn6IRq9FELU0YNy4uuqlqZGp3Yvel2wWXcHOUnETGE6nNqV6Wb F9f89iReoZC9BjiAa3PVVoI7iIlzyLQ0Cw5lcgjGDBKNhYSmFusfVg2bmQsubGR4yRKmpWKRBKitW /rni+Hzyw1sQaC6eZ+cbaMXqY2Fr1pzifBEfgTxPX1lTBACUSK6zuthaNL57Ki0aYyQ2tPGkHyM18 2+dOpVDA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sO8ay-00000001do6-42eX; Mon, 01 Jul 2024 04:24:52 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sO8an-00000001dkd-2E8K for linux-arm-kernel@lists.infradead.org; Mon, 01 Jul 2024 04:24:43 +0000 Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1fab03d2f23so16706255ad.0 for ; Sun, 30 Jun 2024 21:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1719807880; x=1720412680; darn=lists.infradead.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=q8FaXxeW49XxQjIVoOOnJuKPW6Isofg2ljkc7tdAOtU=; b=o24pIdiQK71LEu8XF3k5OkZjhjXPEePnSwHttoBqXH9JkQw68BycHsOfFh75U3S5FE /o//oxZnRHwoovkyB4oyBB7bxY1z/QzFKClNC1by812ce3LpMqUrmjmwnL7lPgwM3Q9s xdVuWgzjpwnimbU2OEyuulXE3njFyj1kmZn4tTBJGKQdhKuqMswHJDy0V5o3Zv9RaxeJ yRSZB7K8Ez7RGn0d6phrfJaDfv56eK4gkqyCZN1xpyKLNdHEbjBb5EGahiIGxMT5Pm9S IIreh1Lf3Xcv414K/W46Lnae0kAfmrHh6eA5LR4A6EUfinCaKVIfHEOwn8CxpDk7MUCW WicQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719807880; x=1720412680; 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=q8FaXxeW49XxQjIVoOOnJuKPW6Isofg2ljkc7tdAOtU=; b=jVjXiQ3cuHQewWWLk5Zv6RcN5LomgaTyv9iSKgwcdmJ5WS2bXkUWH2P9AT2Sqiv+3T oLtXtK0budq6rnR5IRyCicnNVdj0KwPHF1vc+dUj45TfnYhZS3SP9LZecviJKDmRxKfw XAmnycamLTXdzbmriQpGEf1qz27IChEs2MLeHUSIUxaYGodcPWKntg9WP12lgkRkJTDC 894uHE8WTmhj02nYBHVFC7HA50z/FR2DL/I6ahapl18TyjWLqAz7PKsXEMJlCXYqgQ1w yv02sKT7vRrAiNQNgb3xOwlkY1opsJwCn+lL8XkpIR3CijlM5KGQ7mi0gFV+Dz3Ioz7O 1RiA== X-Forwarded-Encrypted: i=1; AJvYcCXAK3upSaaEBY2uw7rzdBkA/ktz1Qifg3qA5NCGM4itK9XR2ccJAzntxCC35R315o8WCjXaWGlfhFxJ17a7VM0oM5eSVz0pBKniGMh9tRv2PAbjq7g= X-Gm-Message-State: AOJu0YyPBj61tcj0XRCEiWLxGob4KM882pErOFm3h2PLPzTFZcZXyeO7 wAzR2+yXoQdwFk1Ru6kC8UMTJUnGN+ZOtDM7n1urypm/HKHGj8RJbBfW+TyrC2E= X-Google-Smtp-Source: AGHT+IFKQ7mlIRHK3qLypxLI+wB6C/xuRboouR5zOv5/KrFwuLBxwDWk/1+R28Hzvt5tq0xC0UW+Zw== X-Received: by 2002:a17:902:d2cc:b0:1fa:2d0:f85b with SMTP id d9443c01a7336-1fadbce9d59mr26040185ad.49.1719807879574; Sun, 30 Jun 2024 21:24:39 -0700 (PDT) Received: from dread.disaster.area (pa49-179-32-121.pa.nsw.optusnet.com.au. [49.179.32.121]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fac1569051sm53926215ad.215.2024.06.30.21.24.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jun 2024 21:24:39 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1sO8ai-00HWNB-2Q; Mon, 01 Jul 2024 14:24:36 +1000 Date: Mon, 1 Jul 2024 14:24:36 +1000 From: Dave Chinner To: Alistair Popple Cc: dan.j.williams@intel.com, vishal.l.verma@intel.com, dave.jiang@intel.com, logang@deltatee.com, bhelgaas@google.com, jack@suse.cz, jgg@ziepe.ca, catalin.marinas@arm.com, will@kernel.org, mpe@ellerman.id.au, npiggin@gmail.com, dave.hansen@linux.intel.com, ira.weiny@intel.com, willy@infradead.org, djwong@kernel.org, tytso@mit.edu, linmiaohe@huawei.com, david@redhat.com, peterx@redhat.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, jhubbard@nvidia.com, hch@lst.de Subject: Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240630_212441_696777_8F1276E0 X-CRM114-Status: GOOD ( 19.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 27, 2024 at 10:54:15AM +1000, Alistair Popple wrote: > FS DAX pages have always maintained their own page reference counts > without following the normal rules for page reference counting. In > particular pages are considered free when the refcount hits one rather > than zero and refcounts are not added when mapping the page. > > Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary > mechanism for allowing GUP to hold references on the page (see > get_dev_pagemap). However there doesn't seem to be any reason why FS > DAX pages need their own reference counting scheme. > > By treating the refcounts on these pages the same way as normal pages > we can remove a lot of special checks. In particular pXd_trans_huge() > becomes the same as pXd_leaf(), although I haven't made that change > here. It also frees up a valuable SW define PTE bit on architectures > that have devmap PTE bits defined. > > It also almost certainly allows further clean-up of the devmap managed > functions, but I have left that as a future improvment. > > This is an update to the original RFC rebased onto v6.10-rc5. Unlike > the original RFC it passes the same number of ndctl test suite > (https://github.com/pmem/ndctl) tests as my current development > environment does without these patches. I strongly suggest running fstests on pmem devices with '-o dax=always' mount options to get much more comprehensive fsdax test coverage. That exercises a lot of the weird mmap corner cases that cause problems so it would be good to actually test that nothing new got broken in FSDAX by this patchset. -Dave. -- Dave Chinner david@fromorbit.com