From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD561D3ABD8 for ; Mon, 11 Nov 2024 17:49:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 711F66B0096; Mon, 11 Nov 2024 12:49:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C0DB6B0098; Mon, 11 Nov 2024 12:49:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5615E6B0099; Mon, 11 Nov 2024 12:49:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 313476B0096 for ; Mon, 11 Nov 2024 12:49:46 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D40C2AD8BE for ; Mon, 11 Nov 2024 17:49:45 +0000 (UTC) X-FDA: 82774550376.25.74D36EC Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf04.hostedemail.com (Postfix) with ESMTP id 69C324001E for ; Mon, 11 Nov 2024 17:48:52 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ae0UQ1zi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731347209; a=rsa-sha256; cv=none; b=Fsroz+d7ZQyQJZhiHNv0RYAUePEvhko11yTCIjvIypeLeRKbHNm5fRCkI2lYWirN+PtxFQ ehclIxEuMdKakQ5PigIJeUVYDxTs5657UFQxwWtHRzvLZKPmEkyWjdqGpktOr7Oh//0ACb 5/lFofcmfVJ+mErkbSD0QVMb6U3cj60= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ae0UQ1zi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731347209; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zll8ldXQZW9waQ7dwCuyoXvWN+LSXFNQJtpkHY+2pVo=; b=MQetjSuzv2OMc0Pc5hQglycv2x0dYECOj5r+mw2n/r6McPLqH4JTDvgvA0KPtEredH42hB hcJ3ZdR4uIV3ZJTEUFVNvo6Uew5rXzacnoJcVzAhskE1U9l7SOmRf5stpDBL+sLrepqFiP GN+Xiy1UMD4rtkSGZJn7sMd7SyxjPMI= Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-20c805a0753so45443165ad.0 for ; Mon, 11 Nov 2024 09:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731347383; x=1731952183; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zll8ldXQZW9waQ7dwCuyoXvWN+LSXFNQJtpkHY+2pVo=; b=Ae0UQ1ziNb8c3WUR0XgIvMXDzqiCQLXIdKdLFcGBnmU2zLSr9aavmBqAN3FDLuuWFm 8j+FFtpvfBVWBOI0iBDO9IGkalRsnlYHEZ6/iElCq2Dxg4m4LD0v4maI4v5d8y6//O1G 1tJXncDr5eaG5kWebTMKyklkCt3ZynzX0lt4Ou/YHZCIDOXMk/FKspu7ZHtAcorDAape Vpt2z/euVwb/GYxXmDfg6wHb5AbXiZf+Ew2+Bs4vOoU1v7HRlPVO4TrsPvOsaJvEJHg4 kDYCQ/OkeECJlMtGOlcAFswoZeg5gOTiTReb5x6SMN+/HUOq38rxdSKNDr1g+pCP8Y/D sMLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731347383; x=1731952183; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zll8ldXQZW9waQ7dwCuyoXvWN+LSXFNQJtpkHY+2pVo=; b=nls5OVInJtRiFyPvFinFxMwngf6IIBgtVVw9PlCP6VSbnT4zfFTU1sIM4KQNhogeNv gMy/BD4kyZj4nbX45XyFUU+ZpGBVq8/0s4d+UVNbTUr265+lL/1zMpRqiDhxj75I/Sef cI8d7lIoZNLp2hzFYnAxFxhTk3OdeDeT0znYd+YN9mKyKLCrei2ZTFEbcPe0hjEl6ESy X0XgkfRsVus9PRqntMPM5i7ZCbA/hNXMvMN8LooYXsiDXv6II61NKyZ/57vf6baqFmrA gewVHr9c7n1MOZ+30Cs9pddtgZfmJVFOudqeolyJzZXC6kn/T52ny82Thrl2CmOGFsZB QSPw== X-Forwarded-Encrypted: i=1; AJvYcCWCHw/TyXtOJWbXlDupWtHjQXwVZZCBmnhCy1lOgi6jduDoL5urUsLj54lIbrLrA3QZPgg6DDo/Aw==@kvack.org X-Gm-Message-State: AOJu0YxQKifpBeCqfO1HqFk18EkqiCYpWWLkdB6Ys04JyrSMj3RrWNMP PQkRfE8aM3drvdPpbn7qSGK2mgxDMFdKfop41k/A/wMGhvyhYDTCGA35ceCM8QE9aXiyk8ztATc xPYkT7DslTgb7VA915r+LJ1HkleQ= X-Google-Smtp-Source: AGHT+IFjhI+Su5HVqTQd1FHPmPjFyvtaz/5qqN+MvZdcq6vQBsNi62OM4QBT4nvmT7Qylj7UBUb/FAFCyEqpgXTwF4A= X-Received: by 2002:a17:903:244c:b0:20d:345a:9641 with SMTP id d9443c01a7336-21183d63de0mr186227605ad.27.1731347382653; Mon, 11 Nov 2024 09:49:42 -0800 (PST) MIME-Version: 1.0 References: <20240829174232.3133883-1-andrii@kernel.org> <20240829174232.3133883-10-andrii@kernel.org> <20241111055146.GA1458936@google.com> In-Reply-To: <20241111055146.GA1458936@google.com> From: Andrii Nakryiko Date: Mon, 11 Nov 2024 09:49:30 -0800 Message-ID: Subject: Re: [PATCH v7 bpf-next 09/10] bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers To: Sergey Senozhatsky Cc: Andrii Nakryiko , bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, adobriyan@gmail.com, shakeel.butt@linux.dev, hannes@cmpxchg.org, ak@linux.intel.com, osandov@osandov.com, song@kernel.org, jannh@google.com, linux-fsdevel@vger.kernel.org, willy@infradead.org, Eduard Zingerman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: f8h6obs648j6p3iatnr8tp4788psa5cm X-Rspamd-Queue-Id: 69C324001E X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731347332-90378 X-HE-Meta: U2FsdGVkX19VcpfogjcL2wjKvV7nL7obre1VDr3pFzIjyyhbHH3Bu+lswyeobb/h10kODIeq9CxEEb+pI3J8CppE0G1wrIwbh9e3N2OOK5eIUJMpSPFY3SVBlEbZ4RoE/65jb0Bhq1wloSDdrsCLyz7R661BO14Cu1O87OWAKoj0Jl+ZP/3cjgfzWlY/6RLZia1cM3WfsuO1qVu3Gq0uTUN3D62AlI/++/4AaXOa4IxGvpYn7+rNvOOGqjYyy/6V5UKc4P6aNalW1IYWW7bNF96ih8kbZPP9kasKpR00RJHwX5fG9hKJHFOtoUOJnCk12LHGyORod7eMxm5ecrP+rceSyLcQfYZm7P8SeKcFLKhGyigfcGcu+rn0O1wFmsR6XO8KbBHza8bMxNtaZkOBO9PBkW+sZNXfhGSmGtA2O7zAa1JSzUYXyQNCh8UWlRXYFisjQ+FAhIAtBSzKLGdhomxfDvlcPc2rIxsM5At+t06F/ckFMsZndYHnEW0EKQFSRuwKzFLV+l8UM+HEnqAUp2QHoVGIU3/1j2wEusivEWGm2sbcahTjSxM/ZTHIYXdPi7Zs/JqssVSQDqSHJGYpx35mTFqcBQrF1+aiDALwbl+S0imwFoOODiXjYHoDGAZXl1T14koD+cQt0VRnK44j60CFKZkMxnmK/e40hrokpw05wfc6jBOMVA3zGmwjIe2if9Gxl9N98tS6PpCqKgujFaNXMwWFuqpIkpCuph2uVW5dfwbVkung0/t/nkiV7HbJyyh3RFVKNXCVayRrIufz5mY2Dy8yQqX7etVOfl089DwnwV1gNqC63uhB56x8adQJtAqisJReBrPwYXf9qYIkoTPqEse1u89vKFp5LCDsu5UP9zoxT55bq/VWp2r9TBeRcSeg8JJileIVjqBeq3LTjjFskWSDyqoa7YTOiNEEh3VdFLdPlFsLKHEcrTxsRScSfeGIlWuRy2p8AMJ1Sam 4MQ2VKPy qbTRpda1SSegkNiplOEJAZkqbddYWagl/fVuR+XnzZHxxdjoPcpz1ALPMuGN3P78m4xI/xLIw+7wL5QHWDLTWfGOr3xRRNvxdYIFaukpsuXr9IlQnT9N8fLuMspi4CvB4PGnELcE2U6KbUSCaE5b7wLXipk5tK3RCaBqSpjzAJE3HvqSA8FXBbox01iTjPka78p674K0XfFT278rSg0g8NYS5tpQQ6o44a/w5Z2yhgb0/Mdn/vjTq0qQ6dG0fn41rPfZOahTVXed7fohoP8pasA35UMhGgxJ/SWxotFBX8PpMH7S1SUD0UNL9wuUVnwN8lMfUKwUVya64m4t0LwRG6vVGVZBMQ9GD34Mk961XWrO4/mOBVpAS2wPsnzKo7UNJBT6AJHh3LIvqx8lOSgVoe6wwsF5EO9n9EDlx9yQ/XpmyuVo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000420, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, Nov 10, 2024 at 9:51=E2=80=AFPM Sergey Senozhatsky wrote: > > Hi, > > On (24/08/29 10:42), Andrii Nakryiko wrote: > > Now that build ID related internals in kernel/bpf/stackmap.c can be use= d > > both in sleepable and non-sleepable contexts, we need to add additional > > rcu_read_lock()/rcu_read_unlock() protection around fetching > > perf_callchain_entry, but with the refactoring in previous commit it's > > now pretty straightforward. We make sure to do rcu_read_unlock (in > > sleepable mode only) right before stack_map_get_build_id_offset() call > > which can sleep. By that time we don't have any more use of > > perf_callchain_entry. > > Shouldn't this be backported to stable kernels? It seems that those stil= l > do suspicious-RCU deference: > > __bpf_get_stack() > get_perf_callchain() > perf_callchain_user() > perf_get_guest_cbs() Do you see this issue in practice or have some repro? __bpf_get_stack() shouldn't be callable from sleepable BPF programs until my patch set, so I don't think there is anything to be backported. But maybe I'm missing something, which is why I'm asking whether this is a conclusion drawn from source code analysis, or there was actually a report somewhere.