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 4F60AD3ABD1 for ; Mon, 11 Nov 2024 17:32:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9235B6B0092; Mon, 11 Nov 2024 12:32:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D37F6B0095; Mon, 11 Nov 2024 12:32:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79AB96B0096; Mon, 11 Nov 2024 12:32:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5BC8D6B0092 for ; Mon, 11 Nov 2024 12:32:43 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 00B1F41A1A for ; Mon, 11 Nov 2024 17:32:42 +0000 (UTC) X-FDA: 82774506150.20.941ABB2 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf19.hostedemail.com (Postfix) with ESMTP id 354371A0006 for ; Mon, 11 Nov 2024 17:31:50 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hvmy4VAd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731346186; a=rsa-sha256; cv=none; b=J/bAkhnCazyvifVwoKWY6qZieDiYTAvuuSTNMo5kKCU/6osH8U6FKXQp7uXFgxXPdgy5qP fZJ8YuX/DqjeDJ/C0eU08LVzekpMeTopjQ7PD7fTqHYH0GIwIvLQsf4568TSLz5cJjDyxI u3QaGImRRcpZawZuqfinuwzrINN2gr0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hvmy4VAd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.160.171 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=1731346186; 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=446kiMyz10bq8FieaREKKmn4/b2mNECd8raHOngAG/s=; b=lCDrkXKjPR73RL/Bj8DBBvMQ0WyuDv0SuDflVg9FbnaHDZgtfwZoYrlJXsj0nNXYGnvFhk KgIRosuLfUePXyp58pKCIxK1rOwRYJqDMUTIyHP1VBDLA57RNl8hAYkqR1tPnYgAOM1C7J Vv1bhAoFS5iGndyaMr/twm1Iw201M+Y= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4609967ab7eso35186051cf.3 for ; Mon, 11 Nov 2024 09:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731346360; x=1731951160; 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=446kiMyz10bq8FieaREKKmn4/b2mNECd8raHOngAG/s=; b=hvmy4VAdM1BJSLLSHTG7ABtGlkVm3yPkcdc3S+arFv6THeyo9YmqmivdCBwJSiBzk+ vJbvXuvvpYc2GZ+Lirkx2I9LrasGt1ZGZGYDQShzGP7VvncJarFxSfonltQ7ComAg9rr RA+mgySuJBpL0QHQhzEzYCg+qxuSHDMHZEMIzxVnrXYlCLVcFzoKNtiXfHjAcWI7SH2N y1jwi2dDvInBCH0At3lmtZo47nkkHmUsSq/+ZhE7U1llcyVCdPCF0eadrsJdyM6//LQy MO1qB9/aKJZEyTnJiEDCkr4HmxaggC1M0jiM7MQ338QSRkTnk4Dg2MtO7jFoPc8c6b03 J9ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731346360; x=1731951160; 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=446kiMyz10bq8FieaREKKmn4/b2mNECd8raHOngAG/s=; b=fS3fC7VkZ8VIK/8V5jqOTNPKAi0GQ2ZkuRYWoz6ln3Xi2h3fai+ENrKg7Eath2YTIE D3pbajv5QtNN/Vzzqtp1VIJovbILFWHX+iwYp6HK4bQgcZxAobMIiampo6SyPXUnukE/ KkctJacuKMd0Uewsy9pDIjQ0muHXc5nGTXZ+hBnrVU+y7JBV2XkfN9qM6AA7ulR3NggI UCnOtBGTbcrLccO+RF+VSiyCrKVqDF1Xqi+K8LjNEU8BB4CF4sBXySY4aR01OV7zuYV7 ps+OqRpWFzAmEHO/jSx3bFtG720+FFnyNtIIppcXwxBAzClwk5ZE2soxtzUdVlaAnn5k jj/Q== X-Forwarded-Encrypted: i=1; AJvYcCXZ12JJPJJudo5AQjx2i/HEmJnpoSFuV+/y+ePc3J7aDaJblH9G+mTb1F2s9RX7ox+6671Lv7f/pw==@kvack.org X-Gm-Message-State: AOJu0Yya51mfaHFgfBTAM3VzOgpx33gmaCGpIMtYbmI+OoTbfw2JgDax vEcHMTcjjnOUu3Q+7srugbAwK8FSNuaUapdHXesDKhGfNEKnYJ+aRP6CsJh44RbIg877Nw8NLmM jN2LN/CGgXB1Q8nUyVcfQ2HVCDgho9g== X-Google-Smtp-Source: AGHT+IHYut3+sEt3XzJfDiHtcSZtT9/Ehm9MZiVZDPX1nQCusxzbEs5rW24mOSm82XpfMduwn3JOTnvHCYtdPw0Ys3E= X-Received: by 2002:a17:90b:2b45:b0:2e2:b64e:f4f7 with SMTP id 98e67ed59e1d1-2e9b177fc67mr17790610a91.29.1731345989175; Mon, 11 Nov 2024 09:26:29 -0800 (PST) MIME-Version: 1.0 References: <20241028010818.2487581-1-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Mon, 11 Nov 2024 09:26:17 -0800 Message-ID: Subject: Re: [PATCH v4 tip/perf/core 0/4] uprobes,mm: speculative lockless VMA-to-uprobe lookup To: Andrii Nakryiko Cc: linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, peterz@infradead.org, oleg@redhat.com, rostedt@goodmis.org, mhiramat@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, jolsa@kernel.org, paulmck@kernel.org, willy@infradead.org, surenb@google.com, mjguzik@gmail.com, brauner@kernel.org, jannh@google.com, mhocko@kernel.org, vbabka@suse.cz, shakeel.butt@linux.dev, hannes@cmpxchg.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, david@redhat.com, arnd@arndb.de, richard.weiyang@gmail.com, zhangpeng.00@bytedance.com, linmiaohe@huawei.com, viro@zeniv.linux.org.uk, hca@linux.ibm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ez1yra7tekm6539kukd9nybyic5we14s X-Rspamd-Queue-Id: 354371A0006 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731346310-483745 X-HE-Meta: U2FsdGVkX18IL8KoHgLl4tlg0hiC9iORUNbF8cn9RJToWGoGEivKCQGk9+EJOnGVb4v4H9przdPdIyx4FGbL/nU704NDn+G7iQ3yMAZ7GhSE5PjkWYdCNdoauT0mzumAlUJwuJNyEebd8eu1ngmiHk+7EDxk6rweCPTfws6O0ivijyLT5kkVQkeoWD8G2sLXKaEDr/+zxhwrf4LpWgKGpQ8cEFmVtlHgkeHNq4HQQk1Vif0v/wUeQ6gJtnEYP57C/9RQFKAMQUL5eWHcorBjTKuWvWWmZ/5avMAGmK2AdDwtW2G8Cjm0i8xg+ZQdvQCgy5XD7oXfmtXSf1kNnJ2hI8nopyzdrWydLM7mncmSPJxiAlqGhrcvHLzi0QI0cmm+BmlTIUUVJiSS1Lt3wt0HYr6JfyQdi9jw4BGANbYs/aYEJSCjNkAXsjwwtwX28yydHkMhdFwXHwcdENLowpe1gactIDgnHTY6jetSo7UiLskucDKnOprc/YptoG0s7Nw9G3hkZssR4/4TWUmMF1A0Dvb2gpwlYcDHlggJGta8r7SyNwse7SfVzAZ1TJVmeIS1b+3HZNkX2Lev8k5UeXDArDTrtGQIFQOCJPHqZyIpdnTCOgfsnIkxu1Fxj9o0g3S741rPrE1L+fWToQN9aU2zgSFnEpQM+AnsNl/v4eKcqVJs39wmHObFZK+NuCFulcNUPJeuqNQg+GnEC0rqh8tuvu8ZYAi/oVD0PBwEkyB2x8jTKVscNJv6izGyNvAqlT6o6v3Ueu2D8lZWkFgLH04MSTHEwy31NBjrLammKF1XaGt3XcZGzqnmyuhdlziYY91F4evc8W/bJlVrVNgkN27uQ+AIhh0WN8kNUbi4XZ6YfZpdsOw76Oz+vus0DCCL8jZxYDrk6TkqoVsXiYZXlUte+wfbtYbOIGIMkNCsyTnsYJb/ddPy4csqj/yfWVnJGF2nBIvdBd/5J77SHoAoiJV 1oVFqzD7 ggacFTcoWeoZx3vuGe5HNPfI4TTFo+nJ+GVdYd4F29M47ORARS/m1BVrEnZXT/a2FyV+DlS6P8CAIaHUOyGrcKiPMRBz/1V3fTE1eSKeuWUX5A2jUEgJjC22bJp2PcDWgKJ7rzPdxg7OYUzk7r7N8+UEenUfE9x9hl3nrgaQWsEZAOeIitvGy4Rx2is1+Ig/AOu5I+CrkA412bRroAkpGpkK9REUwXxz2GFaoc7eZCYTkAjlCrzSTP3WICuQlqfmrViK4WvuslCvwcqb2/66vuA8J8pEKDqYJGuN8TDbw+htPusuJpTNTEkt1tmai4KGcN6dASiXxZopiR6janhR1NO7l5NnQhO8UIM+XeDfxKwsxJSMHoDskXTZnQ+aW75ZwysLnvWAB3o24qst3BgiC9RvrMqPMMz7CEyCz1tyjGfV5TmCBABKYBx6KaOFjoZM2SAFgRlEFnhTuc1aih5J/lK0CsmiV0oq8VrEx 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 Tue, Nov 5, 2024 at 6:01=E2=80=AFPM Andrii Nakryiko wrote: > > On Sun, Oct 27, 2024 at 6:09=E2=80=AFPM Andrii Nakryiko wrote: > > > > Implement speculative (lockless) resolution of VMA to inode to uprobe, > > bypassing the need to take mmap_lock for reads, if possible. First two = patches > > by Suren adds mm_struct helpers that help detect whether mm_struct was > > changed, which is used by uprobe logic to validate that speculative res= ults > > can be trusted after all the lookup logic results in a valid uprobe ins= tance. > > > > Patch #3 is a simplification to uprobe VMA flag checking, suggested by = Oleg. > > > > And, finally, patch #4 is the speculative VMA-to-uprobe resolution logi= c > > itself, and is the focal point of this patch set. It makes entry uprobe= s in > > common case scale very well with number of CPUs, as we avoid any lockin= g or > > cache line bouncing between CPUs. See corresponding patch for details a= nd > > benchmarking results. > > > > Note, this patch set assumes that FMODE_BACKING files were switched to = have > > SLAB_TYPE_SAFE_BY_RCU semantics, which was recently done by Christian B= rauner > > in [0]. This change can be pulled into perf/core through stable > > tags/vfs-6.13.for-bpf.file tag from [1]. > > > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commi= t/?h=3Dvfs-6.13.for-bpf.file&id=3D8b1bc2590af61129b82a189e9dc7c2804c34400e > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git > > > > v3->v4: > > - rebased and dropped data_race(), given mm_struct uses real seqcount (= Peter); > > v2->v3: > > - dropped kfree_rcu() patch (Christian); > > - added data_race() annotations for fields of vma and vma->vm_file whic= h could > > be modified during speculative lookup (Oleg); > > - fixed int->long problem in stubs for mmap_lock_speculation_{start,end= }(), > > caught by Kernel test robot; > > v1->v2: > > - adjusted vma_end_write_all() comment to point out it should never be = called > > manually now, but I wasn't sure how ACQUIRE/RELEASE comments should b= e > > reworded (previously requested by Jann), so I'd appreciate some help = there > > (Jann); > > - int -> long change for mm_lock_seq, as agreed at LPC2024 (Jann, Suren= , Liam); > > - kfree_rcu_mightsleep() for FMODE_BACKING (Suren, Christian); > > - vm_flags simplification in find_active_uprobe_rcu() and > > find_active_uprobe_speculative() (Oleg); > > - guard(rcu)() simplified find_active_uprobe_speculative() implementati= on. > > > > Andrii Nakryiko (2): > > uprobes: simplify find_active_uprobe_rcu() VMA checks > > uprobes: add speculative lockless VMA-to-inode-to-uprobe resolution > > > > Suren Baghdasaryan (2): > > mm: Convert mm_lock_seq to a proper seqcount > > mm: Introduce mmap_lock_speculation_{begin|end} > > > > include/linux/mm.h | 12 ++--- > > include/linux/mm_types.h | 7 ++- > > include/linux/mmap_lock.h | 87 ++++++++++++++++++++++++-------- > > kernel/events/uprobes.c | 47 ++++++++++++++++- > > kernel/fork.c | 5 +- > > mm/init-mm.c | 2 +- > > tools/testing/vma/vma.c | 4 +- > > tools/testing/vma/vma_internal.h | 4 +- > > 8 files changed, 129 insertions(+), 39 deletions(-) > > > > -- > > 2.43.5 > > > > Hi! > > What's the status of this patch set? Are there any blockers for it to > be applied to perf/core? MM folks are OK with landing the first two > patches in perf/core, so hopefully we should be good to go? Another week, another ping. Peter, what can I do to make this land? MM parts are clearly ok with Andrew Morton, uprobe-side logic didn't change (modulo inconsequential data_race() back and forth) since at least August, was approved by Oleg, and seems to be very stable in testing. I think it's time to let me forget about this patch set and make actual use of it in production, please.