Le 31/08/2023 à 16:41, Thomas Zimmermann a écrit :
Hi,
there's a per-architecture function called fb_pgprotect() that sets
VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
simple implementation based on pgprot_writecomine() [1] or
pgprot_noncached(). [2]
On PPC this function uses phys_mem_access_prot() and therefore requires
the mmap call's file struct. [3] Removing the file argument would help
with simplifying the caller of fb_pgprotect(). [4]
Why is the file even required on PPC?
Is it possible to replace phys_mem_access_prot() with something simpler
that does not use the file struct?
Le 31/08/2023 à 16:41, Thomas Zimmermann a écrit :
quoted
Hi,
there's a per-architecture function called fb_pgprotect() that sets
VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
simple implementation based on pgprot_writecomine() [1] or
pgprot_noncached(). [2]
On PPC this function uses phys_mem_access_prot() and therefore
requires the mmap call's file struct. [3] Removing the file argument
would help with simplifying the caller of fb_pgprotect(). [4]
Why is the file even required on PPC?
Is it possible to replace phys_mem_access_prot() with something
simpler that does not use the file struct?
On Thu, Aug 31, 2023, at 10:41, Thomas Zimmermann wrote:
Hi,
there's a per-architecture function called fb_pgprotect() that sets
VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
simple implementation based on pgprot_writecomine() [1] or
pgprot_noncached(). [2]
On PPC this function uses phys_mem_access_prot() and therefore requires
the mmap call's file struct. [3] Removing the file argument would help
with simplifying the caller of fb_pgprotect(). [4]
Why is the file even required on PPC?
Is it possible to replace phys_mem_access_prot() with something simpler
that does not use the file struct?
What what I can tell, the structure of the code is a result of
these constraints:
- some powerpc platforms use different page table flags for
prefetchable vs nonprefetchable BARs on PCI memory.
- page table flags must match between all mappings, in particular
here between /dev/fb0 and /dev/mem, as mismatched attributes
cause a checkstop. On other architectures this may cause
undefined behavior instead of a checkstop
It's unfortunate that we have multiple incompatible ways
to determine the page flags based on firmware (ia64),
pci (powerpc) or file->f_flags (arm, csky), when they all
try to solve the same problem here.
Christophe's suggested approach to simplify it is probably
fine, another way would be to pass the f_flags value instead
of the file pointer.
Arnd
From: Thomas Zimmermann <hidden> Date: 2023-09-04 07:24:55
Hi
Am 31.08.23 um 19:38 schrieb Christophe Leroy:
Le 31/08/2023 à 16:41, Thomas Zimmermann a écrit :
quoted
Hi,
there's a per-architecture function called fb_pgprotect() that sets
VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
simple implementation based on pgprot_writecomine() [1] or
pgprot_noncached(). [2]
On PPC this function uses phys_mem_access_prot() and therefore requires
the mmap call's file struct. [3] Removing the file argument would help
with simplifying the caller of fb_pgprotect(). [4]
Why is the file even required on PPC?
Is it possible to replace phys_mem_access_prot() with something simpler
that does not use the file struct?
Right, I've seen these various implementations. Luckily, the ARM
framebuffers use a plain pgprot_writecombine() without any references on
to file.
So, the simplest is maybe the following, allthough that's probably worth
a comment:
Could we drop the file argument from PPC's internal functions and
provide this interface to fb_pgprotect()? phys_mem_access_prot() would
be a trivial wrapper around that internal API. I'd provide a patch to do
that.
Best regards
Thomas