From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751507AbbJBURe (ORCPT ); Fri, 2 Oct 2015 16:17:34 -0400 Received: from www.linutronix.de ([62.245.132.108]:43266 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751039AbbJBURc (ORCPT ); Fri, 2 Oct 2015 16:17:32 -0400 Date: Fri, 2 Oct 2015 22:16:49 +0200 (CEST) From: Thomas Gleixner To: Mika Westerberg cc: Ingo Molnar , "H. Peter Anvin" , Jiang Liu , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] genirq: Introduce a new flag IRQ_IS_CHAINED for chained interrupts In-Reply-To: <1443769052-21151-1-git-send-email-mika.westerberg@linux.intel.com> Message-ID: References: <1443769052-21151-1-git-send-email-mika.westerberg@linux.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2 Oct 2015, Mika Westerberg wrote: > In some cases it is useful to know if the interrupt in question has chained > handler installed. For example when a cpu is offlined the architecture code > needs to know if it has any users so that it can fixup affinity > accordingly. > > To make this possible we introduce a new flag IRQ_IS_CHAINED that is set by > the core code when chained interrupt handler is installed. We also make it > possible for core and architecture code to check the flag by introducing > function irq_has_chained_handler() for this. While looking at that patch it occured to me, that we can solve this in a different way, which does not require any changes to the migration code. When we install the chained handler, we set the action of that irq descriptor to a statically allocated chained_action which provides a handler which emits a fat warning. chained handlers should never end up calling an action and if they do, it's clearly a bug. The availability of an action makes the migration code just pick it and move it along. And that fixes all architectures in one go without touching them. Sorry, that I didn't think about this right away. Thanks, tglx