Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2029871pxb; Fri, 29 Jan 2021 11:05:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJx2s80n3s+WJpnVjma2PEb1ZV3QinNJ1Qr4gh9ZZe9yIjCm0wF/iWrpfoYMZHuHoB6SNwsp X-Received: by 2002:a50:d90a:: with SMTP id t10mr7066465edj.162.1611947132951; Fri, 29 Jan 2021 11:05:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611947132; cv=none; d=google.com; s=arc-20160816; b=KGRbp00TsWGuf8K/mP1+PDsOpsqDaOdK05cX9OGDxVT1au1i+fkejIAKu1ArRQ7mLD RoyM/wjuIjKnFqHaS21KuhMy0PXS1RIYdeYH4hIOhYa+G8SfnH9SkaKeT3jpd7kbTuwx ylNYSl2Khaf5wU2GJ9OU+IrsNMf4Ho6uk40zF2ObI32TNplF2FtGkZuiYuERE+R5Z9PX /tAtGDw//b01oIHm/7nKhWTkduGhKMCttrx7st8b0JNqwGdi0Qzh+BBah+a/L12Ma3LN fw7lIouN7Di4vhYqeSOwklT2a0Zsrculhgkt2EW8TYysPCS9Z/fJV+jL1eit1qFZed3U cQvA== 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=GgOtgTdzPN4HUVdUQxSVYm/VfbB5b7QOuV0p9U9vM4w=; b=eOXaS5fD5giod777Ix3ot+SvX8oNMiUEYX2bMWwqTTS7AGm5fubtRZbSt3GFlu4G0t MqbUaqFkB8BCLhBKlSjWXJQBkhmDm1Tvl3OHt04J7RIBxp8z9+noNweGOBV7wdQYbgsq BkOw3t+cQQxzXA++BRbYZsvKGqbnxtK8SSpfnqp75pBGuz0TWBdidnFpXfk6+RlIW3Nl abj7nL+jiRG7wKBqFkulsBzVO2Zd6lP9Omus9PUfIdL1Rh/uKGDuTGtjuDvJmi9NKxrY 5YesgGcP1gbMOSl4/A/AkovU+Bhw9/ki75T6VSlfA7/2RbcFQOGu14NV5Ojn37V6LwXe fleQ== 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 f25si5198475ejc.384.2021.01.29.11.05.05; Fri, 29 Jan 2021 11:05:32 -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 S232875AbhA2TDZ (ORCPT + 99 others); Fri, 29 Jan 2021 14:03:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:50278 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232896AbhA2TCg (ORCPT ); Fri, 29 Jan 2021 14:02:36 -0500 Received: from gandalf.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 49AED64DE3; Fri, 29 Jan 2021 19:01:05 +0000 (UTC) Date: Fri, 29 Jan 2021 14:01:03 -0500 From: Steven Rostedt To: Peter Zijlstra Cc: Alexei Starovoitov , Masami Hiramatsu , Nikolay Borisov , LKML , Alexei Starovoitov , bpf , Josh Poimboeuf Subject: Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") Message-ID: <20210129140103.3ce971b7@gandalf.local.home> In-Reply-To: <20210129175943.GH8912@worktop.programming.kicks-ass.net> References: <20210128123842.c9e33949e62f504b84bfadf5@gmail.com> <20210129013452.njuh3fomws62m4rc@ast-mbp.dhcp.thefacebook.com> <20210129224011.81bcdb3eba1227c414e69e1f@kernel.org> <20210129105952.74dc8464@gandalf.local.home> <20210129162438.GC8912@worktop.programming.kicks-ass.net> <20210129175943.GH8912@worktop.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.8 (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 Fri, 29 Jan 2021 18:59:43 +0100 Peter Zijlstra wrote: > On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote: > > Same things apply to bpf side. We can statically prove safety for > > ftrace and kprobe attaching whereas to deal with NMI situation we > > have to use run-time checks for recursion prevention, etc. > > I have no idea what you're saying. You can attach to functions that are > called with random locks held, you can create kprobes in some very > sensitive places. > > What can you staticlly prove about that? I think the main difference is, if you attach a kprobe or ftrace function, you can theoretically analyze the location before you do the attachment. Does, the NMI context mean "in_nmi()" returns true? Because there's cases in ftrace callbacks where that is checked (like the stack tracer). And having ftrace return true for "in_nmi()" will break a lot of existing utilities. -- Steve