From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4969147F2C3 for ; Wed, 1 Jul 2026 11:57:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782907061; cv=none; b=Fa7MtyqieflaKJeUhLnfACU3zI1zM36c4n8Dc68RFAFvKudg3QZIGutzJc5NpsAyu80YapKBH6/JSsJh4nC7tbhGiKcmvO2bJeG6QSWgixWTnOooSRDM6m89sDNzZ1jp4c+0IbdXOJ8pFT0MC9nn86+v2dV5KMlpUV1Rb/6Rj/0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782907061; c=relaxed/simple; bh=GKzO/WyD4D/mbF6c/AmcKtFnDY+JtxUxoljaWdrLzQM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=ctM5I44X+1DUYgGFzNYDiEspkB+foswR6eqFw37O3zkL8Zs30lGgTJLnaP9crDSVWbdPtnwoiFT4GjX1Wf4fgLkNjBQmMZ/n3ijkpmAj+vKgehLU2o0+Bv2T5WAA6fSordRIx8rFzYgs3xFkaSVQ3WxAq1XKiN1DFPMGxnwFIl4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BCRfiuGT; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=ejW8fH8e; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BCRfiuGT"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="ejW8fH8e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782907058; 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:autocrypt:autocrypt; bh=GKzO/WyD4D/mbF6c/AmcKtFnDY+JtxUxoljaWdrLzQM=; b=BCRfiuGTz1IWWojtrUD5hXc8iS21jXrM4Gawmi4DzMQbaQXLkNyIki2d0uEmJTgpGfIl+D wt4qecQBPTXd6llCoes+saQE+V6rN3M/+0HAIM3WwwAhmIHXo5P/JoF3TaB/2AUC/hU/YQ ukva2t4iqHWuZXe32kApEeIOixhFb3U= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-341-Y3ybM2MgMc-oV3ETlcjGpw-1; Wed, 01 Jul 2026 07:57:34 -0400 X-MC-Unique: Y3ybM2MgMc-oV3ETlcjGpw-1 X-Mimecast-MFC-AGG-ID: Y3ybM2MgMc-oV3ETlcjGpw_1782907053 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-493bfc3b84aso3934675e9.0 for ; Wed, 01 Jul 2026 04:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782907053; x=1783511853; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=GKzO/WyD4D/mbF6c/AmcKtFnDY+JtxUxoljaWdrLzQM=; b=ejW8fH8eCpAq35BWL/QKVWfgvz/mYG3e833/YJBwAPKT/xnACS87q1FpZ/prE+WLX6 y+lFLxnzFX+D/sKJphI+iC/9s06+utvHXCeiTRIA8Wg5j5dHHR0MDinfiQsOqTSbLDA6 5zHTNeMeiN8LVE50OGRWlZr6DDpUrdr3QTjVgbb00/JVYtZjPXl8NCEknDye2SMjZ9Jg Y/RrIMXym8cd+4xH7sXt5MBPZRPOq9tIfBoze18uuW+n5WAomJaDNNyB0tIw/x6LAD6m /0nzIMoqBMbU/+anmuw0cT5SLtz9eEFZH4XRSWY6TV0NDDQwJntx8/xCnPGnz2K115ST A5Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782907053; x=1783511853; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GKzO/WyD4D/mbF6c/AmcKtFnDY+JtxUxoljaWdrLzQM=; b=crBJ6IXgdBjDjJTZAW2LnYyxKHwG48YcYLUePhU/186QhAG5YePgC+LJjoPmyrxGPz eH9SpjZ53TCIpvCcO4eY/T7SVVfgw2KWNXE5K+DToA3NwcfW87QHGwGTOBq8qfSdEoC8 CixlEpIOVChM/JW/JRh333IwLVoYm949BXQucw2+Ackq8nOwlM/9Oh4WyAhw/aymU579 JiXjSNXIgjWZa/KrgqAMIhkdbJllbv/h9cplZ5ccG8LyvNxTE+K//n+DTzNYWVfndNkB KOR0ExdQYVFUUB2hXwjly0FXYe+jXJZutOW4IC4KOM+aubhFudJgE591tjLmU/wi+chR VlKg== X-Forwarded-Encrypted: i=1; AFNElJ+4nS42qvNiY9ehJaZu4G8qx2AGBiA7jE6+VZqlnIw4yGc6L9Wrnj7yyBCNoyfdCiPgnjZixgriVbWHAl0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx7dkKS2XcaFJNIlUUHkOUQs1eYrL1KLepVVE4J3DTEQbLXeV46 1Ua1WjEdLpaY1P6zU6FcyGywq+RkwTCznqC7HuKjH48GbJjCbD6BvvhJvOMb6yByvX7yrTxg+iL Yh7MzBVirz5/8gYHyP/KaLzzWZg4x11bS2za1Vl/qiOOCf0df0SsvEkMHJSLHfUIQzQ== X-Gm-Gg: AfdE7clpkGzcaqYRFHbvnUfYqpgyGLy3aIJ9LssZOdMhDQA6gV23RArvm15Ep5ymlHU 9bnWkNUJMIYZg/B2Gp+J6bSLVgVJu8j0vfY0mGU+fQu3sA9VORh9hI+0H1CT/3b8TQA6A0pWEI1 +vsoz+eE3rJ2DT2N8fChuA52B8tu5SCrqYEMfHcQxgxA5oyAMEl2IJjJUY7VtX3hrQACgAuFJyD zkEAVhtnw+ujQoXuelDnPrz4HTcr8s8CnVfWVJceqMFY9/MXOadFD+wWeiKPNAbudb2RW5SdLep pTk5loVyZ9vdrJi73JvJY6BmlgPiEqbX/doaU5pGj0o96ABvAd4FtkeaGQfc2kx+Pz9I6tuIZjy B6m28eRjzvX2gKt3YoRFmcRVNQaUQEnAwkr4dsCOmJzScE4stjxF2Mjj71rZwRfHDDlowd5hMfD j2K1O/ X-Received: by 2002:a05:600c:35d0:b0:493:c3cb:409e with SMTP id 5b1f17b1804b1-493c3cb42d9mr5624695e9.15.1782907053486; Wed, 01 Jul 2026 04:57:33 -0700 (PDT) X-Received: by 2002:a05:600c:35d0:b0:493:c3cb:409e with SMTP id 5b1f17b1804b1-493c3cb42d9mr5624465e9.15.1782907053164; Wed, 01 Jul 2026 04:57:33 -0700 (PDT) Received: from gmonaco-thinkpadt14gen3.rmtit.csb (212-8-243-115.hosted-by-worldstream.net. [212.8.243.115]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493be810be8sm67046565e9.9.2026.07.01.04.57.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 04:57:32 -0700 (PDT) Message-ID: Subject: Re: [PATCH v3 2/9] rv: add generic uprobe infrastructure for RV monitors From: Gabriele Monaco To: Wen Yang Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 01 Jul 2026 13:57:31 +0200 In-Reply-To: References: <9d1a1d491af16853b2b421f358fd6cca965588ab.1780847473.git.wen.yang@linux.dev> <878be1d4-2f93-4fbd-a1f6-b2b7836c9c44@linux.dev> Autocrypt: addr=gmonaco@redhat.com; prefer-encrypt=mutual; keydata=mDMEZuK5YxYJKwYBBAHaRw8BAQdAmJ3dM9Sz6/Hodu33Qrf8QH2bNeNbOikqYtxWFLVm0 1a0JEdhYnJpZWxlIE1vbmFjbyA8Z21vbmFjb0BrZXJuZWwub3JnPoiZBBMWCgBBFiEEysoR+AuB3R Zwp6j270psSVh4TfIFAmjKX2MCGwMFCQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgk Q70psSVh4TfIQuAD+JulczTN6l7oJjyroySU55Fbjdvo52xiYYlMjPG7dCTsBAMFI7dSL5zg98I+8 cXY1J7kyNsY6/dcipqBM4RMaxXsOtCRHYWJyaWVsZSBNb25hY28gPGdtb25hY29AcmVkaGF0LmNvb T6InAQTFgoARAIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgBYhBMrKEfgLgd0WcK eo9u9KbElYeE3yBQJoymCyAhkBAAoJEO9KbElYeE3yjX4BAJ/ETNnlHn8OjZPT77xGmal9kbT1bC1 7DfrYVISWV2Y1AP9HdAMhWNAvtCtN2S1beYjNybuK6IzWYcFfeOV+OBWRDQ== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-07-01 at 02:44 +0800, Wen Yang wrote: > Thank you for the patient explanation. > You are right, and v4 implements the embedded approach. > struct rv_uprobe directly embeds struct uprobe_consumer: >=20 > =C2=A0=C2=A0 struct rv_uprobe { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct uprobe_consumer=C2=A0 uc; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct uprobe=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *uprobe; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct inode=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *inode; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 *priv; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int (*handler)(...); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int (*ret_handler)(...); > =C2=A0=C2=A0 }; Alright, great. Why are you still using double function pointers? Do you re= ally need rv_uprobe->handler instead of just using rv_uprobe->uc.handler ? That = also simplifies one function call down the road. Thanks, Gabriele > rv_uprobe_free() is gone =E2=80=94 no allocation means no explicit free.= =C2=A0 After > rv_uprobe_unregister() (or rv_uprobe_unregister_nosync() +=20 > rv_uprobe_sync()), the caller frees the containing struct directly.=C2=A0= In=20 > tlob: >=20 > =C2=A0=C2=A0 rv_uprobe_unregister_nosync(&b->start_probe); > =C2=A0=C2=A0 rv_uprobe_unregister_nosync(&b->stop_probe); > =C2=A0=C2=A0 rv_uprobe_sync(); > =C2=A0=C2=A0 kfree(b);=C2=A0=C2=A0 /* frees both embedded consumers */ >=20 > This is the pattern from your sketch. >=20 > Regarding my earlier reply that argued for the separate allocation: I=20 > was wrong. The key barrier is synchronize_rcu_tasks_trace() (called=20 > first in uprobe_unregister_sync()), which waits for all=20 > rcu_read_lock_trace() readers including handler_chain().=C2=A0 After it= =20 > returns, no cons_node.next read is in flight and embedding is safe. >=20 > We appreciate your thorough review. All of your comments have been=20 > addressed in v4. > We'll run local tests for one or two days, and then it will be sent out= =20 > shortly. >=20 > -- > Best wishes, > Wen >=20