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 8D535C433EF for ; Mon, 24 Jan 2022 09:21:08 +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:MIME-Version:Date:Message-ID:From: References:CC:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=CDDRKTM27slDpG2VPHj9y9ic9gGX2VADSNcX+nA8rOs=; b=3MLF81URHUfsrayrrSiovgqM1T p0Ha3zQaiyBeZb7ZBAEiDqTZzuM/Sg7ob2iYYmYi6GeYE1hvwjp3C7n4z7lXwKNYbFoWFqDP4emI8 8CPbuW7rNX+3A8BaF7fF0dAwVO3CJ+PNaq2cVA9OzpgK58jwo5+Ng9tU99Yk0s5Q4ACoMuZg/CZYd OtZ28qgO7BIltKcOG/NAkf/0e75XanEx/th/9pUtT7o7R79DRCVGnQn4HG15vt+/eWPrbfbgGUJ5m RHCo+1w9lzei6xZa1QVD/7FTJimAl5unOwBhQUKsVfyC74fsx2qQETnd3gLOVFETcgh/OdCxJXC5U z7IRiUwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nBvVn-002lj3-Ec; Mon, 24 Jan 2022 09:19:43 +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 1nBvVi-002liR-PM for linux-arm-kernel@lists.infradead.org; Mon, 24 Jan 2022 09:19:40 +0000 Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jj4854kSmz686qc; Mon, 24 Jan 2022 17:15:17 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 10:19:30 +0100 Received: from [10.47.89.21] (10.47.89.21) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 09:19:29 +0000 Subject: Test 73 Sig_trap fails on arm64 (was Re: [PATCH] perf test: Test 73 Sig_trap fails on s390) To: Leo Yan , Marco Elver , Will Deacon CC: 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> From: John Garry Message-ID: Date: Mon, 24 Jan 2022 09:19:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20220118124343.GC98966@leoy-ThinkPad-X240s> Content-Language: en-US X-Originating-IP: [10.47.89.21] X-ClientProxiedBy: lhreml709-chm.china.huawei.com (10.201.108.58) 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-20220124_011939_028495_E81BAF28 X-CRM114-Status: GOOD ( 12.75 ) 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 On 18/01/2022 12:43, Leo Yan wrote: Hi Will, Can you kindly check below the question from Leo on this issue? You were cc'ed earlier in this thread so should be able to find more context, if needed. Cheers, John > On Tue, Jan 18, 2022 at 12:40:04PM +0100, Marco Elver wrote: > > [...] > >>> Both Arm and Arm64 platforms cannot support signal handler with >>> breakpoint, please see the details in [1]. So I think we need >>> something like below: >>> >>> static int test__sigtrap(struct test_suite *test __maybe_unused, int subtest __maybe_unused) >>> { >>> ... >>> >>> if (!BP_SIGNAL_IS_SUPPORTED) { >>> pr_debug("Test not supported on this architecture"); >>> return TEST_SKIP; >>> } >>> >>> ... >>> } >>> >>> Since we have defined BP_SIGNAL_IS_SUPPORTED, I think we can reuse it at >>> here. >>> >>> [1]https://lore.kernel.org/lkml/157169993406.29376.12473771029179755767.tip-bot2@tip-bot2/ >> Does this limitation also exist for address watchpoints? The sigtrap >> test does not make use of instruction breakpoints, but instead just >> sets up a watchpoint on access to a data address. > Yes, after reading the code, the flow for either instrution breakpoint > or watchpoint both use the single step [1], thus the signal handler will > take the single step execution and lead to the infinite loop. > > I am not the best person to answer this question; @Will, could you > confirm for this? Thanks! > > Leo > > [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/hw_breakpoint.c _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel