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 B52E5EDE9AB for ; Tue, 10 Sep 2024 17:59:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35A4C8D009E; Tue, 10 Sep 2024 13:59:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3005E8D0056; Tue, 10 Sep 2024 13:59:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A0808D009E; Tue, 10 Sep 2024 13:59:00 -0400 (EDT) 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 EF2CA8D0056 for ; Tue, 10 Sep 2024 13:58:59 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A14CB1C4752 for ; Tue, 10 Sep 2024 17:58:59 +0000 (UTC) X-FDA: 82549589598.15.7161FCB Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf07.hostedemail.com (Postfix) with ESMTP id D083240010 for ; Tue, 10 Sep 2024 17:58:57 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ObHq0tsJ; spf=pass (imf07.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=andrii.nakryiko@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=1725991110; 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=GjEfxluKTJVRF/DjHSV9HalaftsH0waQ1mRxQ+bwGd0=; b=nUHzKlX+QtDKuc0/61PB8oSU+ZjtKthN6eLqs8+RSHYwvwuL5yg9q18mgQ0fXfLa8TnjU+ XqL4eiGsmLWpksm/MEpgGbUmTOxpSpD8M1ov7kZ4IX3KAM6aiuELQ2p3PdM98BfRzezECM ztIrzNN1KVaCqkUCHly2QVR4bDT/SsA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ObHq0tsJ; spf=pass (imf07.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725991110; a=rsa-sha256; cv=none; b=x3i/Pe1XMjO/j31Evt8VF4SOFb7XPuHNay0jKV8QLXkBRLjRvXsSt3BE9RlrteT4vyCkZ/ KREMfNoMVWp0yMGwyjqraoBOT7oH/7wCu/GO34cyt2oAtsCWEB6b9yyGoiYbxaG5qxZJKs 1X/ZXCOg1n0yPtiaGP4iG7Ih/0/DucI= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-718e3c98b5aso2666568b3a.0 for ; Tue, 10 Sep 2024 10:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725991136; x=1726595936; 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=GjEfxluKTJVRF/DjHSV9HalaftsH0waQ1mRxQ+bwGd0=; b=ObHq0tsJjKAIuAWfT/Ntywvhl/lhatQuNimmhZAvS3wwlJcn6/vQ7q1XwAPxNlT1aV Zj6TGru9tk29pvE36uL/2CM6v/Xy4v0B/FjsDBV3doyBMPzXkp5BGr2WPu+6EVCk4wcP VBSbxhK2YafhLmVoch/ekn6cTAmKOfbSDl7uO+K3anmzCgv9PyOCwKOx4HC3Qg3qbzDn 7so8vgrDTBrkCsd2pyeaXrkCX0Mmj1edPohT4QX8rMgGwL88FBt02UyrNzqiPdVxc4+m IMIQevj6pDDq4FB+QwqPnuY8shfoCsycV5K4KDzvMhmkshrXNJyApY6mgQQyR9ozLkF0 DpGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725991136; x=1726595936; 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=GjEfxluKTJVRF/DjHSV9HalaftsH0waQ1mRxQ+bwGd0=; b=YuOUZai0St/sccNjaA0320v31qSAV5Csv36cdvuNGVcJPOScteRXxwL3FCqTbxlCPk zjxE6jrOTgJkjxuaEcgrRuaqUEP+5mlcIzaMskxMXzCCazouFlIP8G7ao532ADxbM6Kw ZSuwoz9moXAhfIl91Wj1e0oArzo6d+TDC/wmJrqj2SOwfYnUpr6VpUuworRt4mMqwJRl 7yfJLIZVxS9bPAsy7vPUw8NeASoRhU5MS6+Hgxyjt9zh/9mgXsdPkHmfgHRo2nPvgB/c mr+Ka2k4aasgvOgQ7dEus5U2h6+2Q7KhSMqG11ZGg47U40mR1imKvISaYtWHLX3VliGx N9TQ== X-Forwarded-Encrypted: i=1; AJvYcCU9TWkGIcBGH0uUQ1dD2c8yiYTy6AWNXxS410nLjs5hi9P7Fo/d0e/brF/j6244Y1qp7CKSz7HGuw==@kvack.org X-Gm-Message-State: AOJu0YxOlFpFXgrBEKC4SzL27WU2r9bWhlgChruD5BGmHDtWfojGLKZI OXjw3d7Gc08wzI4EBsNOR7rxOukTthMEwYUb/+eX/vM9ElLBTfiPIbeHPTBZdG3OpZnxVNeZBaf km20EzqWXuOWELN68KpHuDFd5W90= X-Google-Smtp-Source: AGHT+IFNXrrVPS1asK6Ez1I46sSg3pMZ8OK2Mpk2mTEoVt5umC/wSIE0wWN0Ozv5MLC/PZQn/zRdVhrtnobU1pfO/ig= X-Received: by 2002:a05:6a20:e68e:b0:1cc:e14b:cf3b with SMTP id adf61e73a8af0-1cf5e0f65d9mr1617076637.27.1725991136326; Tue, 10 Sep 2024 10:58:56 -0700 (PDT) MIME-Version: 1.0 References: <20240906051205.530219-1-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Tue, 10 Sep 2024 10:58:44 -0700 Message-ID: Subject: Re: [PATCH 0/2] uprobes,mm: speculative lockless VMA-to-uprobe lookup To: Jann Horn 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-Rspam-User: X-Stat-Signature: y86qbik43ut45x1ibgmnaqhur3tfnho7 X-Rspamd-Queue-Id: D083240010 X-Rspamd-Server: rspam11 X-HE-Tag: 1725991137-197062 X-HE-Meta: U2FsdGVkX1+nFTASF5cBudtS2flgzZTZBS7IgpzAjFnANBHgBYHANQr2Id4tX/gaWbJVWIaJG/7qPIfD6OG724NiV8MtKnc2Lbl/PrjqkBA4+X5LJUYLNV/gxfkK38mb2wo+hinorIPdxOMP/x3VniKuFMAxy1lkL5DvtMA5HbAyj7ZHzG/lMQLsdTM26OCZXx+KnzUUOzm3D+Cb0da7rirnQqoBFbcp1Jisl5UCH+Y0PdKbQ9oe1h3LzRzaFiISYOUnxRaI6QaGRcxwEeAH9G7V7QIqZemXf+HjFJ737WhVYnEx5VkPDwV10p1E11SbkFDo2Om0D1O2y1n097wMnSgyYdNSyu8dU4w9Vw444WkqQq+8geoyTmCjlOmHWN5FNtrb8wDV3fYM0xyKMgMlG1+J2HiV4aM8wZiG8V8BYgz9pDoOSPWdIsP7gAkrPb408pgSfaYvQt7sWev9edYkyR2UKMzr/ZXlqBmxM0jJT3k8qPiOgVIkc3VtYNunryorkrmdC/A2w7xhsvOKt/FTiw/paHQdS5AmVG9wneRuq8RalJNnSbvGuNHEmmgCqMjM70QP1TGp1NClEo79O1JTv0/RBAjdkFToyiXm5KhyU3vaB4Jxfrw90/iNaCn3d1qt9rcI3h4x8AHkUbxo0Ib3IlwHUO8lnk9B4OKmUfqIXQP9de7fam/1dfALwecM0PDbJwTUIMxawZ66ViQB5ANNQXjLIpG7fb+5LxO0k0U0IAB65e2E5VMFFfteSSG/2x3egGQ8P8zlKT5BtBhvd8j9q0Nr+3xBn+6vA+/cr+a1TvyGSFoRcq/PkmjMU1cDBCdK7Mo3VtblAzUAA90EbSSaRPiEu7EvTuClxSCeQIW/N9JT+AjHQmL6kmarXOAOaubQVd2HllrNhRzkLidEVwZdufoYE8bhvm5bC4pN2q+D5Ig1b3iP/GbxvImgtJaLHG6tUjQPMVuz6LlAXUq7HOp HdD/AbJq uhe3muYSPAuaL9Ky9MXeRZZ+1kCajrwu/M5hTm/VWSK1hFB5R0bjQVEsc6lGq0XrjwB5sPGlFMw1RZakIEFQBkZma2w0/1Wvheo7YZyjct0SE8dy5SPJAN2eMx9/xlLA51h/I9L7tbPNBmKIHUb9K+Gr1eqTXF9KPWS8vI5zvGE6or6F6+Llm86uBvMxyFeRCRtfsJjxr0BVujAn+7I9NDwuy4rG+FLGaVvccj8Uv3WMvACgGB2cXJyyzsGgHVILdMFoLCjpFxQ3zlpR9YsMlqnZLsV4lCTvFcq+FyX3vtNiTUaY39w2/iFPPB6mVMV9iCsCmSjRThusvls5DscyvwrmCs5IT/4RuiGUSi98BJEW5b2sXRN8p5viTNl4UMXkZKH8X46IS7t53ldA3RJUtYOt3xKhCOWMqzyqs X-Bogosity: Ham, tests=bogofilter, spamicity=0.028983, 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 9:06=E2=80=AFAM Jann Horn wrote: > > 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 b= y Suren > > adds mm_struct helpers that help detect whether mm_struct were changed,= which > > is used by uprobe logic to validate that speculative results can be tru= sted > > 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 can be installed in many independent anon VMAs across many processes. So anon vma itself can't be part of the key. 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.