Message-ID: <0d377467c50cf60a4d008d7986d4402eecb8c94a.camel@web.de>
Date: Fri, 16 Aug 2024 13:55:33 +0200
From: Bert Karwatzki <spasswolf@....de>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v5.1 00/19] Rebase v5 patchset to next-20240816

Am Freitag, dem 16.08.2024 um 12:33 +0100 schrieb Lorenzo Stoakes:
> On Fri, Aug 16, 2024 at 01:13:41PM GMT, Bert Karwatzki wrote:
> > 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
> >
>
> I appreciate the effort taken in rebasing, but this is quite confusing,
> it's like you've re-sent the series (with tags...) as if you were
> submitting it, which I'm sure isn't your intent.
>
> You've also cc'd Andrew as if it were a submission and everybody else on
> thread...
>
> It's probably worth marking the series to make it totally clear you're just
> doing this as a favour or for testing purposes (I know you at least changed
> the title of the series accordingly). At the very least RFC it...
>
> Also you should mark that this is based on -next, as mm work is based on
> mm-unstable (for this series, likely the same).
>
> Liam is working on a rebase/rework of the series in parallel also so we
> should definitely be careful to avoid any confusion here.
>
> (Oh and as a side note - please do not send email to my personal address,
> all kernel mail should go to my Oracle one please).
>
> To avoid any confusion:
>
> NAK this whole series in this form (+ wait for Liam's next version...)
>
> Nacked-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>

Yes, this done for testing purposes (linux-next had several NULL pointer errors
(unrelated to the patchset) and as these are resolved since next-20240814, I
wanted to try the patches again, which I last tried on linux-next-20240730).

I should have taken more care in marking this as unofficial testing. (and not CC
everyone)

> (Oh and as a side note - please do not send email to my personal address,
> all kernel mail should go to my Oracle one please).

Ok, I just copied it from the Cc of Che old patches (like the other addresses.)

Also patches 16 to 19 of the set are currently stuck as smtp.web.de currently
refuses to send them.

Bert Karwatzki

Powered by blists - more mailing lists