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 BFA6BCA1006 for ; Fri, 30 Aug 2024 15:44:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C6BC6B017E; Fri, 30 Aug 2024 11:44:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 576DA6B017F; Fri, 30 Aug 2024 11:44:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43E616B0180; Fri, 30 Aug 2024 11:44:56 -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 277CE6B017E for ; Fri, 30 Aug 2024 11:44:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D8B89140720 for ; Fri, 30 Aug 2024 15:44:55 +0000 (UTC) X-FDA: 82509334950.24.C3B1B4F Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf24.hostedemail.com (Postfix) with ESMTP id F31FB180016 for ; Fri, 30 Aug 2024 15:44:53 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eZSVTpMa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725032627; a=rsa-sha256; cv=none; b=LTndVVJYfOJK67Za6srUqkTa4haG/7YfRLxvENLOBY+GYCLVcOn+y/73PRr1jYyJ5y3+ud qQ5u4stAmaJ8G83zFFuLH/Yn3Bla8/rn0l6D/pV2JZfW3b4+IkMtZ1r49Kl31I4V6i46B+ Z7w1YgNzSjCCNQ5LDPN6aIk6QFBvkvc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eZSVTpMa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.46 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=1725032627; 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=hUdJ3tWChLbbIEYKPPb76YRhW/3TjJ4im9OWeMVWOqY=; b=v4Z1Bu7UytZB1tuNqxM4rnaxStNjzbhoeCVYjCh9821pTNrNbp3qcZjmJiSs+FLLXj8JJ9 VWH6riIlq2JgRTWRqM+Y3CCnW7oAvpJfVlsLwYdi6v2QSyAmu8BAkTImRKsWl2ag8UghQw /glVpUeRFafGDmfU0IQFQnktV2RrVNI= Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2d41b082ab8so1501846a91.3 for ; Fri, 30 Aug 2024 08:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725032692; x=1725637492; 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=hUdJ3tWChLbbIEYKPPb76YRhW/3TjJ4im9OWeMVWOqY=; b=eZSVTpMaR88MnWXQ+OQcWyRmSD+VXIQq9YHZSkBRrgbe/hsBmPqQy8aO0Yp8MNS2T5 KNhtkpXSuq2sCJLOV+a23YI+ZX6NdY2dZHpJ2tAOg+g0r92nG1QItCyGgj71hcaLU+pV kHiLqtFFPpNzPmAQCU8c9u5txZFVWEq7yap7WwwXese/Ov/UyE8dpKWoop20867pRDuw o8ktZ4msR1jaay098xW8kpiNkMznv2HvY+KDgJnCZ/T21bA8W+78bzTH/u1cdTHQMfSO ZvvnJFVwlMJvz1H30bWHc4/+3ytL85zBLyDhyDYrKhDK7vONRlUF0N5kAzzSjwSV3h0D XXbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725032692; x=1725637492; 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=hUdJ3tWChLbbIEYKPPb76YRhW/3TjJ4im9OWeMVWOqY=; b=ZQtUk9cJjy8X/pGEM7MxNgNKC9553pPf6ZoCRsMEYnHEugjkP+IiojDBwxuF2585oQ brhksWm+WZhQPa4sl5aADrk1LpNZCH2QAfOgoxVYA3TRe0OXk6IBnZ38azyjHydK4ORY A4j/x6NWdOCsT21AdFcISmGlL2KdSb5yYlQA/yDeg67Yu2jo5h/E56MW7JXDla6CuuyS NYA+eNfrKN/nSZaFQDa69bAcValtkAVANj/ylgJ2wzgtSxIBSv5uYE5f0E4dqe1LAPL1 t6QSG9myxltdCXEmYN4oVIArEIB07h6PhiKciRsaf2EYWesnxyQTVS/MJS8UMmAKtLKE mlmA== X-Forwarded-Encrypted: i=1; AJvYcCWHkd12LPJqTaAXOBnTskiLspB/3cTSKefpAnyMEhvZgJugV3o/oJ07246DVr7akfB7UFJoKENLUA==@kvack.org X-Gm-Message-State: AOJu0Yzz4fe+T0DVaZa2kZbvsrs59paUw9/lftSNnYgDPC4RnR8opDrt bcgR3lMBoUc5MUu1ALnU9VPtvAa8wpWq0G090keFNgh+ZaFbjE85WW6gT2S6AN9yHynKYfeJ0XE 8TRgCe8YiUm7NGzFsVLlWdRDAEZw= X-Google-Smtp-Source: AGHT+IH9lOOCe2rTqfIXmA2Zm8EduBS6oRpThaN24Qeaw7NMFyCeTcHthyMHP2O028nkC0WV5jBoesnEOD50qPdMhJ4= X-Received: by 2002:a17:90b:4b45:b0:2d3:ba42:775c with SMTP id 98e67ed59e1d1-2d85618168dmr7730941a91.1.1725032692525; Fri, 30 Aug 2024 08:44:52 -0700 (PDT) MIME-Version: 1.0 References: <20240829183741.3331213-1-andrii@kernel.org> <20240829183741.3331213-5-andrii@kernel.org> <20240830143151.GC20163@redhat.com> In-Reply-To: <20240830143151.GC20163@redhat.com> From: Andrii Nakryiko Date: Fri, 30 Aug 2024 08:44:40 -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: F31FB180016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 1hkqb3dfk1tnx8bk8fg7r1z1ggcy653t X-HE-Tag: 1725032693-432363 X-HE-Meta: U2FsdGVkX1+98HkRjKAMSlILkx0zpMzWsnBV9PZzFkdZkkrQXRzRLrRMzWkQJzp9GrjTDTn5R7jYs9RoDeLFLxcoPWOOO6rFPXYtH39mF+a0a6W2v/IlfDcf7cfVzP44ApA6/Wnp5V6KezyKlSeVTZ9tbJH2fE332kRIXCOmu6x0pj6dJv7b4f7lemN45l/9v3RVqrFiWatXGrZXHb+vE2pquCVLt/2Pv5RrvVL4ic7RJFKzJWp5e6EgQzfOs9PGuarPQzcwKDFqQEXRuFI3k8XnagLzwNKL5BVuohnncKEvFSp1kQUpC9fffeTuH0IXtgdIphuFHu6z01fT9O2YNWFeS1emFfpRkCgbq62r46OBKim22nyz8paJ7syoqfdyOzlmkowx6JpKBYO1c7iUpDh7s3ssyMmbtRYUjYC15NbcZ7R7Q04k5qiOcwERb5GqiOaqwgK8YYYbli4nYE4uYUjeLOPgrfyNn9VQC3fMB4/6xlx7EJ+nTQJ5h85f+jFTyhuVU0rcAlrw8Pgr9LNxJpjoMLlKFdZZVwuM1VTSq2UpgXdrKpG971XCorQjHGRJkFeFhFH2j0n0pCdIjoBHgg3QI4dAd2P7//K2uDlgi5ZVY8M+XmsvHMi3alAxg6SndbNP68UwiveUHQJ9uffA1p/4yIsn1ezUjoUmufI6n/QRCUGmXIsdAbMabFZRfUDuRWWaHbkWmhNQ8Aa2NpIo2QaD7UZGxP6q+Ygn5DLfZmkmcl6cleu2pTvPKxG83b+YVAdZsgzrBFoRDthUj6XnmFppsffKz23bLjTY1PfImlfqgsrJO5+kEmNejpNtT2PNVbFe4PCczpTYNymoWucjp4rnzQFbRquNHETHtrxxh1O40TlzsbfI2DuMPgDv6LYyNCUMOwUjBy3rI9emJ7GDepBRtgEyXXvDOes+V+k2b8C2ibhnZnRsbNh3ck902+F9zk3ihPHCJoNSHAmRTJO CgQVs7/2 1hKC+dOkCX4TEHgX5qALlfUKFOX1sasjHgZ0w+o+hCameiy/2xG6wwCTcijX4spD3MrozBCigTWHhv9sAIizDFRWFMBa9+PMksj22p3Si5nBiwa/+3gWHiV/HAaCY9u16uk3Wzh8BzN5vIlI0Bzx2E+yip/u8ycd3zvuMvdlrE5ZLusnDZ3X7re4IhZBiVIggdd0/CoQ0NjA2vQj/6zCmMfxC6IvebPv6KTZfqefFBniIg3z9/fafWbVuSgv7u2kt7zSz670rRDnvAYRMdaC7jcwr27axQSoy4YkRsUYUnFKgtfl/mFhL9t4Est57fLNsLzwBjvFLuCj+TIs2ZiGBdKkeba5f76FAL8ox X-Bogosity: Ham, tests=bogofilter, spamicity=0.000310, 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 7:33=E2=80=AFAM Oleg Nesterov wro= te: > > On 08/30, Jiri Olsa wrote: > > > > with this change the probe will not get removed in the attached test, > > it'll get 2 hits, without this change just 1 hit > > I don't understand the code in tools/...bpf../ at all, can't comment, > > > but I'm not sure it's a big problem, because seems like that's not the > > intended way the removal should be used anyway, as explained by Oleg [1= ] > > It seems that I confused you again ;) > > 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 sent 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. If it doesn't provide filter callback, it doesn't care about PID filtering and thus can't and shouldn't cause unregistration. In ideal world, we wouldn't need handler to do the filtering, and instead generic uprobe/uretprobe code would just call uc->filter to know whether to trigger consumer or not. Unfortunately, that's a lot of overhead due to indirect function call, especially with retpolines and stuff like that. So I think it's reasonable to have an (implicit, yeah...) contract that whoever cares about UPROBE_HANDLER_REMOVE has to provide filter, they go together. Jiri, the fact that uprobe/uretprobe can cause detachment by returning 1 is a bug, we should not allow that. But that's a separate issue which we can fix in bpf-next tree. Please send a patch. > I think the fix is simple, plus we need to cleanup this logic anyway, > I'll try to send some code on Monday. 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. > > Oleg. >