From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jaya Kumar <jayakumar.lkml@gmail.com>,
Simona Vetter <simona@ffwll.ch>, Helge Deller <deller@gmx.de>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Matthew Wilcox <willy@infradead.org>,
David Hildenbrand <david@redhat.com>,
Kajtar Zsolt <soci@c64.rulez.org>,
Maira Canal <mcanal@igalia.com>
Subject: [PATCH 0/3] expose mapping wrprotect, fix fb_defio use
Date: Fri, 31 Jan 2025 18:28:55 +0000 [thread overview]
Message-ID: <cover.1738347308.git.lorenzo.stoakes@oracle.com> (raw)
Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel pages are mapped read-only and
write-protect faults used to batch up I/O operations.
Each time the deferred work is done, folio_mkclean() is used to mark the
framebuffer page as having had I/O performed on it. However doing so
requires the kernel page (perhaps allocated via vmalloc()) to have its
page->mapping, index fields set so the rmap can find everything that maps
it in order to write-protect.
This is problematic as firstly, these fields should not be set for
kernel-allocated memory, and secondly these are not folios (it's not user
memory) and page->index, mapping fields are now deprecated and soon to be
removed.
The removal of these fields is imminent, rendering this series more urgent
than it might first appear.
The implementers cannot be blamed for having used this however, as there is
simply no other way of performing this operation correctly.
This series fixes this - we provide the mapping_wrprotect_page() function
to allow the reverse mapping to be used to look up mappings from the page
cache object (i.e. its address_space pointer) at a specific offset.
The fb_defio logic already stores this offset, and can simply be expanded
to keep track of the page cache object, so the change then becomes
straight-forward.
This series should have no functional change.
non-RFC:
* Kajtar kindly smoke-tested the defio side of this change and confirmed
that it appears to work correctly. I am therefore stripping the RFC and
putting forward as a non-RFC series.
RFC v2:
* Updated Jaya Kumar's email on cc - the MAINTAINERS section is apparently
incorrect.
* Corrected rmap_walk_file() comment to refer to folios as per Matthew.
* Reference folio->mapping rather than folio_mapping(folio) in
rmap_walk_file() as per Matthew.
* Reference folio->index rather than folio_pgoff(folio) in rmap_walk_file()
as per Matthew.
* Renamed rmap_wrprotect_file_page() to mapping_wrprotect_page() as per
Matthew.
* Fixed kerneldoc and moved to implementation as per Matthew.
* Updated mapping_wrprotect_page() to take a struct page pointer as per
David.
* Removed folio lock when invoking mapping_wrprotect_page() in
fb_deferred_io_work() as per Matthew.
* Removed compound_nr() in fb_deferred_io_work() as per Matthew.
RFC v1:
https://lore.kernel.org/all/1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoakes@oracle.com/
*** BLURB HERE ***
Lorenzo Stoakes (3):
mm: refactor rmap_walk_file() to separate out traversal logic
mm: provide mapping_wrprotect_page() function
fb_defio: do not use deprecated page->mapping, index fields
drivers/video/fbdev/core/fb_defio.c | 38 ++-----
include/linux/fb.h | 1 +
include/linux/rmap.h | 3 +
mm/rmap.c | 152 +++++++++++++++++++++++-----
4 files changed, 141 insertions(+), 53 deletions(-)
--
2.48.1
next reply other threads:[~2025-01-31 18:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 18:28 Lorenzo Stoakes [this message]
2025-01-31 18:28 ` [PATCH 1/3] mm: refactor rmap_walk_file() to separate out traversal logic Lorenzo Stoakes
2025-01-31 18:28 ` [PATCH 2/3] mm: provide mapping_wrprotect_page() function Lorenzo Stoakes
2025-02-03 15:49 ` Simona Vetter
2025-02-03 16:30 ` Lorenzo Stoakes
2025-02-04 10:19 ` Simona Vetter
2025-02-04 5:36 ` Christoph Hellwig
2025-02-04 8:16 ` Thomas Zimmermann
2025-01-31 18:28 ` [PATCH 3/3] fb_defio: do not use deprecated page->mapping, index fields Lorenzo Stoakes
2025-02-01 17:06 ` Lorenzo Stoakes
2025-02-04 8:21 ` Thomas Zimmermann
2025-02-04 8:37 ` Lorenzo Stoakes
2025-02-04 8:57 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1738347308.git.lorenzo.stoakes@oracle.com \
--to=lorenzo.stoakes@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=jayakumar.lkml@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcanal@igalia.com \
--cc=simona@ffwll.ch \
--cc=soci@c64.rulez.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).