Re: [PATCH v2 00/44] VMA tree type safety and remove __vma_adjust()

[Liam Howlett <liam.howlett@oracle.com>]

* Mark Brown <broonie@kernel.org> [230110 17:52]:
> On Thu, Jan 05, 2023 at 07:15:44PM +0000, Liam Howlett wrote:
> 
> > This patch set does two things: 1. Clean up, including removal of
> > __vma_adjust() and 2. Extends the VMA iterator API to provide type
> > safety to the VMA operations using the maple tree, as requested by Linus
> > [1].
> 
> This series *appears* to be causing some fun issues in -next for the
> past couple of days or so.  The initial failures were seen by KernelCI
> on several platforms (I've mostly been trying various arm64 things, at
> least 32 bit ARM is also affected).  The intial symptom seen is that a
> go binary called skipgen that gets invoked as part of the testing
> silently faults, tweaking things so that we get as far as running the
> arm64 selftests results in much more useful output with various things
> failing with actual error messages such as:
> 
>   ./fake_sigreturn_bad_magic: error while loading shared libraries: cannot make segment writable for relocation: Cannot allocate memory
>   ./sve-test: error while loading shared libraries: cannot make segment writable for relocation: Cannot allocate memory
> 
> I'm fairly sure we're not actually running out of memory, there's no OOM
> killer activity, the amount of memory the system has appears to make no
> difference and just replacing the kernel with a mainline build runs as
> expected.


Thanks for the detailed analysis.  This series has been dropped from
mm-unstable and, I guess, out of linux-next by tomorrow.

I will retest my series against a larger number of platforms before
sending out the next revision.

> 
> You can see the full run that produced the above errors at:
> 
>    https://lava.sirena.org.uk/scheduler/job/88257
> 
> which also embeds links to all the binaries used, exact commands run and
> so on.  The failing binaries all appear to be execed from within a
> testsuite, though it's not *all* binaries execed from within tests (eg,
> vec-syscfg execs things and seems happy).
> 
> This has taken out a bunch of testsuites in KernelCI (and probably other
> CI systems using test-definitions, though I didn't check).
> 
> I tried to bisect this but otherwise haven't made any effort to look at
> the failure.  The bisect sadly got lost in this series since a lot of
> the series either fails to build with:
> 
> /home/broonie/git/bisect/mm/madvise.c: In function 'madvise_update_vma':
> /home/broonie/git/bisect/mm/madvise.c:165:25: error: implicit declaration of function '__split_vma'; did you mean 'split_vma'? [-Werror=implicit-function-declaration]
>   165 |                 error = __split_vma(mm, vma, start, 1);
>       |                         ^~~~~~~~~~~
>       |                         split_vma

Thanks.  This was reported to me before and I had a fix in mm-unstable.
I'll squash this into the series for v3.

> 
> or fails to boot with something along the lines of:
> 
> <6>[    6.054380] Freeing initrd memory: 86880K
> <1>[    6.087945] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078
> <1>[    6.088231] Mem abort info:
> <1>[    6.088340]   ESR = 0x0000000096000004
> <1>[    6.088504]   EC = 0x25: DABT (current EL), IL = 32 bits
> <1>[    6.088671]   SET = 0, FnV = 0
> <1>[    6.088802]   EA = 0, S1PTW = 0
> <1>[    6.088929]   FSC = 0x04: level 0 translation fault
> <1>[    6.089099] Data abort info:
> <1>[    6.089210]   ISV = 0, ISS = 0x00000004
> <1>[    6.089347]   CM = 0, WnR = 0
> <1>[    6.089486] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043e33000
> <1>[    6.089692] [0000000000000078] pgd=0000000000000000, p4d=0000000000000000
> <0>[    6.090566] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
> <4>[    6.090866] Modules linked in:
> <4>[    6.091167] CPU: 0 PID: 42 Comm: modprobe Not tainted 6.2.0-rc1-00190-g505c59767243 #13
> <4>[    6.091478] Hardware name: linux,dummy-virt (DT)
> <4>[    6.091784] pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> <4>[    6.092048] pc : mas_wr_walk+0x60/0x2d0
> <4>[    6.092622] lr : mas_wr_store_entry.isra.0+0x80/0x4a0
> <4>[    6.092798] sp : ffff80000821bb10
> <4>[    6.092926] x29: ffff80000821bb10 x28: ffff000003fa4480 x27: 0000000200100073
> <4>[    6.093206] x26: ffff000003fa41b0 x25: ffff000003fa43f0 x24: 0000000000000002
> <4>[    6.093445] x23: 0000000ffffae021 x22: 0000000000000000 x21: ffff000002a74440
> <4>[    6.093685] x20: ffff000003fa4480 x19: ffff80000821bc48 x18: 0000000000000000
> <4>[    6.093933] x17: 0000000000000000 x16: ffff000002b8da00 x15: ffff80000821bc48
> <4>[    6.094169] x14: 0000ffffae022fff x13: ffffffffffffffff x12: ffff000002b8da0c
> <4>[    6.094427] x11: ffff80000821bb68 x10: ffffd75265462458 x9 : ffff80000821bc48
> <4>[    6.094685] x8 : ffff80000821bbb8 x7 : ffff80000821bc48 x6 : ffffffffffffffff
> <4>[    6.094922] x5 : 000000000000000e x4 : 000000000000000e x3 : 0000000000000000
> <4>[    6.095167] x2 : 0000000000000008 x1 : 000000000000000f x0 : ffff80000821bb68
> <4>[    6.095499] Call trace:
> <4>[    6.095685]  mas_wr_walk+0x60/0x2d0
> <4>[    6.095936]  mas_store_prealloc+0x50/0xa0
> <4>[    6.096097]  mmap_region+0x520/0x784
> <4>[    6.096232]  do_mmap+0x3b0/0x52c
> <4>[    6.096347]  vm_mmap_pgoff+0xe4/0x10c
> <4>[    6.096480]  ksys_mmap_pgoff+0x4c/0x204
> <4>[    6.096621]  __arm64_sys_mmap+0x30/0x44
> <4>[    6.096754]  invoke_syscall+0x48/0x114
> <4>[    6.096900]  el0_svc_common.constprop.0+0x44/0xec
> <4>[    6.097052]  do_el0_svc+0x38/0xb0
> <4>[    6.097183]  el0_svc+0x2c/0x84
> <4>[    6.097287]  el0t_64_sync_handler+0xf4/0x120
> <4>[    6.097457]  el0t_64_sync+0x190/0x194
> <0>[    6.097835] Code: 39402021 51000425 92401ca4 12001ca5 (f8647844) 
> <4>[    6.098294] ---[ end trace 0000000000000000 ]---
> 
> (not always exactly the same backtrace, but the mas_wr_walk() was always
> there.)

Thanks.  This was also reported and a fix had landed in mm-unstable as
well.

> 
> The specific set of commits in next-20230110 where bisect got lost was:
> 
> 505c59767243 madvise: use vmi iterator for __split_vma() and vma_merge()
> 1cfdd2a44d6b mmap: pass through vmi iterator to __split_vma()
> 7d718fd9873c sched: convert to vma iterator
> 2f94851ec717 mmap: use vmi version of vma_merge()
> 7e2dd18353a3 task_mmu: convert to vma iterator
> 756841b468f5 mm/mremap: use vmi version of vma_merge()
> aaba4ba837fa mempolicy: convert to vma iterator
> 8193673ee5d8 coredump: convert to vma iterator
> d4f7ebf41a44 mm: switch vma_merge(), split_vma(), and __split_vma to vma iterator
> 4b02758dc3c5 mlock: convert mlock to vma iterator
> fd367dac089e include/linux/mm: declare different type of split_vma() for !CONFIG_MMU
> 3a72a0174748 mm/damon: stop using vma_mas_store() for maple tree store
> dd51a3ca1096 mm: change mprotect_fixup to vma iterator
> b9e4eabb8f40 mmap: convert __vma_adjust() to use vma iterator
> c6fc05242a09 userfaultfd: use vma iterator
> b9000fd4c5a6 mmap-convert-__vma_adjust-to-use-vma-iterator-fix
> bdfb333b0b2a ipc/shm: use the vma iterator for munmap calls
> 3128296746a1 mm: pass through vma iterator to __vma_adjust()
> 80c8eed1721e mm: add temporary vma iterator versions of vma_merge(), split_vma(), and __split_vma()
> 311129a7971c mmap: convert vma_expand() to use vma iterator
> 69e9b6c8a525 madvise: use split_vma() instead of __split_vma()
> 751f0a6713a9 mm: remove unnecessary write to vma iterator in __vma_adjust()
> a7f83eb601ef mmap: change do_mas_munmap and do_mas_aligned_munmap() to use vma iterator
> 39fd6622223e mm: pass vma iterator through to __vma_adjust()
> 

...

I appreciate you running through the bisect and bringing this to my
attention.

I will do a better job of emailing linux-next the fixes, which I
obviously overlooked.