From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752666AbdFTV2p (ORCPT ); Tue, 20 Jun 2017 17:28:45 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:46244 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751090AbdFTV2o (ORCPT ); Tue, 20 Jun 2017 17:28:44 -0400 Date: Tue, 20 Jun 2017 23:28:39 +0200 (CEST) From: Thomas Gleixner To: Keith Busch cc: LKML , Marc Zyngier , Christoph Hellwig , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Jens Axboe Subject: Re: [patch 32/55] x86/irq: Restructure fixup_irqs() In-Reply-To: <20170620213447.GE24415@localhost.localdomain> Message-ID: References: <20170619233700.547167146@linutronix.de> <20170619235445.774272454@linutronix.de> <20170620213447.GE24415@localhost.localdomain> 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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Jun 2017, Keith Busch wrote: > On Tue, Jun 20, 2017 at 01:37:32AM +0200, Thomas Gleixner wrote: > > @@ -441,18 +440,27 @@ void fixup_irqs(void) > > > > for_each_irq_desc(irq, desc) { > > const struct cpumask *affinity; > > - int break_affinity = 0; > > - int set_affinity = 1; > > + bool break_affinity = false; > > > > if (!desc) > > continue; > > - if (irq == 2) > > - continue; > > > > /* interrupt's are disabled at this point */ > > raw_spin_lock(&desc->lock); > > > > data = irq_desc_get_irq_data(desc); > > + chip = irq_data_get_irq_chip(data); > > + /* > > + * The interrupt descriptor might have been cleaned up > > + * already, but it is not yet removed from the radix > > + * tree. If the chip does not have an affinity setter, > > + * nothing to do here. > > + */ > > + if (!chip !chip->irq_set_affinity) { > > + raw_spin_unlock(&desc->lock); > > + continue; > > + } > > A bit of a moot point since the very next patch deletes all of this, > but found this broken 'if' condition when compiling one at a time, > missing the '&&'. Hmm, How did I fatfinger that one after booting it? Yes, the patch is kinda moot, but I wanted to verify that shifting the logic around does not break any of the hotplug stress tests, so that the next step becomes less risky. Thanks, tglx