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:   Tue, 27 Sep 2022 09:56:06 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Alistair Popple <apopple@nvidia.com>
Cc:     Dan Williams <dan.j.williams@intel.com>, 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 10/18] fsdax: Manage pgmap references at entry
 insertion and deletion
Message-ID: <YzLy5jJOF0jdlrJK@nvidia.com>
References: <632ba8eaa5aea_349629422@dwillia2-xfh.jf.intel.com.notmuch>
 <YyurdXnW7SyEndHV@nvidia.com>
 <632bc5c4363e9_349629486@dwillia2-xfh.jf.intel.com.notmuch>
 <YyyhrTxFJZlMGYY6@nvidia.com>
 <632cd9a2a023_3496294da@dwillia2-xfh.jf.intel.com.notmuch>
 <Yy2ziac3GdHrpxuh@nvidia.com>
 <632ddeffd86ff_33d629490@dwillia2-xfh.jf.intel.com.notmuch>
 <Yy3wA7/bkza7NO1J@nvidia.com>
 <632e031958740_33d629428@dwillia2-xfh.jf.intel.com.notmuch>
 <8735cdl4pk.fsf@nvdebian.thelocal>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8735cdl4pk.fsf@nvdebian.thelocal>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UJ/5fr4FtyCxmq3Y7AFkHwCD4l0oNOmksVkUq1Xd3UcftMVEZp1A+w+K8UZa?=
 =?us-ascii?Q?RQFPrYZlPR+DAOMSXWv6urGp6UkF8r2aSnKGbNNzC93F+pHZ3RzIDnFW6XLK?=
 =?us-ascii?Q?KrauThuN/eq0YI1z4WJnwucWszVdN5joI02Xv+92Zq0VARPw5J7FFjc5vCBa?=
 =?us-ascii?Q?uH18kjPy/nvSt61H+kR1DEdgXJwa6XDQPAusjy9J8/j5VYKbzdRPljVLyQlW?=
 =?us-ascii?Q?L1ByDMpknDcngdOvMgoinSf2FilbnP+p/6JhV2PgvYZTMsvev06fvpwnlsRI?=
 =?us-ascii?Q?3e/OAARWSGNGFU2VTifcIOEnOV0vq+1M7C0QrTn7e58/4zOcSdS6DOmY52n0?=
 =?us-ascii?Q?t/Sce0BkHCKhuGm3tpa06v5jtf7uUGI9pCZTIwESyjuyFnjxovcHlDQTpIeY?=
 =?us-ascii?Q?Dx+99bs2pQIxcPEUOnz9hEoo6Oj15zdRU/MfKfTaFjsqU0pLBvJJHwE4hjlw?=
 =?us-ascii?Q?klnFhbjiVQ/M3VYowm1600k1uT6TF7D6YHZfXRyxrHb2RXBWUi9PHCB5bLZw?=
 =?us-ascii?Q?sqC61YgunFmjteVjUE9gT1ZECvv6rGnKX7WdsuM0Lizubs8n5ohrv2WvyU7N?=
 =?us-ascii?Q?D+Px6IxyxoPVVxIHFYEOoUEmHVIgWGJLFJzhrGoIJmUpPGg6SCpmtepX0iNg?=
 =?us-ascii?Q?yNPB0lgaTND8YV/O0Naca89zk5z4H5I/RsjzOZcuibEX5U93WRo8Gwx884zO?=
 =?us-ascii?Q?g/9Uaowl59pposl/S2YDou4E0vgT+gzW0wFOBJ9UekiXWwSlLvMqXVFx3OBQ?=
 =?us-ascii?Q?5TKPtrjETa7oTKXycCp30Li8qk2FQcEXP9ItdojTmzYYrO8e4iObrwziJIpm?=
 =?us-ascii?Q?eLXLcdSYJmEe55cTUHJrpo+fMVHzdhZY6a+zPGhaSx8K0iW+d2d5H+6CIhvE?=
 =?us-ascii?Q?ntu89B2puvfdZAuOhGrahJW5C6mILZgMPCP6gVl+l2ewxE3uE7upj3Ba28c/?=
 =?us-ascii?Q?evrNhdVNaqj8PbpxQtG3uzN/zqAQzRkQWdahN8bEu1RBpu1soTLQ058tk0eP?=
 =?us-ascii?Q?FQhGymIbqbvW52H4R/Hp8BEGnWlHjSqcN1usnAYsTMsfuc276jhtWs4tcHTk?=
 =?us-ascii?Q?7DNhiTGJbswduQI6EVWDF/VdDP2hWbYOskyyTBX6R3chGeX0OSCN0wTHvHy4?=
 =?us-ascii?Q?fwNskmUku2lwHDjmb7V8zCoTCbOqysNOvArQJN8WKv9SXWqJynC+vV+4gcXq?=
 =?us-ascii?Q?YXlqSNKyDPjCn4JnKG6t5jImgI3FD5tL48IDU3XVztgRsT8f6w1JV6p/Jo3H?=
 =?us-ascii?Q?WPRD2GF9iWxMQjrDLDEXrzjg4TcsEf7Hsb75rZCXG6SVEp0LrBSgeo7L3aeE?=
 =?us-ascii?Q?nsZjq3EBY6qu+lDABQCUJu8r35ev3+qccxP3qwx8liH9UN6ec7HNjHtUj3Yn?=
 =?us-ascii?Q?bNHWIT3SfZdzFh7pgc48sx4up3iIOuqrv1KXV3Imm4a7S4a+C4b5cQPYK8uG?=
 =?us-ascii?Q?v7QIXX45r8tNbJMy4is7JutkMk67/xdcbY3r+5WhRgd1u+RgFEIXrGLdX7XK?=
 =?us-ascii?Q?AvqctkzqYif/K+rt3L1fxPtOBh6rgD4GOZZPbRNbGWDvMB/ws34xIU9KFHeA?=
 =?us-ascii?Q?2/Y/ucul2zDP+di99RM=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f150e07d-f81d-450f-a417-08daa087a527
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2022 12:56:07.9620
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: h9/pyBXAlUusqKhj98TYbqZ2hgg9N7QBpEAoIvYlwxb4onfOtMp1pas4jHQOUdRu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6644
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no 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

On Tue, Sep 27, 2022 at 04:07:05PM +1000, Alistair Popple wrote:

> That sounds good to me at least. I just noticed we introduced this exact
> bug for device private/coherent pages when making their refcounts zero
> based. Nothing currently takes pgmap->ref when a private/coherent page
> is mapped. Therefore memunmap_pages() will complete and pgmap destroyed
> while pgmap pages are still mapped.

To kind of summarize this thread

Either we should get the pgmap reference during the refcount = 1 flow,
and put it during page_free()

Or we should have the pgmap destroy sweep all the pages and wait for
them to become ref == 0

I don't think we should have pgmap references randomly strewn all over
the place. A positive refcount on the page alone must be enough to
prove that the struct page exists and the pgmap is not destroyed.

Every driver using pgmap needs something liek this, so I'd prefer it
be in the pgmap code..

Jason