Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 21 Sep 2022 08:48:22 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>,
        Dan Williams <dan.j.williams@intel.com>
CC:     <akpm@linux-foundation.org>, Matthew Wilcox <willy@infradead.org>,
        "Jan Kara" <jack@suse.cz>, "Darrick J. Wong" <djwong@kernel.org>,
        "Christoph Hellwig" <hch@lst.de>,
        John Hubbard <jhubbard@nvidia.com>,
        <linux-fsdevel@vger.kernel.org>, <nvdimm@lists.linux.dev>,
        <linux-xfs@vger.kernel.org>, <linux-mm@kvack.org>,
        <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v2 15/18] devdax: Use dax_insert_entry() +
 dax_delete_mapping_entry()
Message-ID: <632b3246548ff_66d1a29431@dwillia2-xfh.jf.intel.com.notmuch>
References: <166329930818.2786261.6086109734008025807.stgit@dwillia2-xfh.jf.intel.com>
 <166329939733.2786261.13946962468817639563.stgit@dwillia2-xfh.jf.intel.com>
 <YysbXPnA3Z6AzWCw@nvidia.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YysbXPnA3Z6AzWCw@nvidia.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?V/hOwmhHi3v4DuOgodnU7govA71BYACuyb7blXjEvZFejtV+3VdU2jTZ1DA9?=
 =?us-ascii?Q?+V74DXAvCuV/5I66zGvNkyqaO57EDUmEXB5UB2P8hmR5cfW250hPdZN0E3If?=
 =?us-ascii?Q?0LZQy903T0/4qLB8vgovDVtypgT4EcMIEEIGXAMRpZGnT9pfGMzvz/zneAgT?=
 =?us-ascii?Q?duRaO0CSKldb+LL1uKtUM0kvKsegQfCgXB2EIlpXFmJS/QVnx9flkvgqwgBS?=
 =?us-ascii?Q?YiHmNFME/XY9kBkRE5dCzlFXV/TFtM6G1iiRexg3dx5ga0u/ly4088RAT/7J?=
 =?us-ascii?Q?YKX5QgQmtObKqdFInSDa12BL6MHriPAf+j4BCm+jAiT5UMV+H9LEgBv7pvdF?=
 =?us-ascii?Q?ohfqYFF+NJk9T4EsdfgNBiFRodxxg/2ADOvDX1SIxTkFYdL/jeGWzvzkW6Ky?=
 =?us-ascii?Q?RdPgQVei0dGe4YcXILLUUk5I4ns92VZpVpV0oECqa4qQH5Im6qMHOtysd4V9?=
 =?us-ascii?Q?px3h/qSXBshdhbds0ao+sP3Ihhh4+9DxrCqtLZBRURlEfz0Ethi7P1F58myS?=
 =?us-ascii?Q?cnynIieJMoP5fNP5k5aebiIJbR6ksM2TDK7EubXzOq56SxyjaHAzzeB89Ggf?=
 =?us-ascii?Q?TIAFrTZKoJ1dyJNfrDFjo029qwygybNONYhE4UPdgok/uPy5yOJlRBFAlDrX?=
 =?us-ascii?Q?plx0Xu26InD6HLydaaS4YNcK9XhG9w00GEZxBB1mXW7z9W7o9rxmNIx+OhD6?=
 =?us-ascii?Q?lSaBSPrxSBRpIaYBGyuDpzqsUYncp2ojbgqN69gG/3HWBP7l/i//9GhZXdm5?=
 =?us-ascii?Q?hf8UpcGZskXDx0Mb7FbMTrkFzz4D6rL8n/1Md1FMeLYf96K9JLoUy+uNu4pT?=
 =?us-ascii?Q?qj8vLFi7tIn3TYuwQtUf2eeL5UHzBcfItOFndZPQqwL4flMxLrn8mOSj5skm?=
 =?us-ascii?Q?lGFsc7bxwAKYlU4wRwOAhBrP3TpA/bXm0hTw0sTem1Vki+ZHxvisbjB5/Uj+?=
 =?us-ascii?Q?sROhvSXWQ1nN+zAwRKammWuTa2kK97INMasi5uuUk6nX8vYLzaPFUb0ASSCN?=
 =?us-ascii?Q?qdQqTMk0VaHrFBWjUmTQwcpelA7qfiS9QxtddViIklA+Pw+6SzOhUmn+KQ4P?=
 =?us-ascii?Q?9k+4lBE2UJ1xMvhLFrLTDZMTKpHaD5tGEm47OQwQUZb2H3X7YfeUVIH7wWn9?=
 =?us-ascii?Q?aEp6SkAIyqhVtjK1mxq1CO9EBtHM0Y0665aovkNvTnGt/l+5KOWXorcPPz0Z?=
 =?us-ascii?Q?xoPvb9QY6dqpd8PwJpNjzPEKRwh+1Wy8qUwgFdbakVDH5y11AmbokjrfjnbG?=
 =?us-ascii?Q?KiT+w9EeEn8B54Dvpt6Wl/uBkfEMHdp5kO4uiiohXwyaAGj1KBfiReLq5gft?=
 =?us-ascii?Q?WmH2XSMvUpZHWx9XpRhHHER8ZVy+WJARdAWpD5XGtF/AU61pqpjtR+dW0n1n?=
 =?us-ascii?Q?Gf/jvZmhqFjOg1OFrF5Ow2r9L0vDpUWCTvjkbLUNVZc4NUX18a+LF549h27v?=
 =?us-ascii?Q?i5d+Z4KSYpO5k1LG1zNh5IZdNf0ulZtxfArB06wBXtUQhadXiS2wZFyjHr9K?=
 =?us-ascii?Q?T7frvfoMboh7/YYwhT9io4VM7MAgw8GVjM/QrmEioevsUoHGHR62TkOLTao6?=
 =?us-ascii?Q?4Jim4UCb9FPoFxYt9IhWGM9JQus3rO+BXBSvIe1+Lml5980aDWlUVBFBwAXb?=
 =?us-ascii?Q?6w=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 10bf5bf9-15c1-4348-ca1b-08da9be8b838
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2022 15:48:25.3356
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CdFO8xc9qHMv0wX4iD7Gp8Lm70qVgIKpz3bYwLjl+BdnYQJw2CxdaJ0ytTUyoDflEyJ6sSyySeB67UYyKi9iu2CLxZ6ZpeXYF/1DchsELXI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5956
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-ext4.vger.kernel.org>
X-Mailing-List: linux-ext4@vger.kernel.org

Jason Gunthorpe wrote:
> On Thu, Sep 15, 2022 at 08:36:37PM -0700, Dan Williams wrote:
> > Track entries and take pgmap references at mapping insertion time.
> > Revoke mappings (dax_zap_mappings()) and drop the associated pgmap
> > references at device destruction or inode eviction time. With this in
> > place, and the fsdax equivalent already in place, the gup code no longer
> > needs to consider PTE_DEVMAP as an indicator to get a pgmap reference
> > before taking a page reference.
> > 
> > In other words, GUP takes additional references on mapped pages. Until
> > now, DAX in all its forms was failing to take references at mapping
> > time. With that fixed there is no longer a requirement for gup to manage
> > @pgmap references. However, that cleanup is saved for a follow-on patch.
> 
> A page->pgmap must be valid and stable so long as a page has a
> positive refcount. Once we fixed the refcount GUP is automatically
> fine. So this explanation seems confusing.

I think while trying to describe the history I made this patch
description confusing.

> If dax code needs other changes to maintain that invarient it should
> be spelled out what those are and why, but the instant we fix the
> refcount we can delete the stuff in gup.c and everywhere else.

How about the following, note that this incorporates new changes I have
in flight after Dave pointed out the problem DAX has with page pins
versus inode lifetime:

---

The fsdax core now manages pgmap references when servicing faults that
install new mappings, and elevates the page reference until it is
zapped. It coordinates with the VFS to make sure that all page
references are dropped before the hosting inode goes out of scope
(iput_final()).

In order to delete the unnecessary pgmap reference taking in mm/gup.c
devdax needs to move to the same model.