[RFC,0/2] mm: update mips to use do_mmap(), make mmap_region() internal

Message

Lorenzo Stoakes Dec. 12, 2024, 3:36 p.m. UTC

Currently the only user of mmap_region() outside of the memory management
code is the MIPS VDSO implementation.

This uses mmap_region() to map a 'delay slot emulation page' at the top of
the stack which is read-only and executable.

This mapping requires that an already-acquired mmap write lock is utilised
and that uffd and populate logic is ignored. This rules out vm_mmap(),
however do_mmap() fits the bill.

Adapt this code to use do_mmap() and then once done, make mmap_region()
internal and userland testable, and avoid any other uses of mmap_region(),
which is absolutely and strictly an internal mm function which bypasses a
great number of checks and logic.

REVIEWERS NOTES:

Thomas - I lack the hardware or set up to test this beyond a simple
cross-compilation test, so I need some input from you MIPS guys as to
whether this is workable.

I've therefore sent this as an RFC so we can be sure this is suitable!
Please could you check to make sure this change is OK and I haven't missed
anything?

Thanks!

Lorenzo Stoakes (2):
  mips: vdso: prefer do_mmap() to mmap_region()
  mm: make mmap_region() internal

 arch/mips/kernel/vdso.c          | 10 +++--
 include/linux/mm.h               |  3 --
 mm/mmap.c                        | 34 -----------------
 mm/vma.c                         | 36 +++++++++++++++++-
 mm/vma.h                         |  6 +--
 tools/testing/vma/vma_internal.h | 65 ++++++++++++++++++++++++++++++++
 6 files changed, 109 insertions(+), 45 deletions(-)

--
2.47.1

Comments

Thomas Bogendoerfer Dec. 17, 2024, 8:23 a.m. UTC | #1

On Thu, Dec 12, 2024 at 03:36:45PM +0000, Lorenzo Stoakes wrote:
> Currently the only user of mmap_region() outside of the memory management
> code is the MIPS VDSO implementation.
> 
> This uses mmap_region() to map a 'delay slot emulation page' at the top of
> the stack which is read-only and executable.
> 
> This mapping requires that an already-acquired mmap write lock is utilised
> and that uffd and populate logic is ignored. This rules out vm_mmap(),
> however do_mmap() fits the bill.
> 
> Adapt this code to use do_mmap() and then once done, make mmap_region()
> internal and userland testable, and avoid any other uses of mmap_region(),
> which is absolutely and strictly an internal mm function which bypasses a
> great number of checks and logic.
> 
> REVIEWERS NOTES:
> 
> Thomas - I lack the hardware or set up to test this beyond a simple
> cross-compilation test, so I need some input from you MIPS guys as to
> whether this is workable.
> 
> I've therefore sent this as an RFC so we can be sure this is suitable!
> Please could you check to make sure this change is OK and I haven't missed
> anything?

conversation looks correct, but this patch doesn't apply to upstream v6.13-rc1.
Which tree are you using ?

Thomas.

Liam R. Howlett Dec. 17, 2024, 2:11 p.m. UTC | #2

* Thomas Bogendoerfer <[e-mail]> [241217 03:25]:
> On Thu, Dec 12, 2024 at 03:36:45PM +0000, Lorenzo Stoakes wrote:
> > Currently the only user of mmap_region() outside of the memory management
> > code is the MIPS VDSO implementation.
> > 
> > This uses mmap_region() to map a 'delay slot emulation page' at the top of
> > the stack which is read-only and executable.
> > 
> > This mapping requires that an already-acquired mmap write lock is utilised
> > and that uffd and populate logic is ignored. This rules out vm_mmap(),
> > however do_mmap() fits the bill.
> > 
> > Adapt this code to use do_mmap() and then once done, make mmap_region()
> > internal and userland testable, and avoid any other uses of mmap_region(),
> > which is absolutely and strictly an internal mm function which bypasses a
> > great number of checks and logic.
> > 
> > REVIEWERS NOTES:
> > 
> > Thomas - I lack the hardware or set up to test this beyond a simple
> > cross-compilation test, so I need some input from you MIPS guys as to
> > whether this is workable.
> > 
> > I've therefore sent this as an RFC so we can be sure this is suitable!
> > Please could you check to make sure this change is OK and I haven't missed
> > anything?
> 
> conversation looks correct, but this patch doesn't apply to upstream v6.13-rc1.
> Which tree are you using ?

He's out right now, but generally he works on mm-unstable.  It doesn't
apply cleanly there either, so my guess is mm-unstable has been rebased.

We should do this, but there's no rush.

Thanks,
Liam