Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1611504ybb; Fri, 29 Mar 2019 07:54:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqwA4niVu3bZARlgqPkxooBx8pifVN6w+s78yIU1nabxYo9XQAgXDDOP+YrPUDwf6QFbVdis X-Received: by 2002:a17:902:1123:: with SMTP id d32mr48213792pla.16.1553871275510; Fri, 29 Mar 2019 07:54:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553871275; cv=none; d=google.com; s=arc-20160816; b=0u/z0TtOxPGN3ttSZz6rtrcp5ZfJWOP5yNFja2aKzwEF+aLr6LpkBipT+iBUrygD1z tV5ne9cF1DgMog4MtficjOdHksEoTPu5kz822FK0UNuZRJIoTbdqdXKGLAjDl881j/uk fo3/qfpKTtHRuQ14LDs7Xp1s5afV58zv4NmH4N3mBgRYO3BTsAgEeE39KUcxhLc9Jctr v7hhhfDwbNUtjngqtzOJ9DkFdwz32505jngIzjPXdTkttjtpl8oXZ9R0O4OFTBhJMbRg F7y5PCZmW5axLehWxxj2K+JKed3YTjuxEmoevo6xPHiaCzLSmX75ecCHVwKaksohHfj4 jEmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=ihlMKIDW514uvPmLGiSomuKEL7RTaohncZMwoMsF9t0=; b=S+Zg4W2FDECEQ4ZNw7IlCMeMExcDKckbVTkiEJdEvDXQi5L5+aJTSqXn19Dkh2t7q4 Am1armhaY88AwjPeKGsT/PpiCXxBEPnreeUkobalI//kh+bo4kUe+03aAYLJdABoHLpU JGebVtmO9ppQ8JkzzqzELGmagvkTbYMPqUc/t6+8hOOBiywykgQp6XhVFtRrUaeUMtVj iI2XWsEN8kNjR5MWFnJ+xwqyt1hwKJEw/Wh3kIbdL/pVTW2MhOn2MTqMhN4+pfkhNfzP IPExiHx8YY/x0Dfo/unaDR+0OIQc6vBSixjOvLy7PYq/gjpL2LoUAqMbjzh7DT0BKO/G EyNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 89si1983316pfs.243.2019.03.29.07.54.19; Fri, 29 Mar 2019 07:54:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729197AbfC2Oxg (ORCPT + 99 others); Fri, 29 Mar 2019 10:53:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:37504 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728815AbfC2Oxg (ORCPT ); Fri, 29 Mar 2019 10:53:36 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 629E32183F; Fri, 29 Mar 2019 14:53:34 +0000 (UTC) Date: Fri, 29 Mar 2019 10:53:32 -0400 From: Steven Rostedt To: Marc Zyngier Cc: Zenghui Yu , julien.thierry@arm.com, mingo@redhat.com, catalin.marinas@arm.com, will.deacon@arm.com, mark.rutland@arm.com, linux@armlinux.org.uk, james.morse@arm.com, suzuki.poulose@arm.com, wanghaibin.wang@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] irqchip/gic-v3: Make gic_handle_irq() notrace Message-ID: <20190329105332.6b7fc1ae@gandalf.local.home> In-Reply-To: <237b00d0-8a8d-ede6-91b1-c3e23e61925c@arm.com> References: <1553865808-30604-1-git-send-email-yuzenghui@huawei.com> <237b00d0-8a8d-ede6-91b1-c3e23e61925c@arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 29 Mar 2019 13:58:40 +0000 Marc Zyngier wrote: > On the other hand, if you can generate pseudo-NMIs, you could end-up > tracing gic_handle_irq whilst being inside the tracing code with > interrupts being notionally disabled (and that could be pretty bad). Actually, that should still be safe. The tracing code is expected to trace NMIs. Now the entry of an NMI can be an issue because of the way tracing is enabled. But this would also cause function tracing to crash, which was not stated. Does function tracing have the same issue, or is this just with function_graph tracing? This is because a breakpoint is added to all the places that are going to be traced so that the "nops" at the beginning of function calls are going to be converted to calls to the tracer. Now that means a breakpoint is being added at the beginning of gic_handle_irq(). I don't know how this pseudo NMI works, but we have notrace set for do_NMI because breakpoints at the entry (before it can fix things) causes issues. But this still doesn't make sense because the gic_handle_irq() call doesn't fix things up either, so other functions that are traced by gic_handle_irq() should blow up too, which appears (by the patch) not to be the case. -- Steve