Message-ID: <CABXOdTd-cqHM_feAO1tvwn4Z=kM6WHKYAbDJ7LGfMvRPRPG7GA@mail.gmail.com>
Date:   Tue, 16 Apr 2019 12:33:51 -0700
From:   Guenter Roeck <groeck@...gle.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Kees Cook <keescook@...omium.org>, kernelci@...ups.io,
        Guillaume Tucker <guillaume.tucker@...labora.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Mark Brown <broonie@...nel.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Matt Hart <matthew.hart@...aro.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Kevin Hilman <khilman@...libre.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Adrian Reber <adrian@...as.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Linux MM <linux-mm@...ck.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Richard Guy Briggs <rgb@...hat.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>, info@...nelci.org
Subject: Re: next/master boot bisection: next-20190215 on beaglebone-black

On Tue, Apr 16, 2019 at 11:54 AM Dan Williams <dan.j.williams@...el.com> wrote:
>
> On Thu, Apr 11, 2019 at 1:54 PM Guenter Roeck <groeck@...gle.com> wrote:
> [..]
> > > > Boot tests report
> > > >
> > > > Qemu test results:
> > > >     total: 345 pass: 345 fail: 0
> > > >
> > > > This is on top of next-20190410 with CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
> > > > and the known crashes fixed.
> > >
> > > In addition to CONFIG_SHUFFLE_PAGE_ALLOCATOR=y you also need the
> > > kernel command line option "page_alloc.shuffle=1"
> > >
> > > ...so I doubt you are running with shuffling enabled. Another way to
> > > double check is:
> > >
> > >    cat /sys/module/page_alloc/parameters/shuffle
> >
> > Yes, you are right. Because, with it enabled, I see:
> >
> > Kernel command line: rdinit=/sbin/init page_alloc.shuffle=1 panic=-1
> > console=ttyAMA0,115200 page_alloc.shuffle=1
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:303
> > page_alloc_shuffle+0x12c/0x1ac
> > static_key_enable(): static key 'page_alloc_shuffle_key+0x0/0x4' used
> > before call to jump_label_init()
>
> This looks to be specific to ARM never having had to deal with
> DEFINE_STATIC_KEY_TRUE in the past.
>

This affects almost all architectures, not just arm, presumably
because parse_args() is called before jump_label_init() in
start_kernel(). I did not bother to report back with further details
after someone stated that qemu doesn't support omap2, and the context
seemed to suggest that running any other tests would not add any
value.

> I am able to avoid this warning by simply not enabling JUMP_LABEL
> support in my build.
>

Fine with me, as long as CONFIG_SHUFFLE_PAGE_ALLOCATOR=y is not
enabled by default, or if it is made dependent on !JUMP_LABEL.

Guenter

> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper Not tainted
> > 5.1.0-rc4-next-20190410-00003-g3367c36ce744 #1
> > Hardware name: ARM Integrator/CP (Device Tree)
> > [<c0011c68>] (unwind_backtrace) from [<c000ec48>] (show_stack+0x10/0x18)
> > [<c000ec48>] (show_stack) from [<c07e9710>] (dump_stack+0x18/0x24)
> > [<c07e9710>] (dump_stack) from [<c001bb1c>] (__warn+0xe0/0x108)
> > [<c001bb1c>] (__warn) from [<c001bb88>] (warn_slowpath_fmt+0x44/0x6c)
> > [<c001bb88>] (warn_slowpath_fmt) from [<c0b0c4a8>]
> > (page_alloc_shuffle+0x12c/0x1ac)
> > [<c0b0c4a8>] (page_alloc_shuffle) from [<c0b0c550>] (shuffle_store+0x28/0x48)
> > [<c0b0c550>] (shuffle_store) from [<c003e6a0>] (parse_args+0x1f4/0x350)
> > [<c003e6a0>] (parse_args) from [<c0ac3c00>] (start_kernel+0x1c0/0x488)
> > [<c0ac3c00>] (start_kernel) from [<00000000>] (  (null))
> >
> > I'll re-run the test, but I suspect it will drown in warnings.
>
> I slogged through getting a Beagle Bone Black up and running with a
> Yocto build and it is not failing. I have tried apply the patches on
> top of v5.1-rc5 as well as re-testing next-20190215 label, no
> reproduction. The shuffle appears to avoid anything sensitive by
> default, below are the shuffle actions that were taken relative to
> iomem. Can someone with a failure reproduction please send me more
> details about their configuration? It would also help to get a failing
> boot log with the pr_debug() statements in mm/shuffle.c enabled to see
> if the failure is correlated with any unexpected shuffle actions.
>
> 80000000-9fffffff : System RAM
>   80008000-809fffff : Kernel code
>   80b00000-812be523 : Kernel data
>
> [    0.086469] __shuffle_zone: swap: 0x81800 -> 0x99800
> [    0.086558] __shuffle_zone: swap: 0x82000 -> 0x88800
> [    0.086575] __shuffle_zone: swap: 0x82800 -> 0x89800
> [    0.086591] __shuffle_zone: swap: 0x83000 -> 0x89000
> [    0.086606] __shuffle_zone: swap: 0x83800 -> 0x8a800
> [    0.086621] __shuffle_zone: swap: 0x84000 -> 0x93800
> [    0.086636] __shuffle_zone: swap: 0x84800 -> 0x83000
> [    0.086651] __shuffle_zone: swap: 0x85000 -> 0x8f000
> [    0.086666] __shuffle_zone: swap: 0x85800 -> 0x88000
> [    0.086689] __shuffle_zone: swap: 0x86000 -> 0x84000
> [    0.086704] __shuffle_zone: swap: 0x86800 -> 0x8c800
> [    0.086719] __shuffle_zone: swap: 0x87000 -> 0x93000
> [    0.086735] __shuffle_zone: swap: 0x87800 -> 0x94000
> [    0.086751] __shuffle_zone: swap: 0x88000 -> 0x90800
> [    0.086766] __shuffle_zone: swap: 0x88800 -> 0x9d000
> [    0.086781] __shuffle_zone: swap: 0x89000 -> 0x82800
> [    0.086796] __shuffle_zone: swap: 0x89800 -> 0x95800
> [    0.086811] __shuffle_zone: swap: 0x8a000 -> 0x98000
> [    0.086826] __shuffle_zone: swap: 0x8a800 -> 0x89000
> [    0.086842] __shuffle_zone: swap: 0x8b000 -> 0x81800
> [    0.086857] __shuffle_zone: swap: 0x8b800 -> 0x88800
> [    0.086872] __shuffle_zone: swap: 0x8c000 -> 0x8a000
> [    0.086891] __shuffle_zone: swap: 0x8c800 -> 0x84800
> [    0.086906] __shuffle_zone: swap: 0x8d000 -> 0x95000
> [    0.086921] __shuffle_zone: swap: 0x8d800 -> 0x8d000
> [    0.086935] __shuffle_zone: swap: 0x8e000 -> 0x8e800
> [    0.086950] __shuffle_zone: swap: 0x8e800 -> 0x99000
> [    0.086964] __shuffle_zone: swap: 0x8f000 -> 0x8d000
> [    0.086979] __shuffle_zone: swap: 0x90000 -> 0x91000
> [    0.086994] __shuffle_zone: swap: 0x90800 -> 0x83000
> [    0.087009] __shuffle_zone: swap: 0x91000 -> 0x91800
> [    0.087025] __shuffle_zone: swap: 0x91800 -> 0x8d800
> [    0.087040] __shuffle_zone: swap: 0x92000 -> 0x86800
> [    0.087054] __shuffle_zone: swap: 0x92800 -> 0x92000
> [    0.087070] __shuffle_zone: swap: 0x93000 -> 0x91000
> [    0.087088] __shuffle_zone: swap: 0x93800 -> 0x85000
> [    0.087103] __shuffle_zone: swap: 0x94000 -> 0x8b800
> [    0.087117] __shuffle_zone: swap: 0x94800 -> 0x96000
> [    0.087132] __shuffle_zone: swap: 0x95000 -> 0x91000
> [    0.087147] __shuffle_zone: swap: 0x95800 -> 0x8e000
> [    0.087161] __shuffle_zone: swap: 0x96000 -> 0x95800
> [    0.087179] __shuffle_zone: swap: 0x96800 -> 0x8c800
> [    0.087193] __shuffle_zone: swap: 0x97000 -> 0x89000
> [    0.087208] __shuffle_zone: swap: 0x97800 -> 0x85000
> [    0.087224] __shuffle_zone: swap: 0x98000 -> 0x85000
> [    0.087239] __shuffle_zone: swap: 0x98800 -> 0x93000
> [    0.087255] __shuffle_zone: swap: 0x99000 -> 0x94800
> [    0.087269] __shuffle_zone: swap: 0x99800 -> 0x94000

Powered by blists - more mailing lists