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 B0938D41D41 for ; Tue, 12 Nov 2024 01:29:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E8B36B00B1; Mon, 11 Nov 2024 20:29:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24CAC6B00E9; Mon, 11 Nov 2024 20:29:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C4E26B00EB; Mon, 11 Nov 2024 20:29:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B996C6B00E9 for ; Mon, 11 Nov 2024 20:29:50 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6C936C1B8A for ; Tue, 12 Nov 2024 01:29:50 +0000 (UTC) X-FDA: 82775709240.01.74B2FFE Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf27.hostedemail.com (Postfix) with ESMTP id 7DEF240009 for ; Tue, 12 Nov 2024 01:29:06 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K883+aWl; spf=pass (imf27.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.173 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731374934; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=unMes6tk+yAGpxvui8SQySSJdgFoHnSMIQwrPN8JKpM=; b=SxAyqYK3pjnxNmwartBwZao77KCMCsFtWH2uNfqSzm6b4hhEuWYlDhsLoc1h9OJm/9PB80 rHgl3cM08hY2qlbxJb/TNF+l5hCZSR3K1dfHx/ci0xND3YYrhDYgCw5Q4Ca5HlzQePr1mA uNFK1vA9NGrwVRs/CSLHz6yD4aDmt28= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731374934; a=rsa-sha256; cv=none; b=R1e6l1PAmBy41aWCyUqQQrugo5+StFH0AYkKuNrze8o0UB+o4l8rfFi7AytH84ZRlmbSY0 Hjn4qty9RdLP0HZzyKdFnl9w4BfobqzBAL0+/qNfw5H14S7uwfkwcJArkIGZxekCWHCStN cJzqRiPxHM9SV6sDqlH/B5BsJjSoynU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K883+aWl; spf=pass (imf27.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.173 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-7205b6f51f3so4084701b3a.1 for ; Mon, 11 Nov 2024 17:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1731374987; x=1731979787; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=unMes6tk+yAGpxvui8SQySSJdgFoHnSMIQwrPN8JKpM=; b=K883+aWljSUozBw4KLOR/fYeYK3u6dpOevipk4SI2PxSgKVJ/7krluA83/BK3eyrK8 SVjj49FEbYBcKdMR07oWf3+K4LEO+VGa4wzjTLo6v6jGmoOm1U8H55seH89Q2aU5YRqD 9c1CekKpLJB6KeyQoiyDCAPQpo5eWRuAA7vAQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731374987; x=1731979787; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=unMes6tk+yAGpxvui8SQySSJdgFoHnSMIQwrPN8JKpM=; b=K7X8mZ9POVdQCTl2z/gu3ABQjZDro7Rzqkelte6Ddq/uGvfj9l61QxaEzaZlH4DiIH rmpI2DTxlX6Kui5NTW1KQ4nLhVEJ7KtrgFH4sOYxhfdxefa3u5x1WD7jrSXli6IOvTFT BgDwr/FAdN9Z1GG7LLYFwdewGBlLbDHfaHcvQ+BV5vqFw1jVR+DZhjaicfnUE+EUBz4R 4lx9C9+Nbmy2qmaNm6cjGyMiK8oaT6AaNPUngFliUEdk3VUE4w6ss9+dAkUkGisTf/CT oAIMY3qUTr72sAiV5n9rDnQKGe5P/+9TMpzBpidazx9ZCpdeLVSW5tcHxfHcl2ZpsR5U Z8lg== X-Forwarded-Encrypted: i=1; AJvYcCXj2dBlOUCPCLCHaHCPO9kmk3/ZzrVT/HMcJa3cYvEJcTjJk9tAONbxkbfpQvwUwComzSHm9MmyRQ==@kvack.org X-Gm-Message-State: AOJu0Yx5jBEzTRIbGXAsuG0G9+LvShLg1ZH0d/NL+XgwMx+NmHfJAwFf R0Ju1KT0oT9YqKoczxS1NJ69D5LyDbMtvIpseDj12j9nJTj1gAR+6kA+3W9JYA== X-Google-Smtp-Source: AGHT+IF1Dmx7codECfSiIexmKZDkdrD7kqBfP8QQ6WUWW43AnX7ZXdcoXYQtfAUKOWms8jZxU6Dykw== X-Received: by 2002:a05:6a21:205:b0:1db:ec2b:7322 with SMTP id adf61e73a8af0-1dc22b8c05cmr10818183637.46.1731374987152; Mon, 11 Nov 2024 17:29:47 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:a43c:b34:8b29:4f8]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-724078a7f22sm9820976b3a.56.2024.11.11.17.29.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2024 17:29:46 -0800 (PST) Date: Tue, 12 Nov 2024 10:29:41 +0900 From: Sergey Senozhatsky To: Andrii Nakryiko Cc: Sergey Senozhatsky , 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 Subject: Re: [PATCH v7 bpf-next 09/10] bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers Message-ID: <20241112012941.GC1458936@google.com> References: <20240829174232.3133883-1-andrii@kernel.org> <20240829174232.3133883-10-andrii@kernel.org> <20241111055146.GA1458936@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 7nhzghcjruhs7btcbbqbenzrkjrj6iyj X-Rspam-User: X-Rspamd-Queue-Id: 7DEF240009 X-Rspamd-Server: rspam02 X-HE-Tag: 1731374946-510223 X-HE-Meta: U2FsdGVkX18VSe1s8JocdrrgU5qk7iaBOu8jDpFzeqoPnTd7fpPpEH9yW+1u+8Dn9JAnHyrJ1mXwovLF9qXQRHg2xdwl2KJwUocdink4F0PndZ4WLQc9/+83tciyUYRAkq6tHG34nLRqqKLuWe6+7GSLRGA+d1vE+Kf+7EOeSgytRILI6lBkZ6pL1487MJCgBzGnl1weYzacUMflfGHSCsk/MhAPtEXDrJLIlu0VVDPBaBug6uqltreuE0IcKbllb0oV35t//zwIQNIUCphtqwJ1i8fT5yht5VCjEyW5s4K1TJSHSDkhdMk9xQxbJ/tvERnjqZkTGCAjBYTT3ab7rD2wNG3N5Zgs/YoBW18x9Wbj7TpZhZZ7JFtVrkjqNupNz6rCKCro75T9HDkPYLgNCNJ4ZTcrlYyT0GTB/s0GnVUsCevbQ/Dqoj/Da/ucYGtg7RPY/8KTAgDYhVwsP25q3kJLcPtnnSUm+DLZwJN/6ef/lq2jhUeO+i9nZ8Oz1q/F8Zx2nLUIG/0WXPOjEK8S/l0T89hJSODXnaM7h2uIWRxsFjFKUMflLlN8oSWjYWod9zYK3+Qn2c+QmaAwlKsh9/u1f7ZU3BFQUlBOzHyhUifjf7N/C9fuYR8j/LMLKjAqpiHpvy1wHM7QPNwLZlqS49eQ/KTzGrmtYlBW4vh/LJw+n7QGWLpyon2B37mz/tuzVVLW4KQxbg5uZpVTM9LXfOC27UymIY4hwGbqgHcLtvafxsv4niAsQkDRZbT/RQJxjDSzPaWeVp1u4C+1sBpAdH+0aMt7d/ku8Pt0OF9juqaiYGKNmMxBtiVZbSwx2s8Pe34Qlw67mT/OZ8wNku//Yr7OMC2zP4QVGV2MbAhiE5umWtOcKvnfkJVx7xxd/K7zkX+ZyIfBSKcLHDgUPFza3LnqFKnnZE50qUfgXueZxjzhx8nqwfGICOOy3WZW/aXxEP/wIX343EF3TlA5Jia 6/5y1yqc vvDZ0KN6LH0ZDzXamVY++RTqkSYvrvYey8KNl+BNF0Eu1bM154sMBHg3j4pPjaWsa9T+7d5QmwRzCLU41bhRjtqf/QHqScjveZYGFHtzJG+McBNJDJlBuaCV2CHfgpcsvwrXsqd5B9FZujGwghBUpXxyTacIqOlGLyxMC9so2z7zWQnT6xVvuqcE51qj/r3K6eM3bFVrKhJpl2LMnUcSn4AR0VMg9kctMKwQbofcm3JXkcrxsqa+e8iGMLxMcjVEGM1eTRuUJwjJy+fMHp/JI2LOtR/gdtFolsOFWC+MrsCyjcuCDL0A1ShH9WK5a7teDVVSC2VpbdAwMTXO8Kd3gvZAQYTOIPvTFrc2gRSnGRWXmdqvcMd3yGRf2swB3tlqobOs2FuG87Zsym0N5ecwf1NxUGJ4rOL/4sbZVLyNpWEmf8DoMkDUYcSRS7F16WoKyla7zh4h7tDugaiN1WI5Mvp+QiVgSp+xRFkww X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 (24/11/11 09:49), Andrii Nakryiko wrote: > > On (24/08/29 10:42), Andrii Nakryiko wrote: > > > Now that build ID related internals in kernel/bpf/stackmap.c can be used > > > 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 still > > 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. I see a syzkaller report (internal) which triggers this call chain and RCU-usage error. Not sure how practical that is, but syzkaller was able to hit it (the report I'm looking at is against 5.15, but __bpf_get_stack()-wise I don't see any differences between 5.15, 6.1 and 6.6)