Arm + KASAN + syzbot

[Dmitry Vyukov]

On Thu, Mar 11, 2021 at 3:55 PM Arnd Bergmann <arnd at arndb.de> wrote:
> On Thu, Mar 11, 2021 at 3:09 PM Russell King - ARM Linux admin
> <linux at armlinux.org.uk> wrote:
> > On Thu, Mar 11, 2021 at 02:55:54PM +0100, Linus Walleij wrote:
> > > On Thu, Mar 11, 2021 at 11:54 AM Dmitry Vyukov <dvyukov at google.com> wrote:
> > > > The instance has KASAN disabled because Go binaries don't run on KASAN kernel:
> > > > https://lore.kernel.org/linux-arm-kernel/CACT4Y+YdJoNTqnBSELcEbcbVsKBtJfYUc7_GSXbUQfAJN3JyRg@mail.gmail.com/
> > >
> > > I am still puzzled by this, but I still have the open question about how much
> > > memory the Go runtime really use. I am suspecting quite a lot, and the
> > > ARM32 instance isn't on par with any contemporary server or desktop
> > > when it comes to memory, it has ~2GB for a userspace program, after
> > > that bad things will happen: the machine will start thrashing.
> >
> > I believe grafana is a Go binary - I run this in a VM with only 1G
> > of memory and no swap along with apache. It's happy enough.
> >
> > USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> > grafana   1122  0.0  5.9 920344 60484 ?        Ssl  Feb18  28:31 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini ...
> >
> > So, I suspect it's basically KASAN upsetting Go somehow that then
> > causes the memory usage to spiral out of control.
>
> I found a bug report about someone complaining that Go reserves a lot of
> virtual address space, and that this breaks an application that works
> with VMSPLIT_3G
> when changing to VMSPLIT_2G
>
> https://github.com/golang/go/issues/35677
>
> If KASAN limits the address space available to user space, there might be
> a related issue, even when there is still physical memory available.

Issue with virtual/physical memory is my current hypothesis as well
(though, not much grounded). The Go binary is also quite beefy (in
terms of code and memory consumption, but works fine w/o KASAN).
We have a long term plan to move all Go binaries out of the target,
but there is no ETA, more like a wish.