Re: [PATCH v3 00/16] Avoid MAP_FIXED gap exposure

Re: [PATCH v3 00/16] Avoid MAP_FIXED gap exposure

[Bert Karwatzki]

I just did test the v3 patchset on top of linux-next-20240703 with
`stress-ng --vm-segv 16`. In about 5 minutes of testing no errors occured.
This seems to be a good sign especially since testing the v2 patchset yielded
more than a million errors in 30 seconds.

Bert Karwatzki

Re: [PATCH v3 00/16] Avoid MAP_FIXED gap exposure

[Liam R. Howlett]

* Bert Karwatzki <spasswolf@web.de> [240704 17:53]:
> I just did test the v3 patchset on top of linux-next-20240703 with
> `stress-ng --vm-segv 16`. In about 5 minutes of testing no errors occured.
> This seems to be a good sign especially since testing the v2 patchset yielded
> more than a million errors in 30 seconds.
> 

Thanks.  I am still concerned about the group task exit issue you saw in
v2 and how count could be out of sync with the mm struct map count.  I
wonder if it was this set or something else that was in linux-next at
the time of your testing.

Were you closing a window in firefox when that happened?  Maybe I can
attempt to recreate the issue again.

Regards,
Liam

Re: [PATCH v3 00/16] Avoid MAP_FIXED gap exposure

[Bert Karwatzki]

Am Freitag, dem 05.07.2024 um 11:06 -0400 schrieb Liam R. Howlett:
> * Bert Karwatzki <spasswolf@web.de> [240704 17:53]:
> > I just did test the v3 patchset on top of linux-next-20240703 with
> > `stress-ng --vm-segv 16`. In about 5 minutes of testing no errors occured.
> > This seems to be a good sign especially since testing the v2 patchset yielded
> > more than a million errors in 30 seconds.
> >
>
> Thanks.  I am still concerned about the group task exit issue you saw in
> v2 and how count could be out of sync with the mm struct map count.  I
> wonder if it was this set or something else that was in linux-next at
> the time of your testing.
>
> Were you closing a window in firefox when that happened?  Maybe I can
> attempt to recreate the issue again.
>
> Regards,
> Liam

I don't think I was closing a window when the issue happened, but right before
the freeze happened there was a segfault in a firefox process:

[ T8516] show_signal_msg: 16 callbacks suppressed
[ T8516] Isolated Web Co[8516]: segfault at 0 ip 00007f8c1f55fbe5 sp
00007ffcc2b97660 error 6 in libxul.so[4f98be5,7f8c1a686000+5f96000] likely on
CPU 14 (core 7, socket 0)
[ T8516] Code: 48 8d 0d 63 a3 3c 01 48 89 08 c7 04 25 00 00 00 00 00 00 00 00 0f
0b 48 8b 05 47 1a e2 03 48 8d 0d 38 99 30 01 48 89 08 31 c0 <89> 04 25 00 00 00
00 0f 0b e8 7d 7a 12 fb 66 2e 0f 1f 84 00 00 00
[ T8521] ------------[ cut here ]------------
[ T8521] kernel BUG at mm/mmap.c:3521!

so perhaps exit_group was called by a signal handler

Bert Karwatzki

[PATCH v3 00/16] Avoid MAP_FIXED gap exposure

[Liam R. Howlett]

It is now possible to walk the vma tree using the rcu read locks and is
beneficial to do so to reduce lock contention.  Doing so while a
MAP_FIXED mapping is executing means that a reader may see a gap in the
vma tree that should never logically exist - and does not when using the
mmap lock in read mode.  The temporal gap exists because mmap_region()
calls munmap() prior to installing the new mapping.

This patch set stops rcu readers from seeing the temporal gap by
splitting up the munmap() function into two parts.  The first part
prepares the vma tree for modifications by doing the necessary splits
and tracks the vmas marked for removal in a side tree.  The second part
completes the munmapping of the vmas after the vma tree has been
overwritten (either by a MAP_FIXED replacement vma or by a NULL in the
munmap() case).

Please note that rcu walkers will still be able to see a temporary state
of split vmas that may be in the process of being removed, but the
temporal gap will not be exposed.  vma_start_write() are called on both
parts of the split vma, so this state is detectable.

RFC: https://lore.kernel.org/linux-mm/20240531163217.1584450-1-Liam.Howlett@oracle.com/
v1: https://lore.kernel.org/linux-mm/20240611180200.711239-1-Liam.Howlett@oracle.com/
v2: https://lore.kernel.org/all/20240625191145.3382793-1-Liam.Howlett@oracle.com/

Changes since v2:
 - Introduced vms_complete_pte_clear() helper needed in case of modules
   mmaping over MAP_FIXED area.
 - Reduced arguments to unmap_region()
 - Fixed potential free_pgtables() range issue on first/last VMA.
   Tested with stress-ng --vm-sigv

Liam R. Howlett (16):
  mm/mmap: Correctly position vma_iterator in __split_vma()
  mm/mmap: Introduce abort_munmap_vmas()
  mm/mmap: Introduce vmi_complete_munmap_vmas()
  mm/mmap: Extract the gathering of vmas from do_vmi_align_munmap()
  mm/mmap: Introduce vma_munmap_struct for use in munmap operations
  mm/mmap: Change munmap to use vma_munmap_struct() for accounting and
    surrounding vmas
  mm/mmap: Extract validate_mm() from vma_complete()
  mm/mmap: Inline munmap operation in mmap_region()
  mm/mmap: Expand mmap_region() munmap call
  mm/mmap: Reposition vma iterator in mmap_region()
  mm/mmap: Track start and end of munmap in vma_munmap_struct
  mm/mmap: Clean up unmap_region() argument list
  mm/mmap: Avoid zeroing vma tree in mmap_region()
  mm/mmap: Use PHYS_PFN in mmap_region()
  mm/mmap: Use vms accounted pages in mmap_region()
  mm/mmap: Move may_expand_vm() check in mmap_region()

 mm/internal.h |  25 +++
 mm/mmap.c     | 479 +++++++++++++++++++++++++++++++-------------------
 2 files changed, 321 insertions(+), 183 deletions(-)

-- 
2.43.0