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 3BAC3C52D7C for ; Tue, 13 Aug 2024 06:18:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 637866B0098; Tue, 13 Aug 2024 02:18:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E7716B009A; Tue, 13 Aug 2024 02:18:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 488826B009E; Tue, 13 Aug 2024 02:18:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 29C5C6B0098 for ; Tue, 13 Aug 2024 02:18:11 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BCECE1A0630 for ; Tue, 13 Aug 2024 06:18:10 +0000 (UTC) X-FDA: 82446217140.14.6471609 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf18.hostedemail.com (Postfix) with ESMTP id E16D41C0012 for ; Tue, 13 Aug 2024 06:18:08 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=K9GlJzs5; spf=pass (imf18.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723529795; 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=16pKIYRPYzAZ2cVZGoDKE+g4e+Tu4+gU68ARoHo8H9E=; b=7+JcbDxZNgsS39u041g3EDdeHclBuBsMQLRhlU2EIkbVj98sjYjzeO95FBQUsgMzZvY4pK OV8Ogqu5JGjEeA+SfuE8CbP7Kyvl0w12aGOR+4ffXch9QEDt7rwrStxr0KbOPOfTLvTRoZ BOySooWI70xMR7TGUL7fcmrbJIlU+wk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=K9GlJzs5; spf=pass (imf18.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723529795; a=rsa-sha256; cv=none; b=YFBL59fsP6AGwcppsSFY3LC7f4RLpSrT6wX9NH9yM3tKOzPwOmu8Ku8Y6ebKWGBhHGxD/F x0AMPl3uWDAAfRksnHsoG+d9v2Dsiw3JRkuolXpR7BXhjVJJETkvH3qaf1fdTNMIEHcs1T zmFcvAk+ApbqjxQ0uF5ga6q6NjOMjrw= Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-a7aa4bf4d1eso604371366b.0 for ; Mon, 12 Aug 2024 23:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723529887; x=1724134687; 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=16pKIYRPYzAZ2cVZGoDKE+g4e+Tu4+gU68ARoHo8H9E=; b=K9GlJzs5qttgCjvysYFs8rXUPx+Y9CsCUpiEOgHSUhjoZMmtBJQbeLgnWqj+KE8hwP p+I2iWkH1oD+nFpl0p4CxPJlRf5zDQwngt2SyharoEM0qrOtbtW9rHBpDUHIu7e2ki8T H6kY0Z77HPBZIdXr9wH/4uEdxFZ1AAx7EwynRVFLyTSjjzLEGJhIAWa428nsB0axQhFD IducPy0woaD/FCHprGGIkNRpQRMqQMEjVZZp+O3Q6wKB64F/BdYT4xeS3e6QYv+ddpsB zB9Sepny3fraZp8mB0/mA2ve0y98q8sO7eWMoVjDSJmrX7zMczteMe7uAbT6Y+3brs+W PRRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723529887; x=1724134687; 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=16pKIYRPYzAZ2cVZGoDKE+g4e+Tu4+gU68ARoHo8H9E=; b=JEESDwiORyG0EUPPOOALiTEE2/nusRIS0QK8HEejjQi9dG3vqhnq2ILTBpAMiEU3E5 eTe4qQxpW+b/aadXJ7FN2pUZmYPLEJSBv1J8u72Nb3rXoGuTTwaCAidRmsRqNT6AcfRs na07NJ1Yy46qI7gSn1Kwj4CVWKX6DS7CVJ8etXTsZ87TEfSCXEyHWQXaMenFVn8T2usb 4ex7qfNzxlxGE71Sk4JNNImVk2gifhVdoHrKDnGBVsOqy5VDo5Z7zbpfGyrLWm0cwOhT H0BmZgmP+xPW/6AI/vwg57HmirtT53TE0VYDUV/Fs3et4SrLBoJbKT4swXv9nDnA8xNm K6DA== X-Forwarded-Encrypted: i=1; AJvYcCXzTdOvrS1fngfAyuWt6WVpnNi0E6BZpI9c3wCnKqwbJgA6NgQXLjwQyQLw5KJIoT6AKmeIVHHF8Jn4723MRGi9BRY= X-Gm-Message-State: AOJu0Yy9qBf7wobXBSRvuD70/eSGMgsxO3s4IzdvzbT/ZJ/n+LDzQAUJ 0xw6MlBefPgn5MtvIshngoJuxtc5wDN4H62KekYoAplk0cOhjqhkpQF0o9Xv X-Google-Smtp-Source: AGHT+IFgZG9it8OjdYZb1L8HgN1g3Lf1MfTdxpAh434F1nFJT65wNOswN2hy9m/9TLGYCshL1AT9Rg== X-Received: by 2002:a17:907:7d8c:b0:a7a:91e0:5f1b with SMTP id a640c23a62f3a-a80ed2dc9c4mr166308266b.68.1723529886757; Mon, 12 Aug 2024 23:18:06 -0700 (PDT) Received: from f (cst-prg-84-71.cust.vodafone.cz. [46.135.84.71]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a80f4183aa5sm40432566b.211.2024.08.12.23.18.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Aug 2024 23:18:06 -0700 (PDT) Date: Tue, 13 Aug 2024 08:17:57 +0200 From: Mateusz Guzik To: Andrii Nakryiko Cc: 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, surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution Message-ID: <7byqni7pmnufzjj73eqee2hvpk47tzgwot32gez3lb2u5lucs2@5m7dvjrvtmv2> References: <20240813042917.506057-1-andrii@kernel.org> <20240813042917.506057-14-andrii@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240813042917.506057-14-andrii@kernel.org> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E16D41C0012 X-Stat-Signature: z9p9rh3zidsfzx6opt6k73wsf3mw69si X-Rspam-User: X-HE-Tag: 1723529888-641453 X-HE-Meta: U2FsdGVkX1+893SWKuZiNYimwiReUiIDZpu1eXiOTTNynq1HiC3OCEJ+ogfL2GoQ03tQXHF9t6aQnx3SLGZu7LmuVVtxUoAJauHBUrQvzPfn88sIkl5id3wABu+nGNFZd/pSLNEYwUdjyehvgJ9/ubXGROjM/T5v+C1MA5BHEkrKtGxSV9XRpGz3scPchRwOvPEVeb1rwN7/TSEWEbfBz3eEQCPkDAQtdy1qGQiekNZaohkr6+aosRI5UtGLb8VCIHa+6kr2356NY92b/Cui3z4nqy696kEnRM8y6Z045Jt+po60ZXSG9QXgufmigrEPrK/d3R2LOIKsSEH36gjCworvG+3LqWaRDo2F5Ds4lHItNSJAtAhygrUpZf6kF97mejnqF6hP99dKiCQSj8RJQnAiYDREqPnZltLTYVCihF9NH28iNB8HbkLbztprO3QpqaV2OKQTxn0YSUyLaqIx7OTwPsQyPNeCT4Jy49c+diChueTt7LiS/gT5FIhkamXsOv/lArJdiuyWQWKC834i9NsxFbseYoB2wvSXfPqYOHwXsBaa0xhoQd87d0Yb7CxYaJSdmwvt15G7XZk3/5xkq1f51IgBmAl2+3OH1H+euPSpU4jEnVLaXWN83jUpd49aHRdr9TB+pP5IDgUEjh1XLG8G3L+zGmAkEuR4VCu+kDxJcI6OglxLgMa/u2L1TD0myq93Jiim06l5sc7mJ46KyO3M2LZSkmwjGQPolLyTXf21T7BVh8yTDZGxywURZVL3s/VHgjK1XH3AMdsbCsj2Gyn/y+r5Sad3x6kQC6xUq3tSCxo1Se+i0HNlFnJBMCoHyekHKXCNxub9k7QQjQcsYEXIqBSZVnn/LMSkIACjcs/H0KMqTFPqGgiAP9jb7STFX3YrNxDQZ8ei7jjlBgI+UKQdxfQa4/L+LwtFWjOOBGnMqRuU4wDhQaNYQHt4LcLQnNNZ3GPZX3ddUiQGocn J0rfGYHX +uZBSZJDG8zXVnV+BBJH8qG7j2sIhkukmfAo1e7/ywW3/f27tYN/+M/tGkLBhiDhUYgMDBz1xi4NnYkQvAHiHwv3UGlgDFuPLZ43oi6rmlKcDi15YRh/J3eb8AX3SzxDMv8mVqSToCOAlPxNDE2lCBYkH0Q3XLIEpGVnjG1TvhKLkRPct+ZbJLhnqshCPX5xoLg6UU5aGCivDGWb1vJPZv35emHk8tKT6OiEGS8lhoheS9zJFvuB3BJTEr02I6Uhb4lEIfYZJ0SjpR/YEaS7E5lSIw+ar8p2lNWfr7SLHBrV31Uqg9Wx7Q5sTTYcZ+J7bHYL6pp7CG0t6dEZVm9s/QNlR9qs/1Xi2yESUy8aId6J9dK2UlTAeLWG1KQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000994, 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 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?