From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Christopher Lameter <cl@linux.com>
Cc: Andre Wild <wild@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: BUG: using __this_cpu_read() in preemptible [00000000] code: mm_percpu_wq/7
Date: Wed, 12 Jul 2017 18:13:36 +0200 [thread overview]
Message-ID: <20170712161336.GA3190@osiris> (raw)
In-Reply-To: <alpine.DEB.2.20.1707121039180.15771@nuc-kabylake>
On Wed, Jul 12, 2017 at 10:44:54AM -0500, Christopher Lameter wrote:
> On Wed, 7 Jun 2017, Andre Wild wrote:
>
> > I'm currently seeing the following message running kernel version 4.11.0.
> > It looks like it was introduced with the patch
> > 4037d452202e34214e8a939fa5621b2b3bbb45b7.
>
> A 2007 patch? At that point we did not have __this_cpu_read() nor
> refresh_cpu_vmstats.... Is this on s390 or some such architecture?
It is on s390, but after I looked into the code a bit deeper the mentioned
patch doesn't seem to be the problem.
My initial thought was a missing preempt_disable() / preempt_enable() pair,
but that can't be the problem, since the code is executed on a per-cpu
workqueue.
> > Can you please take a look at this problem?
>
> Could you give me a bit more context?
>
>
> > [Tue Jun 6 15:27:03 2017] BUG: using __this_cpu_read() in preemptible
> > [00000000] code: mm_percpu_wq/7
> > [Tue Jun 6 15:27:03 2017] caller is refresh_cpu_vm_stats+0x198/0x3d8
> > [Tue Jun 6 15:27:03 2017] CPU: 0 PID: 7 Comm: mm_percpu_wq Tainted: G
> > W 4.11.0-20170529.0.ae409ab.224a322.fc25.s390xdefault #1
> > [Tue Jun 6 15:27:03 2017] Workqueue: mm_percpu_wq vmstat_update
>
> It is run in preemptible mode but this from a kworker
> context so the processor cannot change (see vmstat_refresh()).
>
> Even on s390 or so this should be fine.
Yes, it *should* be fine. The only unusual thing here is that this happens
during quite a lot of cpu hotplug operations. So even though the workqueue
code should be able to handle cpu hotplug correctly, my best guess is that
current->cpus_allowed is not cpumask_of(this_cpu) for some reason.
That would be this check within lib/smp_processor_id.c:check_preemption_disabled()
if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu)))
goto out;
I changed the code to simply panic, so I can look into a dump to figure out
what actually does cause the warning. As soon as Andre finds some time to
reproduce this we will come back to you.
next prev parent reply other threads:[~2017-07-12 16:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 9:05 BUG: using __this_cpu_read() in preemptible [00000000] code: mm_percpu_wq/7 Andre Wild
2017-07-12 15:44 ` Christopher Lameter
2017-07-12 16:13 ` Heiko Carstens [this message]
2017-08-16 9:13 ` Heiko Carstens
2017-08-16 14:20 ` Tejun Heo
2017-09-01 9:36 ` Andre Wild
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=20170712161336.GA3190@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wild@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox