From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Josef Bacik <josef@toxicpanda.com>,
Michal Hocko <mhocko@suse.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Rik van Riel <riel@redhat.com>, Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Regression on ARMs in next-20170531
Date: Wed, 31 May 2017 11:00:20 -0700 [thread overview]
Message-ID: <20170531180009.GJ3730@atomide.com> (raw)
In-Reply-To: <20170531174333.GA27796@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [170531 10:47]:
> I don't have a similarly configured kernel, but here I have for the
> start of this function:
>
> 00000680 <__mod_node_page_state>:
> 680: e1a0c00d mov ip, sp
> 684: e92dd870 push {r4, r5, r6, fp, ip, lr, pc}
> 688: e24cb004 sub fp, ip, #4
> 68c: e590cc00 ldr ip, [r0, #3072] ; 0xc00
> 690: e1a0400d mov r4, sp
> 694: ee1d6f90 mrc 15, 0, r6, cr13, cr0, {4}
> 698: e08c5001 add r5, ip, r1
> 69c: e2855001 add r5, r5, #1
> 6a0: e1a03005 mov r3, r5
> 6a4: e196c0dc ldrsb ip, [r6, ip]
> 6a8: e19630d3 ldrsb r3, [r6, r3]
>
> r5 in your code is the equivalent of r6, r4 => r3, r3 -> r5.
> lr is the __per_cpu_offset array, so the first instruction is
> trying to load the percpu offset.
>
> The faulting code is:
>
> x = delta + __this_cpu_read(*p);
>
> specifically "__this_cpu_read(*p)".
>
> "ip" holds "pcp" from:
>
> struct per_cpu_nodestat __percpu *pcp = pgdat->per_cpu_nodestats;
>
> and you may notice that it's zero in the register dump. So,
> pgdat->per_cpu_nodestats is NULL here.
>
> This seems to be setup in setup_per_cpu_pageset(), which in the init
> order, happens way after mm_init() (which contains kmem_cache_init()).
OK thanks, so that should help :)
> So, looks to me like an init ordering bug. I'm not sure why SMP
> would be working - maybe its only working because it's managing to
> scribble over some memory that isn't faulting? I suspect a
> WARN_ON(!pcp) here will report even on SMP.
The other way around, CONFIG_SMP=y is not booting, disabling
it boots.
Regards,
Tony
next prev parent reply other threads:[~2017-05-31 18:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 16:45 Regression on ARMs in next-20170531 Tony Lindgren
2017-05-31 17:43 ` Russell King - ARM Linux
2017-05-31 18:00 ` Tony Lindgren [this message]
2017-06-04 11:32 ` Johannes Weiner
2017-06-06 5:55 ` Tony Lindgren
2017-06-06 12:30 ` Tony Lindgren
2017-06-06 14:36 ` Johannes Weiner
2017-06-06 15:03 ` Andrew Morton
2017-06-07 4:38 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170531180009.GJ3730@atomide.com \
--to=tony@atomide.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=josef@toxicpanda.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mhocko@suse.com \
--cc=riel@redhat.com \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.