Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp294537pxb; Wed, 3 Feb 2021 05:56:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJwSP/OiVxvZZ3AfgeRbZRNrC6+GHEFeSiW6DlADUdleSDP7Ehz72vHAYt4RaN6ogu6f287C X-Received: by 2002:a17:907:75c6:: with SMTP id jl6mr3160232ejc.243.1612360613264; Wed, 03 Feb 2021 05:56:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612360613; cv=none; d=google.com; s=arc-20160816; b=THZpN+95p8JyP4YBXA+3vxzpdyeBXrxhAx6BWuntDyb2V0g9MCn5v9mRtVTRKnz+Nx /ACG23aipQQpkzDbc87JEbrKFTEU5T8IWKaxVdihMcTYiMp9Wauw/Ben8LGzvCjhZgaV 4HoNqvFktgRnH4+StiMfhsr+g8FjQK/nBHwwbfe8ABJPztNpmplrAYjxeF75Dxizw9XN DFXjQZLdwyZWr464yH7KdZZrbpY14RAM5aOg5tFOi9T/pQVYM+kNROaGI6eJgldd45Rh aI2tpW+qeZrNm2YyNxEdIoi7uG/CvIGzp5cwi+2wBQ4Smdss2vSzX4YHPqbR1qlOMjvd /9pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=9pnNbQG+SeJ847o5O/GPwncv/pzu0L73zIW2ObUEA90=; b=NExyFdke3f2lzdvi/Mlo/txjbnU+KMoTgHXR6Gw0YctCtmlQG84tajlGCcgZu+3GHV TuwOP6hggEuVn3CCe3tudbX5Pxejr3mrzwk9fjYxVHrTc0M1P2HZoAWmoPol6iE6Bstr a/CPxekibSAlwnmcIE/65bgXLwgp5N+qtZLrBpySo9ULO1unuW4MWAiOxK5CvtFGBpAO DfawddOki2sgRXIJfXhPZxnp37pOHYxVtgVjp1BUHe79odQV+2WUFvRC75Svjhi2YS+v mcaSGT8PreXrV4/hFfw6jPSGbyl9ACHyliVjz7/IQyogHegOUQ/KoxQxD1ndDIa8BgeM cumw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y14si1348344edc.349.2021.02.03.05.56.28; Wed, 03 Feb 2021 05:56:53 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232477AbhBCNyG (ORCPT + 99 others); Wed, 3 Feb 2021 08:54:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:51338 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232361AbhBCNxQ (ORCPT ); Wed, 3 Feb 2021 08:53:16 -0500 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 14FDF64DDA; Wed, 3 Feb 2021 13:52:33 +0000 (UTC) Date: Wed, 3 Feb 2021 08:52:32 -0500 From: Steven Rostedt To: Masami Hiramatsu Cc: Peter Zijlstra , Alexei Starovoitov , Nikolay Borisov , LKML , Alexei Starovoitov , bpf , Josh Poimboeuf Subject: Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") Message-ID: <20210203085232.402e2e35@oasis.local.home> In-Reply-To: <20210203223328.9e99548d19d482ac2e2cda81@kernel.org> References: <20210129175943.GH8912@worktop.programming.kicks-ass.net> <20210129140103.3ce971b7@gandalf.local.home> <20210129162454.293523c6@gandalf.local.home> <20210130074410.6384c2e2@oasis.local.home> <20210202095249.5abd6780@gandalf.local.home> <20210202115623.08e8164d@gandalf.local.home> <20210202160513.38ada3a7@gandalf.local.home> <20210203223328.9e99548d19d482ac2e2cda81@kernel.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Feb 2021 22:33:28 +0900 Masami Hiramatsu wrote: > Ah, that is what I worried about. ftrace and kprobes handler usually want to > know "what is the actual status of the system where the probe hits". > > If the new kernel_exception_enter() for ftrace/kprobes or any other kernel > instrumention does > > __preempt_count_add(KEX_OFFSET + NMI_OFFSET + HARDIRQ_OFFSET); > > And we can distinguish the KEX from NMI, and get the original status of the context. > What would you think about? Oh, that reminds me about the obvious difference between an NMI and a ftrace handler. A ftrace handler doesn't disable interrupts nor preemption. Thus, if you set "in_nmi" to a ftrace handler, and an interrupt (or NMI) comes in, then any ftrace handlers called by the interrupt / NMI will be ignored, since it will think it is recursing from NMI context. -- Steve