From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f10.google.com (mail-wm2-f10.google.com [74.125.225.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7BFCF4229C6 for ; Tue, 21 Jul 2026 19:44:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784663065; cv=none; b=hmr6+RUICRl79D6frjUHIBrbso7qKMKiJv8RKwgcfMrsy8EqFmjZCMh0S24c2UMAV1L5JT6Xe6LiRxipB7n4aVRS2DVQ17ahkIy0wmhYEtze23KJPi52gwT3+ciNhEh0D+FlfYuih453BI8ShDDmAYeNZ1iYZd5bhNno6Ppq+bI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784663065; c=relaxed/simple; bh=wNB9eaLGichIrF407lXC91sdLTgFfNTxKaTb73FP9AU=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=d6yOT6TzXdv3fkudAtzK5cjY/U0Ips4fxL0c0TTbMFYsduY9jIcLU8B/8DjkpuSSVLaFHk1MP0AfCJp7/uWrgyM120GL/8G/xjRuZZuthiZ54rsz7VsRtopV+V5nk2C5UVTmTIyM4riQap8nFW07Csm7UhAGONvsacQqdMFeZR0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DvhwsCHP; arc=none smtp.client-ip=74.125.225.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DvhwsCHP" Received: by mail-wm2-f10.google.com with SMTP id 5b1f17b1804b1-495473da596so1679925e9.1 for ; Tue, 21 Jul 2026 12:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784663062; x=1785267862; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=4TfZyNSsFF/kFGOiqlXhDm8eBgtcovpMS9Ai/8/zxBo=; b=DvhwsCHPJnpbbsS0TKN57PTPoDiYfSH+g3blUtA2zH2/1uGoMNzg/ghnjQ7JVULr6v FtrghUcG6Q1tXWje80K3IKw1sScp/iJsbPczYE/vd0uEwvimN5TjBaCOqz3M1NJUeleC mSeZY2LCqOu6TqV2fGYmIflPJUd45LTNt/0w7frozY3pHonq6y3fHSNfmLoioUCCvrqN 0JVEckkbpU3JgXeCjqOTQaHAyyEtuK35wm/6u3idrkdHJv0xFT7puhspGIZVg8vJNNEy ff0a1MYfAYfN7AQ4acd5JA6X6vEi4iuxEOJyKs07jHG1F37rJFNddvIQ8FB7Hr4WiOCg QuvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784663062; x=1785267862; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4TfZyNSsFF/kFGOiqlXhDm8eBgtcovpMS9Ai/8/zxBo=; b=fii8QThE5mCqczR2bC5ESPHjD+hn8wVEtgtBPjeaMXtRHcBfN9xtYjUCJg7SkwORNj Hh8GqKIDH3jCP+BuEuD48ZV4rooZpgPhZOCHziz/V+iEPRbIx0NJGBrjCSVSDb6Y0nv7 vyRASGE23NJSty3D0FPVbL6/XdyV6yduElNXZJR58WJeY3adWQv6ewDkYV9X6Za5E7Q5 mFCIduXpMd3SXF6uyb9HLrHfuZ2Z9FmTnbjYwXVMlFVzgwoAzXbRP6gTy92vWGNFpYqe Fb9E4r3nKXw9rAzkOAJIk+UovCNWv2J9A7kMG3OS+uhevi0ju+aa2ILFybZvqQ8Yb3/Z JtHw== X-Forwarded-Encrypted: i=1; AHgh+Ro54SjOea3Crbzk07Zm1ijy+66vObCZyxXwt/8Q7hO4FTsIKIKBFq+JSgn9Ro7UQ5LDw9ZFsu2W32SV1rs=@vger.kernel.org X-Gm-Message-State: AOJu0YwhSjDh3EePk8cnPQqYzwqPM4xj2oLz0YUAmiuULAc3CoUfjf0I K4YaWX8x51iYlWvaSAGvmlEjxMFeuG+FR4jQcmKnMMALpk4aIGo88Ah3 X-Gm-Gg: AfdE7clFJcteQFGb2dO/KJw2N4ior+VMgvDyMTYOSKZQgNe7BbInwBiSdW7mIkc1ZpM Z+DIqR7SSXDCTU1TFuPtbIrcj8n/G9dzrDa9qsLQTPe/TLCrqROY3niMDdAXrCnptfGORlj1Cy0 wGIlTYYqMR3N56/MjhD3BAiRFik3bXefP+ZRCSD2ZqWzfcD3JuRe0G0TFSfH3O2McSiqfCuZLfA pf/tqYMj420FzSQT+HAHqodUmQZFvKnrxrD7E1FzLzYmCMG3Uxkb2mJkdS6TsvhG385B80z/Pnk kRWuYwL7+bOJLZxneBULmXEUUzIIwoo7jj1xdvpC2fLLDQlzp804K5XoEbwu10BSWqegdhlOon6 e84n5g+dLmn9P1YQp1/oPDEVQajZTJ8xrusLw0BatjedqjkGRjGIF7LFB/105aw90Bj17kpW5Ld 0gorOqtVRo+KM1YB8+GOZLkGpQue+F5M76h4ob5mDCsgYnxQnfss1h3yzO42R++Ywc0OAdUyNwX ajBLvkULfHNRV6k+0VioO1Erqq7+hrlWKsdkip+u8AX X-Received: by 2002:a05:600d:8449:b0:495:6022:5a23 with SMTP id 5b1f17b1804b1-4956a51d5c4mr13525275e9.19.1784663061533; Tue, 21 Jul 2026 12:44:21 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49565373200sm85700775e9.5.2026.07.21.12.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2026 12:44:21 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 21 Jul 2026 21:44:20 +0200 Message-Id: Cc: "Lai Jiangshan" , "Paul E. McKenney" , "Josh Triplett" , "Masami Hiramatsu" , "Oleg Nesterov" , "Arnaldo Carvalho de Melo" , "Namhyung Kim" , "Alexei Starovoitov" , "Andrii Nakryiko" , "Steven Rostedt" , "Mathieu Desnoyers" , "Mark Rutland" , "Alexander Shishkin" , "Jiri Olsa" , "Ian Rogers" , "Adrian Hunter" , "James Clark" , , , , , Subject: Re: [PATCH bpf-next 2/2] uprobes: Switch uretprobes_srcu to SRCU-fast-updown From: "Kumar Kartikeya Dwivedi" To: "Andrii Nakryiko" , "Puranjay Mohan" , "Peter Zijlstra" , "Ingo Molnar" X-Mailer: aerc 0.21.0 References: <20260706172744.3920417-1-puranjay@kernel.org> <20260706172744.3920417-3-puranjay@kernel.org> In-Reply-To: On Fri Jul 10, 2026 at 11:23 PM CEST, Andrii Nakryiko wrote: > On Mon, Jul 6, 2026 at 10:28=E2=80=AFAM Puranjay Mohan wrote: >> >> uretprobes_srcu currently uses normal SRCU, which issues >> two smp_mb() per read lock/unlock pair. This overhead is >> paid on every uretprobe hit. >> >> Switch to SRCU-fast-updown, which eliminates the per-reader >> memory barriers by moving the ordering cost to the >> grace-period side (synchronize_rcu() instead of smp_mb()). >> This is acceptable because grace periods (uprobe >> unregistration) are infrequent compared to reader-side >> uretprobe hits. >> >> The updown flavor is required because the SRCU read lock is >> taken in prepare_uretprobe() when a return instance is >> created and is held until that return instance is finalized. >> The traced thread returns to user space in between, so the >> lock is inherently released in a different context from >> where it was acquired: on the normal return path via >> uprobe_handle_trampoline() -> hprobe_finalize(), or from >> ri_timer() (expiry) or dup_utask() (fork) via >> hprobe_expire(). srcu_down_read_fast() / srcu_up_read_fast() >> are designed for this acquire-here / release-elsewhere >> pattern and, unlike the same-context srcu_read_lock_fast() >> variant, do not carry the lockdep read-side tracking that >> would warn on it. >> >> The short, same-context SRCU sections in ri_timer() and >> dup_utask() (which guard the uprobe against reuse across the >> hprobe_expire() cmpxchg) instead use guard(srcu_fast_updown) >> for proper lockdep coverage. >> >> Signed-off-by: Puranjay Mohan >> --- >> include/linux/uprobes.h | 5 +++-- >> kernel/events/uprobes.c | 29 +++++++++++++++++------------ >> 2 files changed, 20 insertions(+), 14 deletions(-) >> > > Very straightforward replacement and will improve performance, thanks! > LGTM. Peter or Mingo, I assume you guys will want to route this > through your tip tree, right? > > Acked-by: Andrii Nakryiko > Hi Peter, Ingo, Gentle ping for this. > [...]