From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jaya Kumar <jayalk@intworks.biz>, 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>
Subject: [RFC PATCH 3/3] fb_defio: do not use deprecated page->mapping, index fields
Date: Wed, 8 Jan 2025 16:18:42 +0000 [thread overview]
Message-ID: <1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoakes@oracle.com> (raw)
In-Reply-To: <cover.1736352361.git.lorenzo.stoakes@oracle.com>
With the introduction of rmap_wrprotect_file_page() there is no need to use
folio_mkclean() in order to write-protect mappings of frame buffer pages,
and therefore no need to inappropriately set kernel-allocated page->index,
mapping fields to permit this operation.
Instead, store the pointer to the page cache object for the mapped driver
in the fb_deferred_io object, and use the already stored page offset from
the pageref object to look up mappings in order to write-protect them.
This is justified, as for the page objects to store a mapping pointer at
the point of assignment of pages, they must all reference the same
underlying address_space object. Since the life time of the pagerefs is
also the lifetime of the fb_deferred_io object, storing the pointer here
makes snese.
This eliminates the need for all of the logic around setting and
maintaining page->index,mapping which we remove.
This eliminates the use of folio_mkclean() entirely but otherwise should
have no functional change.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
drivers/video/fbdev/core/fb_defio.c | 34 ++++++++++-------------------
include/linux/fb.h | 1 +
2 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index 65363df8e81b..186ff902da5f 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -69,14 +69,6 @@ static struct fb_deferred_io_pageref *fb_deferred_io_pageref_lookup(struct fb_in
return pageref;
}
-static void fb_deferred_io_pageref_clear(struct fb_deferred_io_pageref *pageref)
-{
- struct page *page = pageref->page;
-
- if (page)
- page->mapping = NULL;
-}
-
static struct fb_deferred_io_pageref *fb_deferred_io_pageref_get(struct fb_info *info,
unsigned long offset,
struct page *page)
@@ -140,13 +132,10 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
if (!page)
return VM_FAULT_SIGBUS;
- if (vmf->vma->vm_file)
- page->mapping = vmf->vma->vm_file->f_mapping;
- else
+ if (!vmf->vma->vm_file)
printk(KERN_ERR "no mapping available\n");
- BUG_ON(!page->mapping);
- page->index = vmf->pgoff; /* for folio_mkclean() */
+ BUG_ON(!info->fbdefio->mapping);
vmf->page = page;
return 0;
@@ -194,9 +183,9 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
/*
* We want the page to remain locked from ->page_mkwrite until
- * the PTE is marked dirty to avoid folio_mkclean() being called
- * before the PTE is updated, which would leave the page ignored
- * by defio.
+ * the PTE is marked dirty to avoid rmap_wrprotect_file_page()
+ * being called before the PTE is updated, which would leave
+ * the page ignored by defio.
* Do this by locking the page here and informing the caller
* about it with VM_FAULT_LOCKED.
*/
@@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_struct *work)
struct folio *folio = page_folio(pageref->page);
folio_lock(folio);
- folio_mkclean(folio);
+ rmap_wrprotect_file_page(fbdefio->mapping,
+ pageref->offset >> PAGE_SHIFT,
+ compound_nr(pageref->page),
+ page_to_pfn(pageref->page));
folio_unlock(folio);
}
@@ -337,6 +329,7 @@ void fb_deferred_io_open(struct fb_info *info,
{
struct fb_deferred_io *fbdefio = info->fbdefio;
+ fbdefio->mapping = file->f_mapping;
file->f_mapping->a_ops = &fb_deferred_io_aops;
fbdefio->open_count++;
}
@@ -344,13 +337,7 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_open);
static void fb_deferred_io_lastclose(struct fb_info *info)
{
- unsigned long i;
-
flush_delayed_work(&info->deferred_work);
-
- /* clear out the mapping that we setup */
- for (i = 0; i < info->npagerefs; ++i)
- fb_deferred_io_pageref_clear(&info->pagerefs[i]);
}
void fb_deferred_io_release(struct fb_info *info)
@@ -370,5 +357,6 @@ void fb_deferred_io_cleanup(struct fb_info *info)
kvfree(info->pagerefs);
mutex_destroy(&fbdefio->lock);
+ fbdefio->mapping = NULL;
}
EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5ba187e08cf7..cd653862ab99 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -225,6 +225,7 @@ struct fb_deferred_io {
int open_count; /* number of opened files; protected by fb_info lock */
struct mutex lock; /* mutex that protects the pageref list */
struct list_head pagereflist; /* list of pagerefs for touched pages */
+ struct address_space *mapping; /* page cache object for fb device */
/* callback */
struct page *(*get_page)(struct fb_info *info, unsigned long offset);
void (*deferred_io)(struct fb_info *info, struct list_head *pagelist);
--
2.47.1
next prev parent reply other threads:[~2025-01-08 16:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 16:18 [RFC PATCH 0/3] expose mapping wrprotect, fix fb_defio use Lorenzo Stoakes
2025-01-08 16:18 ` [RFC PATCH 1/3] mm: refactor rmap_walk_file() to separate out traversal logic Lorenzo Stoakes
2025-01-08 16:38 ` Matthew Wilcox
2025-01-08 19:23 ` Lorenzo Stoakes
2025-01-08 16:18 ` [RFC PATCH 2/3] mm: provide rmap_wrprotect_file_page() function Lorenzo Stoakes
2025-01-08 17:25 ` Matthew Wilcox
2025-01-08 19:35 ` Lorenzo Stoakes
2025-01-08 16:18 ` Lorenzo Stoakes [this message]
2025-01-08 17:32 ` [RFC PATCH 3/3] fb_defio: do not use deprecated page->mapping, index fields Matthew Wilcox
2025-01-08 19:41 ` Lorenzo Stoakes
2025-01-13 23:01 ` Lorenzo Stoakes
2025-01-08 20:14 ` David Hildenbrand
2025-01-08 20:54 ` Matthew Wilcox
2025-01-08 21:12 ` David Hildenbrand
2025-01-08 21:55 ` Matthew Wilcox
2025-01-08 22:02 ` David Hildenbrand
2025-01-13 17:18 ` Lorenzo Stoakes
2025-01-13 17:48 ` Lorenzo Stoakes
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=1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.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=jayalk@intworks.biz \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=simona@ffwll.ch \
--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