From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DE94C433B4 for ; Wed, 21 Apr 2021 17:56:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D4E1961427 for ; Wed, 21 Apr 2021 17:56:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245087AbhDUR4p (ORCPT ); Wed, 21 Apr 2021 13:56:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:35346 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235836AbhDUR4n (ORCPT ); Wed, 21 Apr 2021 13:56:43 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5DE48613D1; Wed, 21 Apr 2021 17:56:10 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lZH56-008kJ3-4I; Wed, 21 Apr 2021 18:56:08 +0100 Date: Wed, 21 Apr 2021 18:56:07 +0100 Message-ID: <87tunzsers.wl-maz@kernel.org> From: Marc Zyngier To: Sudeep Holla Cc: Lorenzo Pieralisi , Hanjun Guo , dann frazier , Fu Wei , Len Brown , "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 2/2] ACPI: irq: Prevent unregistering of GIC SGIs In-Reply-To: <20210421171516.hg3ex7jqigqjqa6i@bogus> References: <20210421164317.1718831-1-maz@kernel.org> <20210421164317.1718831-3-maz@kernel.org> <20210421171516.hg3ex7jqigqjqa6i@bogus> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: sudeep.holla@arm.com, lorenzo.pieralisi@arm.com, guohanjun@huawei.com, dann.frazier@canonical.com, wefu@redhat.com, lenb@kernel.org, rjw@rjwysocki.net, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Apr 2021 18:15:16 +0100, Sudeep Holla wrote: > > On Wed, Apr 21, 2021 at 05:43:17PM +0100, Marc Zyngier wrote: > > When using ACPI on arm64, which implies the GIC IRQ model, no > > table should ever provide a GSI number in the range [0:15], > > as these are reserved for IPIs. > > > > However, drivers tend to call acpi_unregister_gsi() with any > > random GSI number provided by half baked tables, which results > > in an exploding kernel when its IPIs have been unconfigured. > > > > In order to catch this, check for the silly case early, warn > > that something is going wrong and avoid the above disaster. > > > > Reviewed-by: Sudeep Holla > > Just curious if this is just precaution or do we have a platform doing > something stupid like this ? Without this, it could be really hard to pinpoint which driver messes with IPIs. Having this in place would have caught the GTDT bug much earlier (several years ago actually). The only reason I managed to track it down in a short amount of time is that the driver actually printed an error message before the kernel exploded while probing a completely unrelated driver. Without this message, I'd still be scratching my head. The WARN_ON() would definitely point at the guilty party, and keep the kernel running. Thanks, M. -- Without deviation from the norm, progress is not possible.