From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FF8B2C11D1 for ; Tue, 4 Nov 2025 11:22:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762255345; cv=none; b=TnRV0h+IQysA5a3u761vpu7ceAMDceNdPatBp4q7OfnZ/xBZctL12/whxx/wIvu+4Oz128Xi2uuZiFnlfQipeM+jBHe3NQV9Oat/2SFsyc/hSBUV23R0ZZ6f9+03YcC+wuohIWAh+4JAPdfoBrhove2QE5Mrv9x6+wHnCf6q8Q0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762255345; c=relaxed/simple; bh=50x9iL/Y/BljBKuXl4bSN56iD5/TTDcB13FlDryEG7c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hKvTVyQ957RzmKxCVZm6/R0KbjjOaVqn2J2zaTMmUWYqAQemq/TMV3kBgqu28NOo6/jov6o9OCTtmu4w4xcjnZ8Rk7b261ZqYVipo0GGhl7Zi53R+dizSKkOQeJLY4q8+2sshB+UZGt1TB2OMhTtpWKwafeBEMIfpFoCfQjuCUc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GGtnNCN/; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GGtnNCN/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762255342; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QOiwR+3npBDpnhOAXG48/ro8cjEOatu32+L6Iae+fU8=; b=GGtnNCN/b3Lj2VRloJ9d6LXZKXITHCMXXeIoKVHU1RtMMV7SPzc8jaxL14qpCJ4AXe0Ohm cuDyZq/W2265BlgieOopsk42PZhiV49z8/4NAo15KXuwQtw29KNmdqS+UJRtd4J04lYKX7 KRfZjNWNXvFX1DZBdJzMZvE7Jp9GVBQ= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-390-OX-uAnzuNrOrXdiqog2IIA-1; Tue, 04 Nov 2025 06:22:17 -0500 X-MC-Unique: OX-uAnzuNrOrXdiqog2IIA-1 X-Mimecast-MFC-AGG-ID: OX-uAnzuNrOrXdiqog2IIA_1762255334 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6596818002C1; Tue, 4 Nov 2025 11:22:13 +0000 (UTC) Received: from fweimer-oldenburg.csb.redhat.com (unknown [10.44.33.172]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B895630001A1; Tue, 4 Nov 2025 11:22:04 +0000 (UTC) From: Florian Weimer To: Peter Zijlstra Cc: Jens Remus , Steven Rostedt , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Masami Hiramatsu , Mathieu Desnoyers , Josh Poimboeuf , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Sam James , Kees Cook , Carlos O'Donell , Heiko Carstens , Vasily Gorbik Subject: Re: [PATCH v16 0/4] perf: Support the deferred unwinding infrastructure In-Reply-To: <20251024145156.GM4068168@noisy.programming.kicks-ass.net> (Peter Zijlstra's message of "Fri, 24 Oct 2025 16:51:56 +0200") References: <20251007214008.080852573@kernel.org> <20251023150002.GR4067720@noisy.programming.kicks-ass.net> <20251024092926.GI4068168@noisy.programming.kicks-ass.net> <20251024104119.GJ4068168@noisy.programming.kicks-ass.net> <20251024140815.GE3245006@noisy.programming.kicks-ass.net> <20251024145156.GM4068168@noisy.programming.kicks-ass.net> Date: Tue, 04 Nov 2025 12:22:01 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 * Peter Zijlstra: > +/* > + * Heuristic-based check if uprobe is installed at the function entry. > + * > + * Under assumption of user code being compiled with frame pointers, > + * `push %rbp/%ebp` is a good indicator that we indeed are. > + * > + * Similarly, `endbr64` (assuming 64-bit mode) is also a common pattern. > + * If we get this wrong, captured stack trace might have one extra bogus > + * entry, but the rest of stack trace will still be meaningful. > + */ > +bool is_uprobe_at_func_entry(struct pt_regs *regs) Is this specifically for uprobes? Wouldn't it make sense to tell the kernel when the uprobe is installed whether the frame pointer has been set up at this point? Userspace can typically figure this out easily enough (it's not much more difficult to find the address of the function). Thanks, Florian