Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754849AbbFSQVv (ORCPT ); Fri, 19 Jun 2015 12:21:51 -0400 Received: from mga02.intel.com ([134.134.136.20]:16251 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754360AbbFSQVg (ORCPT ); Fri, 19 Jun 2015 12:21:36 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,644,1427785200"; d="scan'208";a="749712636" Message-ID: <5584418D.50408@linux.intel.com> Date: Sat, 20 Jun 2015 00:21:33 +0800 From: Jiang Liu Organization: Intel User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Thomas Gleixner CC: Sergey Senozhatsky , Borislav Petkov , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [-next] !irqd_can_balance() WARNINGs at irq_move_masked_irq() References: <20150619071123.GA511@swordfish> <55843EC9.9000401@linux.intel.com> <55843F79.4000606@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1954 Lines: 42 On 2015/6/20 0:15, Thomas Gleixner wrote: > On Sat, 20 Jun 2015, Jiang Liu wrote: > >> [...] >>>> Something in the kernel (not yet clear what) tries to move the hpet >>>> irq 0 by calling irq_set_affinity(). That's an kernel internal >>>> interface which does not check whether the NO BALANCE flag is set for >>>> the irq. So the call runs and triggers the move from next interrupt >>>> machinery which ends up calling irq_move_masked_irq() and that trips >>>> over the flag and yells. >>>> >>>> That's why I changed the WARN to a pr_warn() because we already know >>>> the call stack. >>>> >>>> So the core behaviour is inconsistent. We let the caller of >>>> irq_set_affinity() succeed and yell later because we think it's wrong. >>>> >>>> I'm pretty sure that we must drop the check for NO BALANCE in >>>> irq_move_masked_irq() and only check for the per_cpu bit, but at the >>>> same time I really want to know where that call to irq_set_affinity(irq0) >>>> is coming from. >>>> >>>> Can you please collect the output of /proc/timer_list for the previous >>>> patch and then replace the previous patch with the one below and >>>> gather all the data again? >>> >>> Hi Thomas, >>> Maybe it's caused by the hpet driver itself? >>> irq_set_affinity() may set the IRQD_SETAFFINITY_PENDING flag, >>> thus triggering the warning. >> And the usage pattern seems reasonable, the IRQF_NOBALANCING flag >> means nobody may change the affinity except myself:) > > Right, that's why I removed the restriction. I just wonder why we have > not seen that before ... I suspected it's caused by the hierarchy irqdomain at first glance because the multiple irq_datas issue, but seems it's not after checking the code. It will only be triggered if HPET works in MSI mode instead of legacy IRQ mode, but still need more investigation here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/