Re: firefox on aarch64

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Tue, 4 Aug 2020 16:23:53 +0200
> From: Tobias Nygren <tnn%NetBSD.org@localhost>
> 
> On Tue, 4 Aug 2020 14:17:42 +0000
> maya%NetBSD.org@localhost wrote:
> 
> > On Tue, Aug 04, 2020 at 04:15:36PM +0200, Tobias Nygren wrote:
> > > On Sun, 2 Aug 2020 19:00:33 +0000
> > > maya%NetBSD.org@localhost wrote:
> > > 
> > > >    162      1 node     CALL  mmap(0x35140000,0x7f000,PROT_NONE,0x1042<PRIVATE,NORESERVE,ANONYMOUS,ALIGN=NONE>,0xffffffff,0,0)
> > > >    162      1 node     RET   mmap -1 errno 12 Cannot allocate memory
> > > >    162      1 node     CALL  mmap(0x35140000,0x7f000,PROT_NONE,0x1042<PRIVATE,NORESERVE,ANONYMOUS,ALIGN=NONE>,0xffffffff,0,0)
> > > >    162      1 node     RET   mmap -1 errno 12 Cannot allocate memory
> > > 
> > > There's no obvious reason why the kernel would ENOMEM for such a small
> > > allocation. It is interesting that it does two consecutive failing calls
> > > to mmap with the same hint address. Possibly race condition in the mmap
> > > syscall?
> > 
> > mlelstv provided this smaller test case.
> > Sorry, I ended up making it into a bug report and did not update the
> > thread.

https://gnats.NetBSD.org/55533

> > He says mmapping a mapped address fails on aarch64 but not amd64.
> 
> Ouch. That sounds like a kernel bug. Perhaps we can meanwhile patch
> nodejs to opportunistically do an munmap() on the range?

munmapping whatever random shared library happens to be in the way
sounds like a recipe for disaster!

Yes, it is almost certainly a kernel bug.  We should just find why the
kernel is returning ENOMEM here and fix it.  As a workaround for older
kernels, perhaps patch nodejs to pass zero as a hint always.