From patchwork Fri Aug 17 03:48:56 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shawn Guo X-Patchwork-Id: 1336951 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id BAEBEDF266 for ; Fri, 17 Aug 2012 03:52:23 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1T2DYS-0006UM-PW; Fri, 17 Aug 2012 03:49:00 +0000 Received: from mail-pb0-f49.google.com ([209.85.160.49]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1T2DYP-0006U9-QV for linux-arm-kernel@lists.infradead.org; Fri, 17 Aug 2012 03:48:58 +0000 Received: by pbbrq8 with SMTP id rq8so2773903pbb.36 for ; Thu, 16 Aug 2012 20:48:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=AFf6dkf2mnSF8LKtjH5AAodNO4Nw1F0J7B9m/BgqlLg=; b=IF0VOql7ex7mYVdDhb1HR/8p8C0A+SKzBj+muzTqlnLwhAXQOmS1oi2OYAtOkH+Gu5 FMOtMLXODnCvIkwLu1CpiwIOfI7X9oT4bQwGVyCxaxmduEKWkArB37S5Y6yKkhFwCLl0 kXq1BESsin8sEDRTvf1fN20fg31+0lz+A37YxZRUxFqW38NYCyTnCdx2rIMddmRgYibo gaiVxHfw0ACCo2i10w+ImKbTcZN0Fw5plFRCZ+Jp5LuXPROCWGBT64/cyWjxDBtnLfCx Pa+QQ7FCOiZKgwk7pLofVm31kwYe+msbuqtAQ3x3SQUjMNklLUwyEVxB6cxSrgWaruQX LVLg== Received: by 10.68.231.233 with SMTP id tj9mr8203030pbc.39.1345175335842; Thu, 16 Aug 2012 20:48:55 -0700 (PDT) Received: from S2101-09.ap.freescale.net ([221.225.141.189]) by mx.google.com with ESMTPS id to6sm3996844pbc.12.2012.08.16.20.48.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2012 20:48:55 -0700 (PDT) Date: Fri, 17 Aug 2012 11:48:56 +0800 From: Shawn Guo To: Russell King - ARM Linux Subject: Re: imx6q restart is broken Message-ID: <20120817034854.GE24242@S2101-09.ap.freescale.net> References: <20120808101817.GA14718@S2101-09.ap.freescale.net> <50224547.9020000@de.bosch.com> <50232C17.9000700@gmail.com> <20120809092021.GQ18957@n2100.arm.linux.org.uk> <502BBB43.5010403@gmail.com> <20120815214412.GC32560@n2100.arm.linux.org.uk> <20120816023109.GH2258@S2101-09.ap.freescale.net> <20120816223446.GB15883@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120816223446.GB15883@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQm+quml86K6ErSR9g2gJX7H+y+qwR95TdiicwLQdIHMq39ZdmM8mIh3qWS97sjj5c4bMSfJ X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.160.49 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Dirk Behme , Catalin Marinas , Sascha Hauer , Hui Wang , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Thu, Aug 16, 2012 at 11:34:46PM +0100, Russell King - ARM Linux wrote: > This doesn't get around the problem that userspace can still effectively > issue a DoS against the system by just running a dmb in a tight loop. > Or maybe this would have a much more dramatic effect: > > while (1) { > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > asm("dmb"); > } > > and make that 3 seconds to get a ps listing turn into something much > longer? > From my testing, no, it does not get the thing even worse. > I think what needs to happen here (while we wait) is someone _with_ the > problem needs to experiment, and find out how many nops are needed for > the DMB not to have much effect in cpu_relax(). If it turns out we just > need to put one nop in, then that's not _too_ bad. At least, I need to have 5 nops to get rid of the issue, something like below. Regards, Shawn --8<--- diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h index 99afa74..3e1b099 100644 --- a/arch/arm/include/asm/processor.h +++ b/arch/arm/include/asm/processor.h @@ -80,7 +80,14 @@ extern void release_thread(struct task_struct *); unsigned long get_wchan(struct task_struct *p); #if __LINUX_ARM_ARCH__ == 6 || defined(CONFIG_ARM_ERRATA_754327) -#define cpu_relax() smp_mb() +#define cpu_relax() do { \ + asm("nop"); \ + asm("nop"); \ + asm("nop"); \ + asm("nop"); \ + asm("nop"); \ + smp_mb(); \ + } while (0) #else #define cpu_relax() barrier() #endif