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 16EA1CA100C for ; Fri, 30 Aug 2024 20:21:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 646B26B00A3; Fri, 30 Aug 2024 16:21:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F7CA6B00BC; Fri, 30 Aug 2024 16:21:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4971B6B00A3; Fri, 30 Aug 2024 16:21:21 -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 20E366B008A for ; Fri, 30 Aug 2024 16:21:21 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6BE69140518 for ; Fri, 30 Aug 2024 20:21:20 +0000 (UTC) X-FDA: 82510031520.26.17EBF9E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 3B6944001E for ; Fri, 30 Aug 2024 20:21:18 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fwcyUzDE; spf=pass (imf11.hostedemail.com: domain of oleg@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=oleg@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725049232; a=rsa-sha256; cv=none; b=x+UlYKBR3e6L6MGt+ShwWKEprBdwNcL1V5xiquOdzuvAVUrHuNt1OjUNejOzlYaGwYJ2mW dMC0BcC5p7ne4Yit4fFXq8VRMa+UfrAjwss/wwP9JlFmf6+P8BgLUCMjJeZ4JEcISMFZkr MaeJc1uyl/AuTbQZs4N2kYVu4u7UgGM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fwcyUzDE; spf=pass (imf11.hostedemail.com: domain of oleg@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=oleg@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725049232; 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=tlG9Z3SWZS45Au6orXQjCifgDXL/6bzfSjTyzN+bf2c=; b=AaI0OSmqsxcpUhAsJ3Ihthe0+wwxnWhzOmKDuVVRc/VWwQ95wK29PdBz740GAOP83YnKHi pbKfuQHPYtuNXd5mBrwanTPgVa+G5iK+/sV9hmbjXS2U9ZpwiVq+gwAHSqoDyORxfZIzpj cjIluZzJuVHGj82Syo/gkshzYaaCECM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725049277; h=from:from: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; bh=tlG9Z3SWZS45Au6orXQjCifgDXL/6bzfSjTyzN+bf2c=; b=fwcyUzDEK2UzmzGSpTxAYA5B3wWwE6pTtNdMUPWeWz8vDag5sBxbWZpAbkVINq/sKGW7Bn Fe8vITojHcLedpbON98cM9ycSlRhSOhFmbb3fS3xa/cPWlJa8b/WoO5yRbdO2Zl5EDKoCC ey8v+O5AvgrDfvNLGwXFf01z8e5m5FE= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-54-H6sJ7imwP5qkwnjaTwy5Iw-1; Fri, 30 Aug 2024 16:21:08 -0400 X-MC-Unique: H6sJ7imwP5qkwnjaTwy5Iw-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DA2AB19560A6; Fri, 30 Aug 2024 20:21:05 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.45.225.148]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id 02C8119560A3; Fri, 30 Aug 2024 20:20:59 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Fri, 30 Aug 2024 22:20:57 +0200 (CEST) Date: Fri, 30 Aug 2024 22:20:50 +0200 From: Oleg Nesterov To: Andrii Nakryiko 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 Subject: Re: [PATCH v4 4/8] uprobes: travers uprobe's consumer list locklessly under SRCU protection Message-ID: <20240830202050.GA7440@redhat.com> References: <20240829183741.3331213-1-andrii@kernel.org> <20240829183741.3331213-5-andrii@kernel.org> <20240830143151.GC20163@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Stat-Signature: hx9gynicw7mamym1353tgaqptztybg5j X-Rspamd-Queue-Id: 3B6944001E X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725049278-110555 X-HE-Meta: U2FsdGVkX18gXnwVGF8HzcHplBeOfILR6XIQu59i+zqmXmznub8VJlfRYQKN26ZxygGH70L9cPGQNZb0MpeovwrN2BOPDUsX0TJLKDDVD2MDp38qz/aiDUQ3APDZ40Vw00Q6/vlDgWVilEKyL+6AhAeMZMPnrh7m52pw3A8cNOPlVyximAEEplwEEzvrphewINlx3pmTyB7MX3OLqEV5tMVbNMt1vSo6qvR1L4R2sAxSqHaF+6skl6biMu4HW/ShkF47jlY75M75BA6ICe210509diKyWiZ8hHby66bs0P20SB2LehoCffV6BT304iBR6Wmfx2TeEkR021uW0eHWDIKaqg6hR6HvKnccYyVfqbncSoZK8tnER/8BQyQ78TMBZvNTxnTJzXp7nNC86ax8wzOuxRnEuze8pduRQNzmLVVOB1FxeLVoePEC9Ahb2l9sTJDW1qqivbivn8pN/D8zoG9rSaQdwevLoVrmU8dVx3ft9FWHUeVRGVymw5A8Yr1S/94a91/BhzIrHHS9ep2eHLlfbLwXzJgJSzXc/grXsJDIL8Oxxzlbdi+SPvfP5d7SioxrA/m0bI6CriqPmd2xDR1xnOJxgoMH+2erkPymZZ9I0AxMMduvhUhfKD8AEKUsLoNYhMWzZbJ05qxCTrzbX6vOvt43TKNWmn2bEYLmGFu8ZZUAPF8eHDqeuwAtD6OiyX8liKtiWp91jzGBfdiu9YTALIF4BmqgzEtP6hcm1pRwfSKXJR6lBBKoIbCdFMTH7NBpNkGdjq5Key92iliYlVP+cTmcUYpF9RrFeRYtN2973BGmMLTGw4mjLctTwR1W7WH4TW9jqoMxDe9H2GOuj63Tk6t0jz1DBblIt4oq8r75QuruFLKXkmZINGb5iK0e4HyKSOgMgo2Xh9dT7s8JtaFQn2fVoTCK0fBoiPiTQoACQRR3YQA9n4eDm6stQm0jcDVDVb8DI2jOZ7gURWk tR7uOEDq ePGpl3kvzwJzLAJqOQq7woi4ffHB+N/xt/MsOVhpXeeEPq7ueV0LJ4l7aYveQmNJSVPBjfL39xcODQ2gZxIjdIIMgTm/UHWpeqaVHyMF/weSswHEiO9Sga3NwSeES05GhogoynfrTklSbyd//eFPfEn3hZmtMzNSy8n/9nni75OAkGrj/LCrizNog36GehdjksrXvHG811BAJIe5mSffV0Rrh91DZQcBIGr35I1WTeSJlzMLzWkGVG24ZEHY2CDpXKaY/AZdYLXXu5iPHCPLHETga456OMqlaBVGXPCTXAtqo4ZFA8OP2fNda/HEFpg/iDXZe0ZVkPxureVEOJUlshsJrJFLMJ6/Noln3d9qFPKeK4ovrjLKoTP1rONGa/Ezjp6vmI4e+Nw4Hy89t1mu5y2/bMAI7PFoSJKuEbdQDJtUmuZW3VhVLtl+c8g== 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 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. > On Fri, Aug 30, 2024 at 7:33 AM Oleg Nesterov wrote: > > > > No, I think you found a problem. UPROBE_HANDLER_REMOVE can be lost if > > uc->filter == 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. 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 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 work. But we can do other things which we can discuss later. Oleg.