Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751265AbaDQUrp (ORCPT ); Thu, 17 Apr 2014 16:47:45 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:33988 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751179AbaDQUrh convert rfc822-to-8bit (ORCPT ); Thu, 17 Apr 2014 16:47:37 -0400 From: Luis Henriques To: Christoph Lameter Cc: Andrew Morton , Eric Piel , Robert Moore , Lv Zheng , "Rafael J. Wysocki" , Len Brown , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Ziljstra Subject: Re: BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497 References: <87mwfn4gah.fsf@canonical.com> <20140415155453.54d0ca97ca88905594b5100f@linux-foundation.org> Date: Thu, 17 Apr 2014 21:47:28 +0100 In-Reply-To: (Christoph Lameter's message of "Wed, 16 Apr 2014 10:03:23 -0500 (CDT)") Message-ID: <8761m7lm3j.fsf@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter writes: > On Tue, 15 Apr 2014, Andrew Morton wrote: > >> On Tue, 15 Apr 2014 00:55:50 +0100 Luis Henriques 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] [] dump_stack+0x4e/0x7a >> > [ 10.485805] [] check_preemption_disabled+0xe1/0xf0 >> > [ 10.485808] [] __this_cpu_preempt_check+0x13/0x20 >> > [ 10.485813] [] 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/