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 DB08CC52D7C for ; Tue, 13 Aug 2024 15:36:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6518E6B008C; Tue, 13 Aug 2024 11:36:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 601906B0092; Tue, 13 Aug 2024 11:36:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C9BB6B0095; Tue, 13 Aug 2024 11:36:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2D43E6B008C for ; Tue, 13 Aug 2024 11:36:19 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A026F1A097B for ; Tue, 13 Aug 2024 15:36:18 +0000 (UTC) X-FDA: 82447623636.14.594327D Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf02.hostedemail.com (Postfix) with ESMTP id BFA8E8002D for ; Tue, 13 Aug 2024 15:36:16 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=eZqIHgCk; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723563321; 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=8XN8l1jauSNkrNY6DVaHPyqTBlKmM+vQ22mOTXq6Qk8=; b=rluODQOy2H//VGfRFIc5vVn+xXFOMMbMlcgsqCzl9EtpAbip5V+iNiYfn5y6i6g2AJF755 0VkRtRLwLjUZynJeJUo8FSdX6Ox4IL1DNQj9RmYGvC2gYevc1jYHuuQaZ/soyTsMa4G+Kb VZpv1yKU7IlIGBLoHl3PUVu7D3WT6/g= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=eZqIHgCk; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723563321; a=rsa-sha256; cv=none; b=aoICqTgXBv89E8hLdo81qtg0Iv0JpfGFiLdRdLNzWjNnqWQdqyS2ps7aLPYrTjdkL2H6iA eC6mxC4Ri0OeTEgTEdihWxsMtP3wuXBbqta+WBU16z17jJHfL6ipmD+BbTRu+sqbkzI+L3 tsH7AZQKLqp+TZ9bUdokAN1ykUDmhrw= Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-691bb56eb65so52512777b3.0 for ; Tue, 13 Aug 2024 08:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723563376; x=1724168176; 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=8XN8l1jauSNkrNY6DVaHPyqTBlKmM+vQ22mOTXq6Qk8=; b=eZqIHgCkrLQAG5ZKbO40wwbcVzscBdt/Dj9jG9P9GF8E+5YlHWC4dUuMjdBdcvr6/s 2hfuPA4K21uALS/ViiAcN5luqb0JHjDgXeCyp2QLpwTFBBX7awUNExBbM+ufdl+HoJj4 d5s82bj/jNlSwe2ccv1zzWtRGZMwy/ObsxUibH7g4IXbTFYlJ0qLSm0POPUea19X7rGP DyGWtyKDdvjDeamoTYzIb9XiA6n3kPFcfna5qPy5wV6mh212xmZgTzkzPHOuzo0WJ/uq wt5BkZbXo1teqAN/p+FPFkMijlnhh+j4aXXWqa5IVseqvME5ZgnPlLKzqfPQ9lfmCZeL TGjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723563376; x=1724168176; 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=8XN8l1jauSNkrNY6DVaHPyqTBlKmM+vQ22mOTXq6Qk8=; b=akAc9XZ1d6r8MMYxyeGWD7Pb8OwunfAdTW/pX0LVOAnAMlXGjug8E4conRL0uCLHc2 gVhTVRXmib2MCAP8XnjrhbfWJ9DyBVJQvExnldsI0hjQDpbcqjbU9z4LjpFec2Sdj3+h UCvqStQMDfH01inBMgPddGKEO5uweEyMXbM/p9HEOsaFLsIkVKM+3Vx+J3sK3+biKZzk FFUukhdm9q4SOveOVWAQxH8rfxy5FNmwE4R/xbBlY3MZrxSlvGZR17aPuPqYhFPuqIJg 5KolRyQ8bSDjL020sHx5sh4084xDph3PtE6hlFXiwDzjIuZN2zlsXvbwvbxGIrOHMn8n OnGQ== X-Forwarded-Encrypted: i=1; AJvYcCUQOWzSP+Ieet3vOz4yl7710I+rbUUQ2vQXNHxHJoW9caFrF8fECbCVqVRceM5xjn78NDoEua794/Oz+Vh4LfsoGF0= X-Gm-Message-State: AOJu0YzDxVM+Ty/WMd5tpTC+QrAawlT2VadS4C7ilvlN+w6teb4s0wxf kw9vo659RHVnYA0MZDLYLaw5aDV7cEVu3thMyictie8yYjZeG8C4r6jk/Qf01o4gZIJ2Fc3LwyL Ylm5qoTGQEjd+n6VAaVYSQaBgkaRG5ZTnR3Rx X-Google-Smtp-Source: AGHT+IGewMdQHdmN2hlq9rjJ5cHzdQ207H+U5ZLcJ+Wx1W91wONKxrCoPZpU6MRnXFPoSPwcwCTkkq02/x8cYLzztA0= X-Received: by 2002:a05:690c:ed5:b0:632:c442:2316 with SMTP id 00721157ae682-6a97142715dmr47043317b3.3.1723563375488; Tue, 13 Aug 2024 08:36:15 -0700 (PDT) MIME-Version: 1.0 References: <20240813042917.506057-1-andrii@kernel.org> <20240813042917.506057-14-andrii@kernel.org> <7byqni7pmnufzjj73eqee2hvpk47tzgwot32gez3lb2u5lucs2@5m7dvjrvtmv2> In-Reply-To: <7byqni7pmnufzjj73eqee2hvpk47tzgwot32gez3lb2u5lucs2@5m7dvjrvtmv2> From: Suren Baghdasaryan Date: Tue, 13 Aug 2024 08:36:03 -0700 Message-ID: Subject: Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution To: Mateusz Guzik Cc: Andrii Nakryiko , linux-trace-kernel@vger.kernel.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, akpm@linux-foundation.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 7bjw5idpus38q6jxboojm8op8stfs135 X-Rspam-User: X-Rspamd-Queue-Id: BFA8E8002D X-Rspamd-Server: rspam02 X-HE-Tag: 1723563376-610973 X-HE-Meta: U2FsdGVkX18G4TnKiOKZ3Z8H44d8BVnfGlPSiwj/Zd2AHdWgAbHzWEnxTFtQkOvo7oiG2cpC0bYezOE/2DOrRxOrHp6j7X0Kd3UpldXiTXPKv9pt1cJGH5LRotGTKG6UPrCjFrJfysXMRBnAKxrPVhIUR1tVYkQ+hO0WOuGN2R+MKTr4bOeSOGI1yKpVoL6HxDiPC1y3BvWqg2YiyD/ldgnUMCo4xYLx/TrtQB4XXtWqXNmVZWnw13CJ/YOt9P7Kh2+xYYhhk5+hn2MnNFZ5bCHXDkuMBf3kov9FHHOEpNEf6WPFWF+YxpWDTuUMK73LKr0qh2zKhFGNsO/54SUqRhHXUKFe02bR3oGsh+kne4bXNUsr/W/l5f6q5Uqk2fnDljl3jeZo68CXgkfZzl7KVCo4GMHwvqD+6ZxLJuT09TkkCbSIx/9spXfVYzD7GIEy7gOsB7Cy+M5R/wDRBtv1OuvaSlN8rzBpGPKKYXZYC7b7l7DQhzWbgRAzlLaqWGp8lxb/kyYFVApKEp+egbQZzwuqvHHmvD45NM7ExN2SG35BtJ1ad32bGrF8n6+hhPzljhZ4EM89Rk/oZkFZnH+MbynwJUmldbc9tiVXcetN0Ar1327Hz7ExIH1ZUUQk6ySRfgalH+EB/A1BFEzBW3foCY8EJlV2pJFyG7x6Q+QdmdSAKICBfyXYaW8J0KhAm4XIp15xTpo0d1B332LAjrXvDbrNd5lZkCl53KZX3kpGbWCu/MlKKGaWuYZZ+avNymYKrbbXdu1SjR4Ppmu4RmjvluC2C6qwHssqx1nv75hafSxyL6hSEyD4xsuqAn42piFnleieP1NX0+FNvRnzYNKUyzJXcJXNXff5EA1ulUG1AxWEELwE1rgGQ9fOPOZ6GyjdYFL2DvAjiqD1fa1NUNzmI/aBPGtpxJsTZ83K+/YgNjFIhCN1iHIPG04AUlr5/0opi1zMCY7NprYP7TPPFIk cBImLQub phQhFJmUaMhpYTtbtK1ONhL5T+UDypPPQzKYhyatlI3X+D5g3j/gT/yh5fAo9gs+HsDMfmx+LCSeJNQ9Cbp5nBN6ByLF4mCBmPVptobmRU4V9u1Ei0yY+bJf+VdQ15DW+JYblukJmYm4d617wOjLh9sREnXCt0pJ8oixw3InPJb1fWcsbxzSbf7ufrkwpmSjLctv2 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 Mon, Aug 12, 2024 at 11:18=E2=80=AFPM Mateusz Guzik = wrote: > > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote: > > Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely access > > vma->vm_file->f_inode lockless only under rcu_read_lock() protection, > > attempting uprobe look up speculatively. > > > > We rely on newly added mmap_lock_speculation_{start,end}() helpers to > > validate that mm_struct stays intact for entire duration of this > > speculation. If not, we fall back to mmap_lock-protected lookup. > > > > This allows to avoid contention on mmap_lock in absolutely majority of > > cases, nicely improving uprobe/uretprobe scalability. > > > > Here I have to admit to being mostly ignorant about the mm, so bear with > me. :> > > I note the result of find_active_uprobe_speculative is immediately stale > in face of modifications. > > The thing I'm after is that the mmap_lock_speculation business adds > overhead on archs where a release fence is not a de facto nop and I > don't believe the commit message justifies it. Definitely a bummer to > add merely it for uprobes. If there are bigger plans concerning it > that's a different story of course. > > With this in mind I have to ask if instead you could perhaps get away > with the already present per-vma sequence counter? per-vma sequence counter does not implement acquire/release logic, it relies on vma->vm_lock for synchronization. So if we want to use it, we would have to add additional memory barriers here. This is likely possible but as I mentioned before we would need to ensure the pagefault path does not regress. OTOH mm->mm_lock_seq already halfway there (it implements acquire/release logic), we just had to ensure mmap_write_lock() increments mm->mm_lock_seq. So, from the release fence overhead POV I think whether we use mm->mm_lock_seq or vma->vm_lock, we would still need a proper fence here.