From: Christoph Hellwig <hch@infradead.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
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>,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH 2/3] mm: provide mapping_wrprotect_page() function
Date: Mon, 3 Feb 2025 21:36:42 -0800 [thread overview]
Message-ID: <Z6Gnat93skcoFZqn@infradead.org> (raw)
In-Reply-To: <Z6DljlvHpjdFof42@phenom.ffwll.local>
Hi Simona,
On Mon, Feb 03, 2025 at 04:49:34PM +0100, Simona Vetter wrote:
>
> Could we go one step further and entirely drop the struct page? Similar to
> unmap_mapping_range for VM_SPECIAL mappings, except it only updates the
> write protection. The reason is that ideally we'd like fbdev defio to
> entirely get rid of any struct page usage, because with some dma_alloc()
> memory regions there's simply no struct page for them (it's a carveout).
Umm, for dma_alloc* where * is not _pages you never can get a page or
PFN form them. They are block boxes and drivers must not attempt to
translated them into either a page or PFN or things will go wrong.
Only the kernel virtual address and dma_address may be used.
> See e.g. Sa498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if
> necessary") for some of the pain this has caused.
The commit hash is corrupted, I guess this is 5a498d4d06d6 as the
subject line matches. And that commit (just like the code it is trying
to fix) is completely broken as it violates the above.
next prev parent reply other threads:[~2025-02-04 5:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 18:28 [PATCH 0/3] expose mapping wrprotect, fix fb_defio use Lorenzo Stoakes
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 [this message]
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=Z6Gnat93skcoFZqn@infradead.org \
--to=hch@infradead.org \
--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=lorenzo.stoakes@oracle.com \
--cc=mcanal@igalia.com \
--cc=simona@ffwll.ch \
--cc=soci@c64.rulez.org \
--cc=tzimmermann@suse.de \
--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