[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240816111405.11793-1-spasswolf@web.de>
Date: Fri, 16 Aug 2024 13:13:41 +0200
From: Bert Karwatzki <spasswolf@....de>
To: "Liam R . Howlett" <Liam.Howlett@...cle.com>
Cc: Bert Karwatzki <spasswolf@....de>,
Suren Baghdasaryan <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Lorenzo Stoakes <lstoakes@...il.com>,
Matthew Wilcox <willy@...radead.org>,
sidhartha.kumar@...cle.com,
"Paul E . McKenney" <paulmck@...nel.org>,
Jiri Olsa <olsajiri@...il.com>,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <kees@...nel.org>,
Jeff Xu <jeffxu@...omium.org>
Subject: [PATCH v5.1 00/19] Rebase v5 patchset to next-20240816
Since the v5 patchset some changes have taken place in the linux-next tree
which make it impossible to cleanly apply that patchset. The most important
of these changes is the splitting of the mm/mmap.c into mm/mmap.c and mm/vma.c
and the splitting of mm/internal.h into mm/internal.h and mm/vma.h. Also
arch_unmap() has already been removed from mm/mmap.c in next-20240816 so
there's no need to take care of that.
When testing this with `stress-ng --vm-segv 1` dmesg show errors like
[ T3753] coredump: 3753(stress-ng-vm-se): over coredump resource limit, skipping core dump
[ T3753] coredump: 3753(stress-ng-vm-se): coredump has not been created, error -7
[ T3754] coredump: 3754(stress-ng-vm-se): over coredump resource limit, skipping core dump
[ T3754] coredump: 3754(stress-ng-vm-se): coredump has not been created, error -7
[...]
this is most likely not a problem of the patchset but instead caused by
a more verbose coredump introduced in the following patch:
https://lore.kernel.org/all/20240718182743.1959160-3-romank@linux.microsoft.com/
Changes since v4:
- rebase on next-20240816
- some functions which were static in the original v5 patchset
are now non-static as they're used in both mmap.c and vma.c
(an alternative approach to this would have been to leave
them as "static inline" and put them into vma.h (at least if
they're only used in mmap.c and vma.c))
Bert Karwatzki
Liam R. Howlett (19):
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: Support vma == NULL in init_vma_munmap()
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 can_modify_mm() check down the stack
ipc/shm, mm: Drop do_vma_munmap()
mm/mmap: Move may_expand_vm() check in mmap_region()
include/linux/mm.h | 6 +-
ipc/shm.c | 8 +-
mm/mmap.c | 146 ++++++++---------
mm/vma.c | 397 +++++++++++++++++++++++++++++++--------------
mm/vma.h | 61 ++++++-
5 files changed, 403 insertions(+), 215 deletions(-)
--
2.45.2
Powered by blists - more mailing lists