From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.127.231.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793191926; b=A7ehLpQQ4wpV5T8GEF9bf5XH+5PXlJjC3Z4EH6IiPq8y2aCzZOmDotzhNuWfK1noAqHr J9blgB2BkCd9z32tHvW5KcpvaNpf4Nxfjl/3Y4eeHNOL1lQ1JX7OaBK6LfIYiOe+XDpdR /TC4NMuMEnQ6orslKT06eCVY7zpcSOijwRTJXxLl/hLTCn0JIsbTfY/elbBpLuB54AfpB h1hAJDqdWj0BIVfp5FT7vLJB06BvgggFMJvjVM3jJkC+vr8IWv8xtIQPJy+YJ+qgfkvkR 8V2+6I6cb6TYX7JZRSe/4ADIb/5VB1odRFg2fVFCKe65POKMaAxO/uHvYrpJwvw30qg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793191926; h=DMARC-Filter:DKIM-Signature:Message-Id:Content-Type:Subject: X-Original-From:Cc:Content-Transfer-Encoding:X-Mailer:References: In-Reply-To:Received:To:From:Date:Mime-Version:X-Lms-Return-Path; bh=ruJcFMq+T+PYshOYgwUo5k4oqvbhd5wL7JLOkO0njoo=; b=eLn98hDfpuGCiiokr3yK6Hl7VRASNDbn8IVaQCeI1L0xIsaidsNcZVFdJ2O0XoYV05NE jAScqJ7pC+4Xv8FQA+I1JoLKsbLdH4eYFesIhazCiQADi6SoG3BgfFhcQwNkkMpb06rr3 sL1nR6EHnz3ul1c87EMvuxfkEfOJxsaZwDsXmS+gwaHtaLJz0vDACYW5ctWbJ94DTzs7c YhioE6Ux8vMXjJU/RBOz3TSZoO4YvZWN+jpk8w9CYo6wLN7Piqcg0HSPyyKh+IAj9cnK+ 9FBDibf3Kzo0k6cZDacjujLLtnRDT4CSqZOokGs0OU5kl6ItleXPZzrnjo2kY7RK3Xw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=insta360.com; spf=pass smtp.mailfrom=insta360.com; dkim=pass header.d=insta360.com header.i=@insta360.com header.a=rsa-sha256 header.s=feishu2606151854 header.b=q2WpuNEn; arc=none smtp.remote-ip=209.127.231.18 Received: from va-2-18.ptr.blmpb.com (va-2-18.ptr.blmpb.com [209.127.231.18]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0317606A334 for ; Wed, 28 Oct 2026 12:52:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org D0317606A334 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=insta360.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=insta360.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=insta360.com header.i=@insta360.com header.a=rsa-sha256 header.s=feishu2606151854 header.b=q2WpuNEn DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2606151854; d=insta360.com; t=1793191917; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=ruJcFMq+T+PYshOYgwUo5k4oqvbhd5wL7JLOkO0njoo=; b=q2WpuNEnardC3QCL0XlIgUTNG849iFNdxmtXxDCnkbehfuy6pzCMr+l/asWPKvhvdcTN+o /2xQOuIcOC+Vkp2bjqVy2OsE/YCKYVBOBDFO0bC5o9zFOPbfnsA4w8OaoS11F3tjW4o6Tw otJYc68qhRLqapRdTBYWAFY902QG6nhtZY2fh2xPN7M49yrSUL8hEty2JwdOKV03DRsv3U pkDiAg/BRwn8+mJntQstJUX+WOToWsLaOEiL88zBda/KvG4JU1o/9nfwZJPuDtjLzMf29A RefFgTFIc6ioaglfhzkI0qyTmihOIjlwPO8kBhls528VNMn1CqrjqcRxiA2aCQ== Message-Id: <20261028125148.1348-1-yangsongsen@insta360.com> Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH bpf-next] bpf: Fix suspicious RCU usage for sleepable bpf_get_stack() X-Original-From: Songsen Yang Cc: , , , , , , , , , , , , , , , , , Content-Transfer-Encoding: 7bit X-Mailer: git-send-email 2.53.0.windows.2 References: <20261028093548.790977-1-yangfeng59949@163.com> In-Reply-To: <20261028093548.790977-1-yangfeng59949@163.com> Received: from DT-9806 ([61.241.19.90]) by smtp.feishu.cn with ESMTPS; Wed, 28 Oct 2026 20:51:54 +0800 To: "Feng Yang" From: "Songsen Yang" Date: Wed, 28 Oct 2026 20:51:47 +0800 X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 X-Lms-Return-Path: On Wed, Oct 28, 2026 at 05:35:48PM +0800, Feng Yang wrote: > Sleepable BPF programs run under rcu_read_lock_trace(), not classic RCU. > bpf_get_stack() relies on the caller holding a classic RCU read lock: > get_perf_callchain() -> get_callchain_entry() dereferences > callchain_cpus_entries, and the returned entry is read until > callchain_store(). __bpf_get_stack() takes that lock only for the > sleepable variant, i.e. when may_fault is true. Hi Feng, I hit the same root cause independently via syzbot and sent a fix a few hours after yours, without having seen this patch -- sorry for the overlap: https://lore.kernel.org/bpf/20261028121859.994-1-yangsongsen@insta360.com/ It also covers the syzbot report for BPF_PROG_TYPE_SYSCALL programs (always sleepable, run via bpf_prog_test_run_syscall() under rcu_read_lock_trace() only), which reach bpf_get_stack_raw_tp() through tracing_prog_func_proto(): https://syzkaller.appspot.com/bug?extid=72a43cdb78469f7fbad1 The approach is different: instead of routing sleepable programs to new sleepable protos, it simply takes rcu_read_lock() unconditionally in __bpf_get_stack() around get_perf_callchain()/callchain_store(), as Andrii suggested earlier that an extra nested rcu_read_lock() is harmless: https://lore.kernel.org/all/CAEf4BzYN33yQhO-tsF8pUWDMZoiLAXkV+Z1oP6fJkByocYcjpw@mail.gmail.com/ That is a 3+/6- change in kernel/bpf/stackmap.c, it covers every caller of __bpf_get_stack() (including the tracepoint, raw_tp, iter and syscall cases listed above), and since no helper gains might_sleep it does not hold the per-CPU bpf_raw_tp_regs slot across a possible sleep in callchain_finalize(), which is the issue the Sashiko review raised here. It does not do what your patch additionally does, i.e. allow BPF_F_USER_BUILD_ID to fault in build IDs from these program types. I'm happy to go with whichever the maintainers prefer, or to drop mine. Thanks, Songsen