From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eddie.linux-mips.org ([148.251.95.138]:35626 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbdLFOu6 (ORCPT ); Wed, 6 Dec 2017 09:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1]:43562 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S23990591AbdLFOu4CN52s (ORCPT ); Wed, 6 Dec 2017 15:50:56 +0100 Date: Wed, 6 Dec 2017 14:57:45 +0100 From: Ralf Baechle To: James Hogan Cc: Paul Burton , James Hogan , linux-mips@linux-mips.org, stable@vger.kernel.org Subject: Re: [PATCH] MIPS: CM: Drop WARN_ON(vp != 0) Message-ID: <20171206135745.GD5238@linux-mips.org> References: <20171205222822.15034-1-james.hogan@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171205222822.15034-1-james.hogan@mips.com> Sender: stable-owner@vger.kernel.org List-ID: On Tue, Dec 05, 2017 at 10:28:22PM +0000, James Hogan wrote: > Since commit 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to > mips_cm_lock_other()"), mips_smp_send_ipi_mask() has used > mips_cm_lock_other_cpu() with each CPU number, rather than > mips_cm_lock_other() with the first VPE in each core. Prior to r6, > multicore multithreaded systems such as dual-core dual-thread > interAptivs with CPU Idle enabled (e.g. MIPS Creator Ci40) results in > mips_cm_lock_other() repeatedly hitting WARN_ON(vp != 0). > > There doesn't appear to be anything fundamentally wrong about passing a > non-zero VP/VPE number, even if it is a core's region that is locked > into the other region before r6, so remove that particular WARN_ON(). > > Fixes: 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to mips_cm_lock_other()") > Signed-off-by: James Hogan > Reviewed-by: Paul Burton > Cc: Ralf Baechle > Cc: linux-mips@linux-mips.org > Cc: # 4.14+ > --- > arch/mips/kernel/mips-cm.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c > index dd5567b1e305..8f5bd04f320a 100644 > --- a/arch/mips/kernel/mips-cm.c > +++ b/arch/mips/kernel/mips-cm.c > @@ -292,7 +292,6 @@ void mips_cm_lock_other(unsigned int cluster, unsigned int core, > *this_cpu_ptr(&cm_core_lock_flags)); > } else { > WARN_ON(cluster != 0); > - WARN_ON(vp != 0); I think the reason is that for a while the combination of SMP/CMP with MT was at the bottom of priorities and nobody really cared about it so a WARN_ON was thrown in. Which in this case might well itself be a bug! Ralf