Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1115705pxb; Fri, 22 Jan 2021 07:32:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5EMGnrxFsVCM7IbTFpR8nW8GDmTh9blli/Ttl8ek8KSkiR3LjIZmxGJaeeTMbCdl8cvb3 X-Received: by 2002:a17:906:1348:: with SMTP id x8mr3233352ejb.81.1611329546024; Fri, 22 Jan 2021 07:32:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611329546; cv=none; d=google.com; s=arc-20160816; b=h0a3jLJ28ArCQGUyWFazRf/fNTJMLFvaMMuZkkX1sgz2HxjS2pIev0QkPkSVZ1FbLF Az2B6W0hVjFglnJWyAalx/ytAGdkSzpZ7wGy9vcgHdDiRrfCXbi8xBlbFcBUy3dRn5Nb s+lFWNdScw0OS0IrYyT1k8kDzmtpWP4R51S5C8q8mBAvZ6RALjfSdHCLwUt6z+i4PvEN Y2+90uSyBIHBA+2NzYHepuWDFZlpzFdgqf3ut6teUjojc711FyKDsbqjxTsgjwwVeJxs EWF9xxdxMzIDsVRaAcbqrpsJIlPXaGBUXAL255XaDuVcrR4vMZlTdrAvnTbFwEK/DviN ye4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=0FB1pdJSlzrmWHuHUX1M8H0tp+ZholYU29ZSIh/FGaY=; b=caw0S3I2q8kTAh3B+NHZMc02ZsL/qrftWT3ZSevBrZLsNy/s7Qzech6KPXbJscbLp3 5k6/Nqh6W9jEOzJYpu1+BkKPiRb2zuAL+1sJSG+/beLee9oHjm0qABQUIQxHQWFVIgSi KgMz5NMPSzFsSxoQ6S7MA8CYm4Yy3RU7tPS5bt25ydzCAgtYiydtnfsqMvMTXzK1tOMe Wy53L70Q6XOPFp4sqK+nHvtTCyiZ4hhZCjAhYQRUN4Fz6nHPeDYfZwuQYPLXHo7fbcCn en27M88dbgaBwKBHy2ctNH1pt9Esc6WnQqc2l97+cm0XHnZvmY5XbSv/s39R3PPbKC0j zLIQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lc16si3066515ejb.514.2021.01.22.07.32.02; Fri, 22 Jan 2021 07:32:26 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728875AbhAVPad (ORCPT + 99 others); Fri, 22 Jan 2021 10:30:33 -0500 Received: from foss.arm.com ([217.140.110.172]:53324 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728566AbhAVPaR (ORCPT ); Fri, 22 Jan 2021 10:30:17 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0D8D11D4; Fri, 22 Jan 2021 07:29:24 -0800 (PST) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 06E033F66E; Fri, 22 Jan 2021 07:29:23 -0800 (PST) Date: Fri, 22 Jan 2021 15:29:21 +0000 From: Qais Yousef To: Masami Hiramatsu Cc: Catalin Marinas , Will Deacon , Jean-Philippe Brucker , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: kprobes: Fix Uexpected kernel BRK exception at EL1 Message-ID: <20210122152921.gnevsymmd4mckkee@e107158-lin> References: <20210122110909.3324607-1-qais.yousef@arm.com> <20210122223601.4b3b7e01c6ec583c0439f1c9@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210122223601.4b3b7e01c6ec583c0439f1c9@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/22/21 22:36, Masami Hiramatsu wrote: > > Further analysis showed that kcb->kprobe_status is set to > > KPROBE_REENTER when the error occurs. By teaching > > kprobe_breakpoint_ss_handler() to handle this status I can no longer > > reproduce the problem. > > Very good catch! Yes, this missed the reentered kprobe case. > > Acked-by: Masami Hiramatsu Thanks! > > > > > Fixes: ba090f9cafd5 ("arm64: kprobes: Remove redundant kprobe_step_ctx") > > Signed-off-by: Qais Yousef > > --- > > > > Another change in behavior I noticed is that before ba090f9cafd5 ("arm64: > > kprobes: Remove redundant kprobe_step_ctx") if 'cur' was NULL we wouldn't > > return DBG_HOOK_ERROR, but after the change we do. > > It should not happen, since the KPROBES_BRK_SS_IMM must be used only for > kprobes's second break which must happen on the trampoline instruction > buffer, which must set current kprobes before execution. I see. Thanks for the explanation! Cheers -- Qais Yousef