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 1E31FCA1018 for ; Fri, 30 Aug 2024 20:43:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4D5B6B0107; Fri, 30 Aug 2024 16:43:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FD306B0109; Fri, 30 Aug 2024 16:43:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C50F6B010B; Fri, 30 Aug 2024 16:43:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 62F826B0107 for ; Fri, 30 Aug 2024 16:43:51 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D81AE1402A3 for ; Fri, 30 Aug 2024 20:43:50 +0000 (UTC) X-FDA: 82510088220.11.A3D65E9 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 13E6A40008 for ; Fri, 30 Aug 2024 20:43:48 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dQZb0Rz1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725050562; a=rsa-sha256; cv=none; b=hs+wiRgUyVPXbTEP8xW0RZLQrSbcPMVKSdODdNeGo1+6SOqHNgdjbg2uPGIMpozdsAgVYa tLgF2Sw72eWNKuqHeD6L1MIOupi08c6Ke+S7ORtbcBr8g+LZclpxQ9IIO0Mhbr4ECxmGEn dYPi/do0eZy9u08YZb35KNJsohebVpg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dQZb0Rz1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.178 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=1725050562; 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=/J3chlRHgWeDFjFRxlbl2Q7F2+KANwyc4B88VCV1lWA=; b=75z6ZeDMrfVokti27UP7UIc66TPiMUo9zpDu9jTmXGXeMnVSfp3aWZlRw5+qlnCJ5m2qdD 6vTGkBeIKmL7UJrhLTENX96LlNB+J5W/37yFvrCtLhzqP424wEefVtRg8mPi67sD4uZmcu 2HHSVSFjVs/AgYw1QFS94OAbiTpziPE= Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-7cf6641765dso1706583a12.1 for ; Fri, 30 Aug 2024 13:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725050627; x=1725655427; 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=/J3chlRHgWeDFjFRxlbl2Q7F2+KANwyc4B88VCV1lWA=; b=dQZb0Rz1hjCT2YfZIPoFjK0o6JSgZ6mR5oNRBaIdb8sYvvuwPgi903nfZe+j/1+oYm lqDFN5tBf+8tMt2mrBHXy0+2GnG+ymIbtMVsqwHOUO80kAAp3xR1XgJGh2p+u4wEsY3K V9XetzgL4GDD+Oia79swaC4WchEvrGMNzu2+/pX787Euo7IU0Rw3mMim9I+N3mi2pRSY g42TW96qhDuxa0AZCwIJdw/NwCqZuvQxs+6dlohkirS3RDJCaKOKeM+DsTMHLI3EIK97 wX49JsguOhcZTbFMrUxdXXjXjMH4hSO8kwRljaPy4dKxBB9hGxLCZn0tDGpxBUB5pMbu pMew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725050627; x=1725655427; 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=/J3chlRHgWeDFjFRxlbl2Q7F2+KANwyc4B88VCV1lWA=; b=IELClVdaivniORCN7XSq4JXzCAyZWguAbBXx54ynbqvJdbhgV/3E7/moSwtlcAYuHr aOLWNUrQiHRhLNbieG9VxDkgchixIEeVCTcwxImROfJThvbzbaNC7yAt58/SHsuWtD1g GUoE8rhg3LkoJz9ZF/Ap0lA7DAy9Cm/nLmVCE7iNR9p0ALlSofRveXNiV64HHMnLVrpo WAww64nKKBfF0aHPBkrSdChCyme140PLON+FjsFTVheHwh9NdxBf/PyHYsqyOxmU9v5C BY3oXdjB42NwQ+bcxIoFs6MfG+GMuoM8bviVtqa6CwP8nNfFJ1U19WonZ4+F44E6D3Uc CYSQ== X-Forwarded-Encrypted: i=1; AJvYcCW00U9PGL6Q0Na+nKBFRWdNmqJ2R+W7n1095IIqPh/jqz3wMKpeUIzZvR790Bnc38R9HGtTRzoisg==@kvack.org X-Gm-Message-State: AOJu0YzHsTEhKt8K/w+N2rOGSBpU52QrR54fRyiX8KbJ833e8MqrqATm FBvLw+CDYsu8m1pX7OptoRChwxAd57JVIzYb1Ef+93WOPACi0ljg55euGkFmHJA+AbsSdVJ+z9m u5wLRjGpfwB49xFdKiX+HQc0oeHo= X-Google-Smtp-Source: AGHT+IE4nYRaD6VNgiFBs2JY8ume+v97ADAducXuYilVQJHUShm0gRe+pkzkUhVf//0F8ALTesi7AxhylpkqGj1uvIU= X-Received: by 2002:a17:90a:ce90:b0:2d8:6f73:55a with SMTP id 98e67ed59e1d1-2d86f7305edmr3303400a91.25.1725050627471; Fri, 30 Aug 2024 13:43:47 -0700 (PDT) MIME-Version: 1.0 References: <20240829183741.3331213-1-andrii@kernel.org> <20240829183741.3331213-5-andrii@kernel.org> <20240830143151.GC20163@redhat.com> <20240830202050.GA7440@redhat.com> In-Reply-To: <20240830202050.GA7440@redhat.com> From: Andrii Nakryiko Date: Fri, 30 Aug 2024 13:43:35 -0700 Message-ID: Subject: Re: [PATCH v4 4/8] uprobes: travers uprobe's consumer list locklessly under SRCU protection To: Oleg Nesterov Cc: Jiri Olsa , Andrii Nakryiko , linux-trace-kernel@vger.kernel.org, peterz@infradead.org, rostedt@goodmis.org, mhiramat@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, paulmck@kernel.org, willy@infradead.org, surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 13E6A40008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ee1rxmuteoqg8mf184ik8z3ghhgj3uh8 X-HE-Tag: 1725050628-584750 X-HE-Meta: U2FsdGVkX1/QHu8bAAVGQkJ2HPjXKzDU5xaF+IOA2zzwbfMneP5eNBKNFQ31Qk86uiOW3MVQQAimQ8koZvBXNeqBGB96eIK0zjPczaKfczUovJxEDJkFDybGQl3S7flab/l+7IBF/pSRruGnpoWcA9hd2py8nMt9R9NFUtivOZLWo7f4vYktnY4ZHgST99k7KzcB3dXjJfkAY9uN6Seay7LhfXqu3jjmUh1COP1w+ZXiLBPaAUAIGXMH9HOhFF9PyuZ5DK/3azVRpofMoFL+GEQtEg2nb91xilrmp5sMWL6K9w4iqTNH5JqCCa1iWf9DvsUev7K4dsEA7PHjZvP6S8cjl64ALSjiNSgMq7NSeL1/Rv+XoydxeToj/eMVLC30xzZqKUX5tl9CkQJ15xlrEtt6JS0FhrP5g7KvWlkRAthgXujSa+iJX8/F205NQI2tWPp7fOg0fAWZng74yulMABR+UnRDbB/837dvJJ9OkGadGs/YgC/qMecORWFQt/rZHZPP4RTV2fo33y4Qv9qKZtxp7Kym/n3cb5h2Ue3S1JvNprLY7jw5wQsHu326998j2UrmGuIa4IoRnZro0KKYk04Ofh74GVAqJDkALCxc324Bv5jmiS8xvBW30YVrvJmwDBe84invB26PzSDYvzBC2Jx1AkEkyuPo3wGILb91J7B74URi3U0/C4PYshXyY/RCPcE2JJYSpcUfF7RkHbXeDGpmxMpeebOLcmEi/GIjkHrO+g/XZ6HjrVIhSD2tCJenowh+i5/7A9DqUyAmA213mgSgSdAsats7VWb6lL1MUsQJl90qdJnyZ+BpfFI2bMxC87PTs4iQsMEPNevz61i5/RiqiBImLq0fewZEJcUOELwyuCQ9Fp+bbp0Z47j7WHKVOI4tEiXity5/PlguDLqVG1zothCn7VoMNlVGwCrwq8F4/j91XoXlYvUpsNCEM844quPQPyJUURpkUQY3vhO 2Vxu9RF6 XBK9pbbjk5VTbXQlFtwIaSnwfKS0BlPpQ2qZPurOfcCW0mlO0k+EYhqEaz97+61/eePRweIht6eWopJwO6Wf47EyQnE22Nozi8v2jnZLs9iSEMzXfiYdsLptvvsWU+iboG6Q8qdQaHb5rk9F9C0QglcTFTxHUr8D4HNBsQ3iG5/1b5YF74woQ/ziGkH1VeahpJVk9E7Oj1XN+iqez4kN7xhpKFrXuR7gs66eMqRbFS9KwmyrkGq+BCJ1TXhJ5Jf3Zqw6oVKlSHJjyI6t2ZU5BYpusmxrRujYrU9WksCPjdXE8ecjXf+xU6IJbJ2zf9yh/zrpTmBqX0fleMavMSB1RbNJnsobIj0wX7hzF 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 Fri, Aug 30, 2024 at 1:21=E2=80=AFPM Oleg Nesterov wro= te: > > On 08/30, Andrii Nakryiko wrote: > > > > Andrii, let me reply to your email "out of order". First of all: > > > Can we please let me land these patches first? It's been a while. I > > don't think anything is really broken with the logic. > > OK, agreed. > > I'll probably write another email (too late for me today), but I agree > that "avoid register_rwsem in handler_chain" is obviously a good goal, > lets discuss the possible cleanups or even fixlets later, when this > series is already applied. > Sounds good. It seems like I'll need another revision due to missing include, so if there is any reasonably straightforward clean up we should do, I can just incorporate that into my series. > > > > On Fri, Aug 30, 2024 at 7:33=E2=80=AFAM Oleg Nesterov = wrote: > > > > > > No, I think you found a problem. UPROBE_HANDLER_REMOVE can be lost if > > > uc->filter =3D=3D NULL of if it returns true. See another reply I sen= t a > > > minute ago. > > > > > > > For better or worse, but I think there is (or has to be) and implicit > > contract that if uprobe (or uretprobe for that matter as well, but > > that's a separate issue) handler can return UPROBE_HANDLER_REMOVE, > > then it *has to* also provide filter. > > IOW, uc->handler and uc->filter must be consistent. But the current API > doesn't require this contract, so this patch adds a difference which I > didn't notice when I reviewed this change. > > (In fact I noticed the difference, but I thought that it should be fine). > > > If it doesn't provide filter > > callback, it doesn't care about PID filtering and thus can't and > > shouldn't cause unregistration. > > At first glance I disagree, but see above. I still think it's fine, tbh. Which uprobe user violates this contract in the kernel? Maybe we should just fix that while at it? Because otherwise we are allowing some frankly too-dynamic and unnecessarily complicated behavior where we can dynamically unsubscribe without actually having corresponding filter logic. As I mentioned earlier, I actually considered calling filter explicitly to enforce this contract, but then got concerned about indirect callback overhead and dropped that idea. > > > > I think the fix is simple, plus we need to cleanup this logic anyway, > > > I'll try to send some code on Monday. > > Damn I am stupid. Nothing new ;) The "simple" fix I had in mind can't wor= k. > But we can do other things which we can discuss later. > I actually don't see how anything reasonably simple and straightforward (short of just taking register_rwsem) can work if we want this weird out-of-sync filter and dynamic UPROBE_HANDLER_REMOVE behavior to remain. But again, does anyone actually rely on that and should it be even allowed? > Oleg. >