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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50CF1C2D0E4 for ; Tue, 17 Nov 2020 17:29:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C2978241A7 for ; Tue, 17 Nov 2020 17:29:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SwX3n2Dp"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="TPACWcwj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2978241A7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Q4sln9ZHilEQ6jTnzBazA3+4V/lrN4i+b/TltaW9muI=; b=SwX3n2DprKe4W+dDHQaEvHxas muLlLBal/2wwEDRtx5VLMWRxlKv2ETqjsuAJHbrHGAltJD/7YVElvPZO8UkseGEqPMPgrAZnaLtB+ innMPHP1Hs+2ashqX4T8Y6qKPKRERdMWHpyjT1zWuE00itQWyzWgdgPKy4N0zpAjDwvqMh+azu0s8 GvYlliwQVLjsOj4oJU2cgATu3uyh7/HEYy0A5owC+zdpw/e4zdpU6WWRf4dxUXBlgg3mrI22PuoZ/ SC6NYmxpSbRNaLXwr0cM4BXjEKO7LEYAwPiYB8RC+YVf7+hho8B89/ib+Hl4s/FHSjI4jAOU3cudi TkVy9QqMw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kf4mU-0002sc-Qq; Tue, 17 Nov 2020 17:28:38 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kf4mS-0002sG-6B for linux-arm-kernel@lists.infradead.org; Tue, 17 Nov 2020 17:28:37 +0000 Received: by mail-ed1-x542.google.com with SMTP id q3so23294810edr.12 for ; Tue, 17 Nov 2020 09:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=joOWpFZv2OqdBoT9vbTXVYWF1dy1s2St0EF9MsCWDyU=; b=TPACWcwjuyepiS88n8no+2DB4xv5YuIergeymxl/5BRdzDikUj7YnazRMnLUhoZ47M bYDkEqBQh9OEZmS3cARy/imN1vH4e42KNtaCJKVK2dF+HpZFOs2vcuW4D3Ht+bDUQATQ vUVKo9b339EfpT7LW4tKW2tebnsH/zLVgg4ycEmjSI9mx4Ey6Gl97Z7YZlqlLBem3CUs oru0wblYH72Dw1vGx/Dn5PkSlKuKwL3rKjjH1F6fdiG1nzEdahGsdfaMJcThm8YP3Tx1 Q/W13B/8SMOa14irNzNfBd/pEol1QCZBTNbdptJN1IdiF8ce9GgJC3V9PY1v4BNC8Rp1 UQqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=joOWpFZv2OqdBoT9vbTXVYWF1dy1s2St0EF9MsCWDyU=; b=dSVHCgYHNm24UZEPwkhH7VkjcJA5QvpdViC70Cbi9XO0rTzQxY1LkH9eZhLHk6MNbB KKDP+OXP37q7FMpYtE1tG3NmH5KoMIUgGKe4jSoxzMEYIzRfHAHDhheDgMQUDG07lSLm sOx8C7m+E2jeWlYqdsOT5hotslljvE2cgIzSS7vtvQeiNikPGKVl1BpfJyVtg5gG1rNX r1FJ560c0uo9UGvE3sOQ8cSfF4MAsKQ3ZFwPsgn8wedxksLBK2pHqZHBZRPiPFdTWCDe B1JDSLn31tuopxZwsxhGfnSceMOMxXc2lXxDk+fkdi4IpaozKbuCcrDLXpClNKcQIojs 6HGQ== X-Gm-Message-State: AOAM531L32v2Kn4TbjkM/6CryC6nqN/8sntC9KkK1bue/H8V5griDy7a 6MOqtKCknFmmMHij6EEO0arYLQ== X-Google-Smtp-Source: ABdhPJySM3vNJblXQgsBAfezcC1rOb4hP7Fvs4XQowHj8KKiAZTing6zACwr8MXLZROu5NQN21hLGQ== X-Received: by 2002:a50:8a8e:: with SMTP id j14mr11299234edj.87.1605634112840; Tue, 17 Nov 2020 09:28:32 -0800 (PST) Received: from myrica ([2001:1715:4e26:a7e0:116c:c27a:3e7f:5eaf]) by smtp.gmail.com with ESMTPSA id d14sm950777edu.63.2020.11.17.09.28.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Nov 2020 09:28:32 -0800 (PST) Date: Tue, 17 Nov 2020 18:28:12 +0100 From: Jean-Philippe Brucker To: Will Deacon Subject: Re: [PATCH] arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line Message-ID: <20201117172812.GA551957@myrica> References: <20201029173440.117174-1-jean-philippe@linaro.org> <20201102114152.GA3452@willie-the-truck> <20201102225255.fa991f3607c45bbbb161803c@kernel.org> <20201103091305.GA6723@myrica> <20201103092315.GC4403@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201103092315.GC4403@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201117_122836_243002_BF5DC8D6 X-CRM114-Status: GOOD ( 17.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: catalin.marinas@arm.com, Masami Hiramatsu , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 03, 2020 at 09:23:16AM +0000, Will Deacon wrote: > Yes, let's just set all of DAIF during the trampoline. Also, while I've got > you, If you get a chance, I'd appreciate any feedback on my proposal for > reworking our debug exception handling altogether: > > https://lore.kernel.org/r/20200626095551.GA9312@willie-the-truck Well, I stared at this for a while... It looks fine to me, but I don't have a full picture of the trap infrastructure (not sure whether you were asking me). I could help with testing if you get around to reworking it. > On taking an interrupt from EL1, stash MDSCR_EL1.SS in a pcpu variable and > clear the register bit if it was set. Then unmask only D and leave I set. On > return from the exception, set D and restore MDSCR_EL1.SS. If we decide to > reschedule, unmask D (i.e. we only step into interrupts if we need a > reschedule. Alternatively, we could skip the reschedule if we were > stepping.) Any specific reason to treat reschedule differently, or just to keep things simple? I'm asking because that could be a problem with the current code: when taking an interrupt while stepping EL1, we keep MDSCR_EL1.SS set and unmask D before calling the IRQ handler. The step exception might only be taken after the next context synchronization event (on QEMU it happens at an isb in the timer handler). If the IRQ handler doesn't happen to do any context synchronization and we reschedule, I guess the step exception could happen after the next eret? Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel