Re: [PATCH 2/3] mm: provide mapping_wrprotect_page() function

Thomas Zimmermann
2025-02-04T08:16:14Z

Hi

Am 04.02.25 um 06:36 schrieb Christoph Hellwig:
> 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.

As the author of these commits, I have no doubt that the code would
break on some systems. It works in practice for the current use cases
though. Is it possible to create something that tracks framebuffer
writes without requiring pages?

Best regards
Thomas

>
>

--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)