From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933157AbcBYP6M (ORCPT ); Thu, 25 Feb 2016 10:58:12 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33285 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932407AbcBYP6J (ORCPT ); Thu, 25 Feb 2016 10:58:09 -0500 Subject: Re: Interesting csd deadlock on ARC To: Russell King - ARM Linux References: <56C6BA82.1060909@synopsys.com> <56CBEC66.2030401@synopsys.com> <20160223095824.GH6356@twins.programming.kicks-ass.net> <56CD36CD.2080303@synopsys.com> <20160225140654.GL6357@twins.programming.kicks-ass.net> <56CF0E6B.5020903@synopsys.com> <20160225143046.GR19428@n2100.arm.linux.org.uk> Cc: Peter Zijlstra , Will Deacon , "linux-arch@vger.kernel.org" , Marc Zyngier , Frederic Weisbecker , lkml , Noam Camus , arcml From: Vineet Gupta Organization: Synopsys Message-ID: <56CF248A.3070805@synopsys.com> Date: Thu, 25 Feb 2016 21:28:02 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160225143046.GR19428@n2100.arm.linux.org.uk> 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 On Thursday 25 February 2016 08:00 PM, Russell King - ARM Linux wrote: > On Thu, Feb 25, 2016 at 07:53:39PM +0530, Vineet Gupta wrote: >> But then ARM CONFIG_SMP on UP hardware will still crap out because there >> is no way to send IPI to self. Same as the bug in above discussion. I'm >> surprised they way ARM guys worked around it. > > We haven't worked around it - the code which provoked the oops that was > seen (in the cpufreq code) was changed not to call it, which has the > effect of making the problem "go away", at least for now. > > We still have the problem that if it does get called on UP, it'll blow > up - and I don't see any point in complicating the code for something > that never happens right now. Right so my statement "workaround" was technically incorrect. But like you say, it's a ticking bomb which will certainly go off on your SMP on UP systems the moment someone adds irq_work_queue_on() in some obscure corner of generic code. And I think this merits fixing in generic code ! -Vineet