From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BEE98C433F5 for ; Wed, 16 Feb 2022 11:48:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Pb2Ei2/Uw485WPXUpFoH13JPfazkOgnmSKCeiMMtfok=; b=1blcarRV4in8H8 YerqxrdFLhhqwbYAAePV2hJYsW/ZUIsKBL3d9fMDAM7VVgSEBUuSVlBtDHFhUMMXToJZNZM75Bg1W LSU4JaezPC5qXBfYY2sgenNOJb3xYzkLdUOBrsm5rRCX4uaTQJPizfSbvrO1VlfZ8OPiJcbKp7V/F ixz8zJJRGHd+H/yqQ6xOCJX0EMxW7TjcWZhlwSHOz4xwYBNsdukczuQwVetW3rWqp+BUxDAuSpe/j 7mxwkVwVr0A440Q6h3r1EH1eU38stk0049m4UT2XkPqIaON8y+e2uygunY6XRK3jYkjSPMwrVX+tM tWb1PAb3gYiPu/dpjWVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKImA-006o4H-3C; Wed, 16 Feb 2022 11:47:14 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKIlz-006nz2-B6 for linux-arm-kernel@lists.infradead.org; Wed, 16 Feb 2022 11:47:11 +0000 Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JzGQ00WYyz67gXC; Wed, 16 Feb 2022 19:46:32 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Feb 2022 12:46:56 +0100 Received: from [10.47.81.42] (10.47.81.42) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Feb 2022 11:46:55 +0000 Message-ID: <8c582e45-0954-a2ea-764a-4dd78a464988@huawei.com> Date: Wed, 16 Feb 2022 11:46:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Test 73 Sig_trap fails on arm64 (was Re: [PATCH] perf test: Test 73 Sig_trap fails on s390) To: Will Deacon CC: Leo Yan , Marco Elver , "Thomas Richter" , , , , , , , , "Mark Rutland" , "linux-arm-kernel@lists.infradead.org" , References: <20211216151454.752066-1-tmricht@linux.ibm.com> <90efb5a9-612a-919e-cf2f-c528692d61e2@huawei.com> <20220118091827.GA98966@leoy-ThinkPad-X240s> <20220118124343.GC98966@leoy-ThinkPad-X240s> <06412caf-42e4-5c4b-c9b3-9691075405bd@huawei.com> <20220215143459.GB7592@willie-the-truck> From: John Garry In-Reply-To: <20220215143459.GB7592@willie-the-truck> X-Originating-IP: [10.47.81.42] X-ClientProxiedBy: lhreml754-chm.china.huawei.com (10.201.108.204) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220216_034703_691560_8B45BD96 X-CRM114-Status: GOOD ( 27.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Will, > Sorry, I haven't had time to look at this (or the thousands of other mails > in my inbox) lately. > Thanks > I don't recall all of the details, but basically hw_breakpoint really > doesn't work well on arm/arm64 -- the sticking points are around handling > the stepping and whether to step into or over exceptions. Sadly, our ptrace > interface (which is what is used by GDB) is built on top of hw_breakpoint, > so we can't just rip it out and any significant changes are pretty risky. > > What I would like to happen is that we rework our debug exception handling > as outlined by [1] so that kernel debug is better defined and the ptrace > interface can interact directly with the debug architecture instead of being > funnelled through hw_breakpoint. Once we have that, I think we could try to > improve hw_breakpoint much more comfortably (or at least defeature it > considerably without having to worry about breaking GDB). I started this a > couple of years ago, but I haven't found time to get back to it for ages. > > Anyway, to this specific test... > > When we hit a break/watchpoint the faulting PC points at the instruction > which faulted and the exception is reported before the instruction has had > any other side-effects (e.g. if a watchpoint triggers on a store, then > memory will not have been updated when the watchpoint handler runs), so if > we were to return as usual after reporting the exception to perf then we > would just hit the same break/watchpoint again and we'd get stuck. GDB > handles stepping over the faulting instruction, but for perf (and assumedly > these tests), the kernel is expected to handle the step. This handling > amounts to disabling the break/watchpoint which we think we hit and then > attempting a hardware single-step. During the step we could run into more > break/watchpoints on the same instruction, so we'll keep disabling things > until we eventually manage to complete the step, which is signalled by a > specific type of debug exception. At this point, we re-enable the > break/watchpoints and we're good. > > Signals make this messy, as the step logic will step_into_ the signal > handler -- we have to do this, otherwise we would miss break/watchpoints > triggered by the signal handler if we had disabled them for the step. > However, it means that when we return back from the signal handler we will > run back into the break/watchpoint which we initially stepped over. When > perf uses SIGTRAP to notify userspace that we hit a break/watchpoint, > then we'll get stuck because we'll step into the handler every time. > > Hopefully that clears things up a bit. Ideally, the kernel wouldn't > pretend to handle this stepping at all for arm64 as it adds a bunch of > complexity, overhead to our context-switch and I don't think the current > behaviour is particularly useful. > Right, so what I am hearing altogether is that for now we should just skip this test. And since the kernel does not seem to advertise this capability we need to disable for specific architectures. Thanks, John > [1]https://lore.kernel.org/all/20200626095551.GA9312@willie-the-truck/ > . _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel