From: Luis Henriques <luis.henriques@canonical.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Eric Piel <eric.piel@tremplin-utc.net>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@kernel.org>,
Peter Ziljstra <peterz@infradead.org>
Subject: Re: BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497
Date: Thu, 17 Apr 2014 21:47:28 +0100 [thread overview]
Message-ID: <8761m7lm3j.fsf@canonical.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1404160958440.9704@gentwo.org> (Christoph Lameter's message of "Wed, 16 Apr 2014 10:03:23 -0500 (CDT)")
Christoph Lameter <cl@linux.com> writes:
> On Tue, 15 Apr 2014, Andrew Morton wrote:
>
>> On Tue, 15 Apr 2014 00:55:50 +0100 Luis Henriques <luis.henriques@canonical.com> wrote:
>>
>> > (Cc'ing both lis3lv02d and ACPI maintainers)
>> >
>> > Since commit 188a81409ff7de1c5aae947a96356ddd8ff4aaa3 ("percpu: add
>> > preemption checks to __this_cpu ops") I've been seeing the following:
>> >
>> > [ 10.485588] hp_accel: hardware type HPB64xx found
>> > [ 10.485772] BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497
>> > [ 10.485777] caller is __this_cpu_preempt_check+0x13/0x20
>> > [ 10.485781] CPU: 3 PID: 497 Comm: systemd-udevd Tainted: G W 3.15.0-rc1 #9
>> > [ 10.485783] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012
>> > [ 10.485785] ffffffff81a14db5 ffff88022c80b8e0 ffffffff81604ba4 0000000000000003
>> > [ 10.485789] ffff88022c80b908 ffffffff81313431 0000000000000000 0000000000000032
>> > [ 10.485793] 00000000000003e8 ffff88022c80b918 ffffffff81313473 ffff88022c80b928
>> > [ 10.485796] Call Trace:
>> > [ 10.485802] [<ffffffff81604ba4>] dump_stack+0x4e/0x7a
>> > [ 10.485805] [<ffffffff81313431>] check_preemption_disabled+0xe1/0xf0
>> > [ 10.485808] [<ffffffff81313473>] __this_cpu_preempt_check+0x13/0x20
>> > [ 10.485813] [<ffffffff810e4eb8>] touch_nmi_watchdog+0x28/0x40
>>
>> Presumably touch_softlockup_watchdog() being called with preemption
>> enabled. Which is a legitimate thing to do and there's no point in
>> disabling preemption just to squish a runtime warning.
>>
>> Christoph, this thing has iirc caught a couple of very minor bugs but
>> it is being quite a pain in the rear. I'm inclined to revert?
>
> Well this preemption check functionality was strongly desired by Peter
> Zilkstra and Ingo Molnar and made a precondition for more extensive use of
> the this_cpu operations. My patches to various subsystems were rejected
> because these operations were deemed unsafe without those checks.
>
> The simple thing to do in these cases is to use switch from __this_cpu_*
> to raw_cpu ops to squish these warnings.
FWIW, I just gave the -mm tree patch
kernel-watchdogc-touch_softlockup_watchdog-use-raw_cpu_write.patch [1]
a try and it looks like it fixes this issue.
[1] http://ozlabs.org/~akpm/mmots/broken-out/kernel-watchdogc-touch_softlockup_watchdog-use-raw_cpu_write.patch
Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Luis Henriques <luis.henriques@canonical.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Eric Piel <eric.piel@tremplin-utc.net>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@kernel.org>,
Peter Ziljstra <peterz@infradead.org>
Subject: Re: BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497
Date: Thu, 17 Apr 2014 21:47:28 +0100 [thread overview]
Message-ID: <8761m7lm3j.fsf@canonical.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1404160958440.9704@gentwo.org> (Christoph Lameter's message of "Wed, 16 Apr 2014 10:03:23 -0500 (CDT)")
Christoph Lameter <cl@linux.com> writes:
> On Tue, 15 Apr 2014, Andrew Morton wrote:
>
>> On Tue, 15 Apr 2014 00:55:50 +0100 Luis Henriques <luis.henriques@canonical.com> wrote:
>>
>> > (Cc'ing both lis3lv02d and ACPI maintainers)
>> >
>> > Since commit 188a81409ff7de1c5aae947a96356ddd8ff4aaa3 ("percpu: add
>> > preemption checks to __this_cpu ops") I've been seeing the following:
>> >
>> > [ 10.485588] hp_accel: hardware type HPB64xx found
>> > [ 10.485772] BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497
>> > [ 10.485777] caller is __this_cpu_preempt_check+0x13/0x20
>> > [ 10.485781] CPU: 3 PID: 497 Comm: systemd-udevd Tainted: G W 3.15.0-rc1 #9
>> > [ 10.485783] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012
>> > [ 10.485785] ffffffff81a14db5 ffff88022c80b8e0 ffffffff81604ba4 0000000000000003
>> > [ 10.485789] ffff88022c80b908 ffffffff81313431 0000000000000000 0000000000000032
>> > [ 10.485793] 00000000000003e8 ffff88022c80b918 ffffffff81313473 ffff88022c80b928
>> > [ 10.485796] Call Trace:
>> > [ 10.485802] [<ffffffff81604ba4>] dump_stack+0x4e/0x7a
>> > [ 10.485805] [<ffffffff81313431>] check_preemption_disabled+0xe1/0xf0
>> > [ 10.485808] [<ffffffff81313473>] __this_cpu_preempt_check+0x13/0x20
>> > [ 10.485813] [<ffffffff810e4eb8>] touch_nmi_watchdog+0x28/0x40
>>
>> Presumably touch_softlockup_watchdog() being called with preemption
>> enabled. Which is a legitimate thing to do and there's no point in
>> disabling preemption just to squish a runtime warning.
>>
>> Christoph, this thing has iirc caught a couple of very minor bugs but
>> it is being quite a pain in the rear. I'm inclined to revert?
>
> Well this preemption check functionality was strongly desired by Peter
> Zilkstra and Ingo Molnar and made a precondition for more extensive use of
> the this_cpu operations. My patches to various subsystems were rejected
> because these operations were deemed unsafe without those checks.
>
> The simple thing to do in these cases is to use switch from __this_cpu_*
> to raw_cpu ops to squish these warnings.
FWIW, I just gave the -mm tree patch
kernel-watchdogc-touch_softlockup_watchdog-use-raw_cpu_write.patch [1]
a try and it looks like it fixes this issue.
[1] http://ozlabs.org/~akpm/mmots/broken-out/kernel-watchdogc-touch_softlockup_watchdog-use-raw_cpu_write.patch
Cheers,
--
Luís
next prev parent reply other threads:[~2014-04-17 20:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 23:55 BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497 Luis Henriques
2014-04-15 21:22 ` Éric Piel
2014-04-15 22:54 ` Andrew Morton
2014-04-16 15:03 ` Christoph Lameter
2014-04-17 20:47 ` Luis Henriques [this message]
2014-04-17 20:47 ` Luis Henriques
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=8761m7lm3j.fsf@canonical.com \
--to=luis.henriques@canonical.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=eric.piel@tremplin-utc.net \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.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.