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 3196EEDE9AB for ; Tue, 10 Sep 2024 18:14:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC1B28D00A0; Tue, 10 Sep 2024 14:14:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B48D78D0056; Tue, 10 Sep 2024 14:14:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E9AD8D00A0; Tue, 10 Sep 2024 14:14:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7F7318D0056 for ; Tue, 10 Sep 2024 14:14:15 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E5B1B809B8 for ; Tue, 10 Sep 2024 18:14:14 +0000 (UTC) X-FDA: 82549628028.10.B38DB2C Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf17.hostedemail.com (Postfix) with ESMTP id 0AD034000A for ; Tue, 10 Sep 2024 18:14:12 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xhf4hHHE; spf=pass (imf17.hostedemail.com: domain of jannh@google.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=jannh@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=1725992001; 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=PN/bOVC7EhD+DKOp8i3e+Nf4juy6xA9SZtiS34NdjWg=; b=O6j63wSn6UJ6Tii+hc5PQNbp+oWoEvLHetf84O9jN3+OH7D3jB7SkwJ/IFZ+Z09CAjLuY0 On6vrUOdQG6heZ0q93CfdPItWjXnHCDxzZe9i0WgZDb5zDYFEQzg7W4jouboGgo+iMsWEO Qy/3ySD0rImnC2Znu6/Ghecjj01JNpk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xhf4hHHE; spf=pass (imf17.hostedemail.com: domain of jannh@google.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725992001; a=rsa-sha256; cv=none; b=KCOc/y8EJan4e+4gNj2ahyNeBVluzv6C1MNYjhArUNHOLQziddpolXv/MCJkMwp20rbvIX CdC/x1hC7Wgzv59+3pyrF7zjbwXsJTlK/ZRemJ1MdtqeIvK3BpcTvu37m3ot85d9RE2rUi ZBuQWTFYil21XruMCvwsCi+0mwIR+rM= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5356a2460ceso31612e87.0 for ; Tue, 10 Sep 2024 11:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725992051; x=1726596851; 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=PN/bOVC7EhD+DKOp8i3e+Nf4juy6xA9SZtiS34NdjWg=; b=xhf4hHHE1g37qdcZNBV0uUMzMqPE+Fq806MB6xRk1v12XTQaUMghMh9r68KdmS30Kb u5KR1U4+KJzWUR1zyIhkpt48mQwBjn8gjI+dlOGSVrPVoz/SJZw/qGSZb+zj7EVEyave AsGrCmclmO0KTsNsmBTY+N2cK36OiYspXTOIju5n52QAPHm5Zaw9yFFVD9j4gysFJrtw goBF+IxPjiWu3jzSloaPKcFph41ECD8+Y4GgAxpVWZoxcIJFivob3Bawd76nzbVDUIVe C98GIoSTeI+PhyiX+DKjmcckVJSpnPdBMSZJk23cz5vz2i61PEurIR3ee4nsHAqb9tS6 5rhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725992051; x=1726596851; 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=PN/bOVC7EhD+DKOp8i3e+Nf4juy6xA9SZtiS34NdjWg=; b=jmpc45MC+uBlWN0BG7vUE3swQm1yCIWBDBclR4+/HhRNiRWGls5L0tcPHXPlpkJnNS FLEW0cC0nQ3n7xrrv8GdDVrhldcVEQwHnGqycAsjSC0+s53/Tdt8wA5LU2WlYafRVzRw ExH1ybh0SjYLbF0NaXpXn5Pwuz4y587csZhHtkU3hVGl9MFuQgck1WDnHUnxUAUCmYaD wlkE7ItsKmkIF7qyK0t++vP5FPP8dx+84HFU7Dvp2tY9OIWBdHjLtLl79hxh2rT9GihO pzyPeIwoDqEOOFaXaTxVjoGfKa5kvZ8kvnixZ5ps83D7XVeyLFOPGps/Ac8zzGRlB/cl t7lQ== X-Forwarded-Encrypted: i=1; AJvYcCVj+KgSUNtB1SY2NImRLYMPXy1Z7EBUfxCPDf/xVXETQ/ZG0fgtE6hOEFD06q11MkQ6W0BmNfz1YQ==@kvack.org X-Gm-Message-State: AOJu0YzVZvLx25JhPy2RlvJ9T5NAQGXMKOLsrVU96mZ8tBJfqdDVFoEJ 9rO5KT6tJdLqxCUV/KjyvwUi6kUo/Md2i3E6POndb0NR9Wy18uXMDdxhqE2kI5ySjXKQD36g7X1 EbtzI9w98VJvXsWjZb4Ycrba4VngT1sAb+tqj X-Google-Smtp-Source: AGHT+IHJzZW54ZelEpqtjg5sNSpim2OEz6bcZdRlXJladf0hM3rQAiAdQOYywo77wa6LK0FC2fDMu1023QrWMkIipaU= X-Received: by 2002:a05:6512:318e:b0:536:52dc:291f with SMTP id 2adb3069b0e04-536743b4463mr19813e87.1.1725992050488; Tue, 10 Sep 2024 11:14:10 -0700 (PDT) MIME-Version: 1.0 References: <20240906051205.530219-1-andrii@kernel.org> In-Reply-To: From: Jann Horn Date: Tue, 10 Sep 2024 20:13:32 +0200 Message-ID: Subject: Re: [PATCH 0/2] uprobes,mm: speculative lockless VMA-to-uprobe lookup To: Andrii Nakryiko 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, surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, mjguzik@gmail.com, brauner@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 0AD034000A X-Stat-Signature: xkocoigfu9nj7rdgg4s6akfx8ymgdxoo X-HE-Tag: 1725992052-345260 X-HE-Meta: U2FsdGVkX19RsxEjyIDX9rtPH0l64w63jhshgcd3+5D80s4XjLPTgrvq8VeLY4KNu+MmEQyfqn6uJOCfr9g6j3asrTb27UHGtCQ8u6hAKb8cgpvogMlfabMp/689Ye9pm+/yU5riIdtJB7Bmgphy8osoipWaQOL0gHhAbkULjFQusE8ngZBHY1tVupXFAg5q0BSCzXEm1+ilSlQ3m/kJ7yl7fk7SYb/PJgRg0dO81rUeKNIcV0AyBPEfviwBj7u3w+5mrs1xWa9Wm1SbwJb0zLIeIIcBbIo6PsFvoVkUqhkDCExsPILCI03azmx3H6lIT4cd7W/lZS5Yl+hib3SFevCgEHceuGOsxIbWL/OHvzC7SJ/yO6eaKa/uPgQ21W6pSXuUg0wrrG6BfrBtt+27LRgyXD9ZYfi+m46nMcfCOGJxe5oqvu44FyOX81LGNa95YdGoTAg3wtTGMRDJ+sA3phobLANpSjWsohzKBnr501CcSqHY8kX6rH+fYLXC0LqWjJ5+M7+voj6pFgx3xuJAVr8p/CO9VJGsW0+pPqCs/NRnfV85/wnf+QQnOvSrRT3JC0SYDnPutybHOqIjBZheR166eA3thhe9zmTXhM5anjBvdjo130USD8ABIaqBoyetRCVjJOcdKgZ5ed3ByF+sRluxBCFDtJ41vQg2XC6Ip3hiBEdcWxzIgBKyv+lsmkxKlDE7Y4eYZ/dFjcw2TijGADKopz186q8EuaIJvB+kVKzRU6ZGrBg/mzsMQQ08r890cqKiO9ZdtPTigsZKGS7u8lFqP09tuZdzxJf8gNnI4oySLjWTDjmKgdhMTBJA/kUiZ9fjsAixTrwc/FuLJIgdb23eRmjjmyXPfisBkUxKJS6q+LYlHPpYW/etddkv31zaoYcuO0QKNlvtCkEAkbpgaSsLWK+TiCDC1HdWTqap6t1XpZWLmf+aWfuo/0u7k6O6DLtm+PUaWXqWKIwZYWJ 9GPBwRPq k2FBN4S7Tfwxf38jUPZ7DKZ87yqdwhVo1cQkKR3605DOxqIUIRJb9O2Bf1vE5ZHPvZqjvgbSx1aBWZWDr/BbQPoF7iEywWVtbOd5qr8PeVH3+UQaS1oOTKrZpA1YJAI2ZRkdIqqLdxDCcn1Z92fUs51XLWuoCVxhWCO3WJBAFoUL/KyROMUrBoaMbCUYpujDSuJjPJ7QAs2FABtq5/2ygmfOHBISRCQroO58NMPxk3ddNC+xRJfFFMR2u3IzSkNBGmpv3tKc41uD5t7askXWCJ28DcMVuHFHf7+worY9r2UuUiqsEQJdZ02guZrgiJnt56+o0u/G7aVNtxFRZYqPPLW1JEw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000229, 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, Sep 10, 2024 at 7:58=E2=80=AFPM Andrii Nakryiko wrote: > On Tue, Sep 10, 2024 at 9:06=E2=80=AFAM Jann Horn wrot= e: > > On Fri, Sep 6, 2024 at 7:12=E2=80=AFAM Andrii Nakryiko wrote: > > > Implement speculative (lockless) resolution of VMA to inode to uprobe= , > > > bypassing the need to take mmap_lock for reads, if possible. Patch #1= by Suren > > > adds mm_struct helpers that help detect whether mm_struct were change= d, which > > > is used by uprobe logic to validate that speculative results can be t= rusted > > > after all the lookup logic results in a valid uprobe instance. > > > > Random thought: It would be nice if you could skip the MM stuff > > entirely and instead go through the GUP-fast path, but I guess going > > from a uprobe-created anon page to the corresponding uprobe is hard... > > but maybe if you used the anon_vma pointer as a lookup key to find the > > uprobe, it could work? Though then you'd need hooks in the anon_vma > > code... maybe not such a great idea. > > So I'm not crystal clear on all the details here, so maybe you can > elaborate a bit. But keep in mind that a) there could be multiple > uprobes within a single user page, so lookup has to take at least > offset within the page into account somehow. But also b) single uprobe I think anonymous pages have the same pgoff numbering as file pages; so the page's mapping and pgoff pointers together should almost give you the same amount of information as what you are currently looking for (the file and the offset inside it), except that you'd get an anon_vma pointer corresponding to the file instead of directly getting the file. > can be installed in many independent anon VMAs across many processes. > So anon vma itself can't be part of the key. Yeah, I guess to make that work you'd have to somehow track which anon_vmas exist for which mappings. (An anon_vma is tied to one specific file, see anon_vma_compatible().) > Though maybe we could have left some sort of "cookie" stashed > somewhere to help with lookup. But then again, multiple uprobes per > page. > > It does feel like lockless VMA to inode resolution would be a cleaner > solution, let's see if we can get there somehow. Mh, yes, I was just thinking it would be nice if we could keep this lockless complexity out of the mmap locking code... but I guess it's not much more straightforward than what you're doing.