Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1759556AbcLAOzl (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Dec 2016 09:55:41 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:57550 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1758191AbcLAOzg (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Dec 2016 09:55:36 -0500
Date: Thu, 1 Dec 2016 15:52:48 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Aaron Sierra <asierra@xes-inc.com>
cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] acpi/rt: convert acpi_gbl_gpe_lock to raw spinlock
In-Reply-To: <390489414.497553.1480534166735.JavaMail.zimbra@xes-inc.com>
Message-ID: <alpine.DEB.2.20.1612011458590.3453@nanos>
References: <390489414.497553.1480534166735.JavaMail.zimbra@xes-inc.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2075
Lines: 46

On Wed, 30 Nov 2016, Aaron Sierra wrote:
> When testing GPE interrupts with CONFIG_PREEMPT_RT_FULL enabled, a
> verbose WARN_ONCE message would print to the kernel log. It turned out
> that the GPE interrupt handler was being called with local interrupts
> enabled because acpi_gbl_gpe_lock was implemented as a spinlock_t. Full
> preemption strips local interrupt disabling from spinlock_t operations,
> but not for raw_spinlock_t operations.
> 
> This is the warning that was triggered:
> 
> ------------[ cut here ]------------
> WARNING: CPU: 8 PID: 483 at kernel/irq/handle.c:149 __handle_irq_event_percpu+0x6f/0xcf
> irq 33 handler irq_default_primary_handler+0x0/0xb enabled interrupts
> Modules linked in: gpio_irq_demo(O)
> CPU: 8 PID: 483 Comm: irq/9-acpi Tainted: G           O    4.8.6-rt5-00012-geaa3b7c #6
> Hardware name: Extreme Engineering Solutions, Inc. XCalibur4643/XCalibur4643, BIOS 1-1.1.12.3_Alpha 04/29/2016
>  0000000000000000 ffff880858f3bc10 ffffffff81219a93 ffff880858f3bc60
>  0000000000000000 ffff880858f3bc50 ffffffff8104b84a 0000009500000000
>  ffff880855b76880 0000000000000021 0000000000000002 ffff880856356800
> Call Trace:
>  [<ffffffff81219a93>] dump_stack+0x4d/0x63
>  [<ffffffff8104b84a>] __warn+0xc0/0xdb
>  [<ffffffff8104b8af>] warn_slowpath_fmt+0x4a/0x4c
>  [<ffffffff810f7192>] ? path_openat+0xbf8/0xc62
>  [<ffffffff8107d7c3>] ? handle_irq_event+0x75/0x75
>  [<ffffffff8107d68d>] __handle_irq_event_percpu+0x6f/0xcf
>  [<ffffffff8107d727>] handle_irq_event_percpu+0x3a/0x61
>  [<ffffffff8107d7a3>] handle_irq_event+0x55/0x75
>  [<ffffffff8107ff76>] handle_simple_irq+0x5c/0x92
>  [<ffffffff81243a53>] gpe_irq_handler+0x2a/0x31

gpe_irq_handler is not in tree, so I really cannot tell what this is
about. It looks like it does interrupt demultiplexing, which triggers the
warning.

We tried to make that lock raw years ago and this results in a different
splat: https://marc.info/?l=linux-kernel&m=132468512523207&w=2

So no, we are not making that lock raw again blindly just because of random
out of tree code.

Thanks,

	tglx