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 0F8F1E77188 for ; Wed, 8 Jan 2025 21:55:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A5226B0085; Wed, 8 Jan 2025 16:55:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 82E9B6B0088; Wed, 8 Jan 2025 16:55:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CE9B6B0089; Wed, 8 Jan 2025 16:55:21 -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 4E54F6B0085 for ; Wed, 8 Jan 2025 16:55:21 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 131371A1545 for ; Wed, 8 Jan 2025 21:55:21 +0000 (UTC) X-FDA: 82985641242.21.0C60F85 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 285C7100016 for ; Wed, 8 Jan 2025 21:55:18 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tKtR3JeM; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736373319; a=rsa-sha256; cv=none; b=Oo4Y5gCzWIyvN1OO7k+5YJMEHJJCgd0LhCBKo5mpGMptD818suwqFwUTk6jbRHhAjafPpL lFONyLGO08lCxb94B0n5XRAAPBvqD8JugtAknaL0/5C7x8df3CGUhH/lptWjibaFpxM6Sl RFGP5YnvfmsCAjkwbTXpkXZufdxU340= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tKtR3JeM; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736373319; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GZFfG+Oey+YrRCmnuLUDH49MTGtZAOROTvCOTJdkge4=; b=Nqra3bbb56WiW3/swLfbptZVM3wHLbg7rOB+iEWwxgibNSvpKjmwkK79XTEfqd5a6C39mN xaAWA6/VU/d4v5tFdkp15Hr2bEM1lXuEsUx04hY4N9GUHfiUKI8inDyAWOigLmzLRv2j/h Bujdq4vabWF7PlBWAiglVcH5bu6LaYI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GZFfG+Oey+YrRCmnuLUDH49MTGtZAOROTvCOTJdkge4=; b=tKtR3JeM6A1gmAWNtq4cuOMcjM Ymux5zQa7scoEka+qRFfaW9TtNncXNfaGb0/Dur+AnmApwhDpMulmiupz69vy885FpWVvr+kf12Mv QV/Y0jB8EFEU2D7DCawSyRYGvekSg24VJrNJRHJgv+w3rX6QJgYtWqnVlFJd+RZszj4XK67Pb4szY hDRHyLmHH59eOk/GiBit7gph6L0jZUOKh+8mYxOesouUB6VUeVFEGCowNisc7TcDQ0VJ//RZMrd59 8kniig18CBsDcV/cctYTRE2YKf1R8ZWHFHaqHPlJRVSveYFAMKJgyitdKWPg3F2Sf5cMXBXznmozy pm+98I7Q==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tVe1B-00000002xlB-08gm; Wed, 08 Jan 2025 21:55:13 +0000 Date: Wed, 8 Jan 2025 21:55:12 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Lorenzo Stoakes , Andrew Morton , Jaya Kumar , Simona Vetter , Helge Deller , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 3/3] fb_defio: do not use deprecated page->mapping, index fields Message-ID: References: <1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoakes@oracle.com> <34ad8349-c4c3-4370-a662-324fa91b32b1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34ad8349-c4c3-4370-a662-324fa91b32b1@redhat.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 285C7100016 X-Stat-Signature: ok7198z8qw4bf68n7r97q6z8jxdtic58 X-Rspam-User: X-HE-Tag: 1736373318-308525 X-HE-Meta: U2FsdGVkX1+Guwyqicywx2TrceVPU11YrWGa5ub0F7p65Zu+hq5lDWIra3hT+/DhGwS34JgxH+OgW9RA5mGJrag+2e3AZ4dUs22mhqeDyVu/NpiFYV9bElxBFBTyWQ2emQeVAoDHdg+Sq/VtMR7nMfoy0pYgdUKjGniNkd4uwefBTT5BcelPvl0nRSpRLDlT7GoPvwFJeDnB4wjAsmMcCiKNZsJAT6IrL1+TajR2IG9jM/wLK/fwds/CmmZ4l9g0c6XZaJyNiMPWu65wMDOh/OVqJ8gm01cWMwvGjIkIw5ahlWFvxpbXQgotm0tR8RhVw5T22tzL8/HhLvkVC6Sx7QQbv1xA3I6owzKQXkQVyxxuwtr6O/GrKzGCUg/jVN173r3FF0i1/FIhlJZKL7LGa6D5fAFmJfmtc0tLtgub0inkB6hYdrcbZ0i4i06R4SiInlnbVloJs3/m5SEL2bPKtQKoe1SCh4Vo5nlflZJ4hwpz8btLsGuSOPOLcp/otGhI+7Dm916tu3woOPtb0YhOYwN9CbcUR2X0T+cKFW7mzygXhS8ScGA+csdjozRwa90LJhIzqWSV2VJQd+Y7QH2ef90pjpnXbuh5/ixwuTjuFiKZyMwCeQyBdyquhpUk7nJUwMLnwGUb0gi917kyM1crMv149Z5G68IN/MWqWPcwdPbB4UbA0DXuPvHWrMdSU0RSJw97x+U9DN8fu/dI2yirfG5dCER5VT+aeXSjeGKxlnQjvi9fILJHCKrxN6tgOZLO8prK9I4bNXAzMcIrrfq9xpCNF2xXfBBWBxHByvHb46XQrlLhaNoeRa7esVfCpDSZ8aAHlFaRszEPsKZYSJ5MsS6IYJVceUst/GW15O56YFYFsQt73n8WrD7KUiUNQ9t6TMH1ldn52WX7ApjuCGIQjXHhX/E+8td8MB2BdLVaXAFHTJYUxPHJDv+eDcIRWkdxjIPsOVeB0RsMTRJijez ld69Qmf5 PcrqfxYmW0pRLMmPEYvUCKozCND2/Z3URXbupYrLEai2gWolitD2XLwaXX4Rn/l0d8NlbQrFCm5jJk3r+z+sJa5B9Rc4meZCnC22/7dqsaAA3xj5SSy4itKto0VGbv9h8568C6ccV7UDuE0PfzVnhMn+jucKp7/qfrT9F0WZDr1JB3gFXQnWHosEIFSgpqma/Aamqa8t8n78ZWym2sdXKGZmW/6B5CAcA5/fd7fcTNOTQEP6zElzB9FL3Fb67p/Rel3Tpw1c7g0M25LpbNUhiSSaGTQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000381, 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 Wed, Jan 08, 2025 at 10:12:36PM +0100, David Hildenbrand wrote: > On 08.01.25 21:54, Matthew Wilcox wrote: > > Not necessarily! We already do that (since 2022) for DAX (see > > 6a8e0596f004). rmap lets you find every place that a given range > > of a file is mapped into user address spaces; but that file might be a > > device file, and so it's not just pagecache but also (in this case) > > fb memory, and whatever else device drivers decide to mmap. > > Yes, that part I remember. > > I thought we would be passing in a page into rmap_wrprotect_file_page(), and > was wondering what we would do to "struct page" that won't be a folio in > there. > > Probably, because the "_page" in rmap_wrprotect_file_page() is misleading :) > > ... should it be "file_range" ? (but we also pass the pfn ... ) I don't think it's unprecedented for us to identify a page by its pfn. After all, the acronym stands for "page frame number". That said, for the one caller of this, it has the struct page and passes in the result from page_to_pfn(). So no harm in passing in the struct page directly. I would not like to see this function called "rmap_wrprotect_file_pfn". Files don't have pfns, so that's a bad name.