Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp52232pxk; Tue, 15 Sep 2020 17:31:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDGNiNT/rwHYjQ3uz4GR3qhUn3b7MqDV5lmBteGGzfVXxPZjW9BswuZgbBZgsb7HhKrCma X-Received: by 2002:a17:907:4035:: with SMTP id nk5mr22260715ejb.418.1600216317612; Tue, 15 Sep 2020 17:31:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600216317; cv=none; d=google.com; s=arc-20160816; b=PCLwUk1M2qERSOY0Od+dHYA+rFKDAN1tFAbnWoanbpGim5u2c/TyscjvJ+5TazcXQj LYEIGgHAcDiJzgSEnnZJewm0zgdHanOoh92xweZo12IiaQK9NJBCFBSItkJkn8IX2N2d C4GbsIxpIVTBsUSCAb9j/kgw7ucatr9QUJ/KcFAKRymfzc3FWC4mQNIIH+eMvTkNsktE u4U0lgWo0L0IEz5TJU9DHBe+Ev+pyrWUHnHIFT/tQnM6FiPJ//oLPxihKT8pT8kUzWw7 zoNDQ3hu6YIxQF05YRgSm+AHKr/cmeAu3FPbDJf66sOPxX9Jzv94Ix+KUfxvMXKnO4GF TLwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=jFlH2Mb4PbicIWoSy/doLle0e/no7tiKAYBIFeeMPlE=; b=bEYKxgf+dCgtZ/CChlGKHUHNmEZEHKJVL+sljCrGslQkjRNkw8TtW7AlsgZE31LbRR PoroXPshQdCs5kDca6vAx/iZjbwn+bLCLSUGxfNcrnzMGF0BFsz7oBDPwdI79ku/8gVu hhzH1OMLVc2wyaZPm8Cd/XypWadtYxh8UKg0RQ8EYE1XJ3dsMhZ/j8wme61zir0CYf1G BxVn0QvRiKLz+IeJqu+r7IcSoHstI2BxIQIzRlY/wsmrvVfWWyx42B7gXe0Iproaph0+ fsMqXs0hFpm1EiRAQsdei/bDZkSEFs+ByGwS4Drg4p7S+vtxagWEtHbeAzLkUQDGWTBk 0ZRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cmL+DxSQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z3si11229495ejw.596.2020.09.15.17.31.35; Tue, 15 Sep 2020 17:31:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cmL+DxSQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726507AbgIPAa7 (ORCPT + 99 others); Tue, 15 Sep 2020 20:30:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726740AbgIONpk (ORCPT ); Tue, 15 Sep 2020 09:45:40 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 481CDC061225 for ; Tue, 15 Sep 2020 06:45:25 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id c18so3366063wrm.9 for ; Tue, 15 Sep 2020 06:45:25 -0700 (PDT) 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=jFlH2Mb4PbicIWoSy/doLle0e/no7tiKAYBIFeeMPlE=; b=cmL+DxSQG5LinAgNudybg6vutCW3d525J8bCTa5zQRsM1+6+9u7btw251f1MR5sX39 Kn/qOa17Cl5qvCihyI9tkcM8WGn9vqBjwld//Cam6u5a3lqBnRxOS4kPFMaM2+Wh9lia Dn+7EZImyLJIgW00vBvwynPEbNYZ0mpBabcIzIYm5h5992MwZNrWy+feXgrdqpRfjP7c KnbtFJAXCexsAwnXmW5KKgDj9dLqg13gTmbXS8r66cb9GGwEJGnYYoGLIzVkjlffojzc WyHU31DfYADP/TjbzvIKu9VPGeBim2GV59AVMSdRiTBRMbmZklS6/f5SMPDIgQUCdwVb r2fQ== 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=jFlH2Mb4PbicIWoSy/doLle0e/no7tiKAYBIFeeMPlE=; b=DLu1D2YtNp1ljfTygkpPE+KV/vVj9GO2lSjb3QjJMOE4p2/ub1kov3MgqXp3t33Jjh ma8UONpjXcx/lSnT2ZhGaXPaqbinZSbyTAifpK7w/rBhNIX45LUkRWc0LPxwNQeMEIJP IjvMq4gu0lwDTOvdrc9qdTrV/Ep9PdCejGyL0x1QWfEJ4ghSPtm0BeaW3qLiV1x3bLQD NagjhnURuqUswFCnQwdrrrNK8F8y9dgE7jpEH8Is6V36AQrKX/F8ys1mDNpRZSMiGVqa lUA3N/9twmPfM98bzjb5v6fGCilKbD39vKLgrTteBfBXH0IlTdDCkbq8uhrG7bdVCOmb /8eQ== X-Gm-Message-State: AOAM531Xn95j+1xYMKiSEvqSFEatTo5y2Te569EXN/DB8F8vqHFfiorn OxIWlnUnuDHoo0t9I81JOzWMaMHtMB1sPw== X-Received: by 2002:adf:f0c7:: with SMTP id x7mr21149017wro.315.1600177523578; Tue, 15 Sep 2020 06:45:23 -0700 (PDT) Received: from holly.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id x2sm26804404wrl.13.2020.09.15.06.45.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2020 06:45:22 -0700 (PDT) Date: Tue, 15 Sep 2020 14:45:20 +0100 From: Daniel Thompson To: Doug Anderson Cc: Jason Wessel , Peter Zijlstra , Sumit Garg , Petr Mladek , Sergey Senozhatsky , Will Deacon , Masami Hiramatsu , kgdb-bugreport@lists.sourceforge.net, LKML , Patch Tracking Subject: Re: [PATCH v3 3/3] kernel: debug: Centralize dbg_[de]activate_sw_breakpoints Message-ID: <20200915134520.jgbxallmksifrg2x@holly.lan> References: <20200914130143.1322802-1-daniel.thompson@linaro.org> <20200914130143.1322802-4-daniel.thompson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 14, 2020 at 05:13:28PM -0700, Doug Anderson wrote: > Hi, > > On Mon, Sep 14, 2020 at 6:02 AM Daniel Thompson > wrote: > > > > During debug trap execution we expect dbg_deactivate_sw_breakpoints() > > to be paired with an dbg_activate_sw_breakpoint(). Currently although > > the calls are paired correctly they are needlessly smeared across three > > different functions. Worse this also results in code to drive polled I/O > > being called with breakpoints activated which, in turn, needlessly > > increases the set of functions that will recursively trap if breakpointed. > > > > Fix this by moving the activation of breakpoints into the debug core. > > > > Signed-off-by: Daniel Thompson > > --- > > kernel/debug/debug_core.c | 2 ++ > > kernel/debug/gdbstub.c | 1 - > > kernel/debug/kdb/kdb_debugger.c | 2 -- > > 3 files changed, 2 insertions(+), 3 deletions(-) > > I like the idea, but previously the kgdb_arch_handle_exception() was > always called after the SW breakpoints were activated. Are you sure > it's OK to swap those two orders across all architectures? Pretty sure, yes. However, given the poor attention to detail I demonstrated in patch 2/3, I figure I'd better write out the full chain of reasoning if I want you to trust me ;-) . kgdb_arch_handle_exception() is already called frequently with breakpoints disabled since it is basically a fallback that is called whenever the architecture neutral parts of the gdb packet processing cannot cope. So your question becomes more specific: is it OK to swap orders when the architecture code is handling a (c)ontinue or (s)tep packet[1]? The reason the architecture neutral part cannot cope is because it because *if* gdb has been instructed that the PC must be changed before resuming then the architecture neutral code does not know how to effect this. In other words the call to kgdb_arch_handle_exception() will boil down to doing whatever the architecture equivalent of writing to linux_regs->pc actually is (or return an error). Updating the PC is safe whether or not breakpoints are deactivated and activating the breakpoints if the architecture code actually censors the resume is a bug (which we just fixed). Daniel. [1] The fallthroughs aren't a whole lot of fun to read but if gdb_cmd_exception_pass() provokes a fallthrough then it will have rewritten the packet as a (c)ontinue.