From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id p/koJLDavWgHfjAAWB0awg (envelope-from ) for ; Sun, 07 Sep 2025 15:19:12 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=lists.lttng.org header.i=@lists.lttng.org header.a=rsa-sha256 header.s=default header.b=gXc9fexr; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1D9951E0BA; Sun, 07 Sep 2025 15:19:12 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from lists.lttng.org (lists.lttng.org [158.69.130.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 53FA51E047 for ; Sun, 07 Sep 2025 15:19:10 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cKfyb53rsz1fXK ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1757272744; b=Kd8A2bmHMTS5q+V3p/Jz0/Wyx0HnCYbyvVBiWtQ9+2n7QBP9HrDVbRryhSd4JxHDI0U6 qsOehbDlYYEUBrkD0kefHkv5bhb1tueoCXt72IQ96hKIXqOhnJH/9dVUTN/tc1Q9YAgNp vYmxkrlgIpF4Gi96xnEOs0EFJOfP85R619dODKBZswHizNQ+KS4en5d0yZvsvn3EuDytI zuF4+M0Ye63hQs4uniPlrE1/bRSZJ2tL3FLOvOpctLzXf5Jst44WD4IoWA55TjbbiOMv3 P6Ey7m3PaEi1U8IsCzZDGZeJ5FKGi/0Y0KkNdaL48DIUqdz80tnXdfLm9Ik7UI3i9ow== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1757272744; h=DKIM-Signature:MIME-Version:Date:Message-ID:Subject:To:From:From; bh=x2vPiAdHsnK6Afv431v+Wp2UdjvEB3fKnC9rai9j/oo=; b=TCA3Rcphd63Fh9oG+3kLkIyQ4oJ9x0eyLPBYBmwdv+EoEWBZHTw3kq32sFQUXlxCpQs6 NDW56T/fDYW3eBO2Lpwvms8kTg3xhtsXqtDRAvKn07H4U9GKvHCqhNlQMF9L36TXyfcda U9+Tssl+onw29u2yE2aKX+6oUmA++qaWx11pj54hkVJPl2GbSgRfEBs8PIjkuFV+NMqCx Kpo8aK0jK8OhJqeYmbf6DRtJ50fAgdYSsodgN6/nFY60TK85Ptcarloe6qqKVv4arRy/2 4t7IYQZ+51XIi3+ETQwwzPCr2usOfrssBHve2qNhplCts5m7a5kDZpO4KQkHMX6GXKA== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cKfyb53rsz1fXK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1757272744; bh=x2vPiAdHsnK6Afv431v+Wp2UdjvEB3fKnC9rai9j/oo=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=gXc9fexr5QYxFHuj2jvqaCuEam+zpP14/NjtTNkb7e4HD9jUB/ZxFhCQ8VtvR0dIJ rR98VYDAdjEVZqGukAUZSzIHz1aq7kixsl1lZ31BkHwwG3YiaDRQmksWT4jwxx5WOz ul87Rbqcpn7j2p53kgrCt9b3mKVTdCpai7X2J0RA6SNzR/AetgLgtjbsuukAMTDQYS YAnLCi/vWqnkAAjDmisiGIu42D/rl5EsCOP2iU7TVHJiFIKAvkJ2rwxIYidFXUubZa QNN8k6Vdp1b7iY95W/tl5N7Q301rbaeUNuHngkrLSrIZNS0D56YjUveXfDWiA9Fa0I G9g0K+ZXHAaHQ== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cKfyb53rsz1fXK; Sun, 7 Sep 2025 15:19:03 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cKfyZ1PSgz1fNk DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cKfyZ1PSgz1fNk Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lists.lttng.org (Postfix) with ESMTPS id 4cKfyZ1PSgz1fNk for ; Sun, 7 Sep 2025 15:19:01 -0400 (EDT) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b0473327e70so605550766b.3 for ; Sun, 07 Sep 2025 12:19:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757272739; x=1757877539; h=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=o5fo9lI811FlGlxrBNWAKhB8plMB3WAMl7UBKdtjvps=; b=d6dV2oPyJZGAZIfsO/ZssOharUhzG9UZrmYEJxIDKN5k5nlpXLxdrtg0ckPIfPzUsy mX4WqJ7DmIC/Ifo9AcyIzrX+jOczhkdCSwVt5r3cRbJ1LRIbw/rMTHpGrQaZrsDABTDk Mzh2E0pXzweyq6RYgf8RGLqabnZgJl2L7+svSVYQbNg9WZXryy8z5DFzoZrom1J8DQz/ L1lNBS8ZGGJxptfBgmfw9RW5Js+6iBU7K//xpXCjqxGnjpzAu/J6Rx4iPyzw+CZaDH6P nbsr3oJmfdx7eQEmL3/vNbQ3zfYjDz1gzR02oJihnpejvwkMbZov860ERlLdwQnfAsHS 91Bg== X-Forwarded-Encrypted: i=1; AJvYcCVcIcEwHUirI5fKOdurIz6DfaKnNfzN+hB9VFH9SOdBeM/G/QSlFix/iwA/8U2peTGokBb2IufSSW0=@lists.lttng.org X-Gm-Message-State: AOJu0YzpGp8yPFRvSZu+hnYOZZ+nkuAybbSPy08E8f8VApNazRDN0Gw3 ImZnNwqrf4A7cblrFfKJgAPKWqyAgNBoPTqyP4FTpzkH5evaD4R6RIXsQHIqu0lNvEc8O4ko/cc +b4jtPxIWRJsg3CRpyT5R3DyN5xXYjpc= X-Gm-Gg: ASbGncuv6njKlpIm5x097TV59PHEQyCSpG6krHdT9XGAOXb7/Q0of4eIsVzR6lFOcrX srFnDS0mGsOEOjgRx1/oCpzfFDc5EgpWczWEiYQvGvGVhXKBkBN0D7AyZIJZCrrZvBVLHtQOK45 net+EwimPxkcGQsGb/EU7Fs+wbCCGz2Lkrwfcsuk4w2xWNDcRTE5dIQ7f5+R+EmuGeCXm8nAxv4 gtqXzoWjsLPDxE= X-Google-Smtp-Source: AGHT+IFIXe2ZA2NrZjPsKUnOf61+58RUm6FmlLmu3wn6617nRf5dxUXdv8O24pjTf17jiSqtANkElFvPF/vBio3D2ps= X-Received: by 2002:a17:906:d555:b0:afe:dbfb:b10e with SMTP id a640c23a62f3a-b04b16baf46mr473334166b.47.1757272737892; Sun, 07 Sep 2025 12:18:57 -0700 (PDT) MIME-Version: 1.0 References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> <87h5xg7p3u.fsf@laura> In-Reply-To: <87h5xg7p3u.fsf@laura> Date: Sun, 7 Sep 2025 21:18:46 +0200 X-Gm-Features: AS18NWC_obJtcN6CgWf5gMqO_bGiiDTzo47VuiFBNmtHMd_wfJMuENjAifDmwPs Message-ID: Subject: Re: URCU feature request? To: Olivier Dion Content-Type: multipart/alternative; boundary="00000000000050ccc4063e3af15b" X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Thobias Knudsen via lttng-dev Reply-To: Thobias Knudsen Cc: lttng-dev@lists.lttng.org Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --00000000000050ccc4063e3af15b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > It looks like you want runtime verification for the usage of the API. > Did you know that URCU can now be compiled against ThreadSanitizer > (TSAN)? If a user misuses the API or makes incorrect assumptions about > the guarantees offered by RCU, TSAN will most likely detect those > issues. Coupled with the other debug features we already have, this > makes it very hard to not trigger an error path when the API is used > incorrectly. Really?! I've used TSAN and got a bunch of false positives, I believe, but maybe they're not false positives? How do you remove the false positives, or know that they're not false positives? > Note that certain kind of errors could actually be flag at compile time > with the proper tooling. For example, the Linux kernel uses a `__rcu' > attribute that Sparse can understand to flag improper use of > RCU=E2=80=91protected pointers. I=E2=80=99d be very open to exposing som= ething similar > (an attribute) for static checkers. wow thanks for the info! I knew compile time checks would be possible but requiring compiler operability which is a higher hanging fruit for me. Is '__rcu' compatible with custom concurrency? For example rcu_dereference a pointer then locking a mutex inside the pointer then unlock read then continue using the pointer? I cant come up with something usefull other than a language rework. Is it much work making the __urcu attribute? fre. 5. sep. 2025 kl. 20:04 skrev Olivier Dion : > On Thu, 04 Sep 2025, Thobias Knudsen wrote: > >> I am confuse about the overall discussion here. Are we talking about > >> static checking of RCU pointers usage or runtime checking? > >> > >> Is is possible to see the implementation you made so I can understand > >> better? > > > > Sorry for being late to answer :/ > > The library overrides a subset of urcu and lfht functions with macros a= nd > > replaces them with other functions which checks in runtime if the > functions > > are called in the correct order. > > here is the code: https://github.com/ThobiasKnudsen/urcu_lfht_safe > > It looks like you want runtime verification for the usage of the API. > Did you know that URCU can now be compiled against ThreadSanitizer > (TSAN)? If a user misuses the API or makes incorrect assumptions about > the guarantees offered by RCU, TSAN will most likely detect those > issues. Coupled with the other debug features we already have, this > makes it very hard to not trigger an error path when the API is used > incorrectly. > > Note that certain kind of errors could actually be flag at compile time > with the proper tooling. For example, the Linux kernel uses a `__rcu' > attribute that Sparse can understand to flag improper use of > RCU=E2=80=91protected pointers. I=E2=80=99d be very open to exposing som= ething similar > (an attribute) for static checkers. > > [...] > > Thanks, > Olivier > -- > Olivier Dion > EfficiOS Inc. > https://www.efficios.com > --00000000000050ccc4063e3af15b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> It looks like you = want runtime verification for the usage of the API.
> Did you know th= at URCU can now be compiled against ThreadSanitizer
> (TSAN)?=C2=A0 I= f a user misuses the API or makes incorrect assumptions about
> the g= uarantees offered by RCU, TSAN will most likely detect those
> issues= .=C2=A0 Coupled with the other debug features we already have, this
>= makes it very hard to not trigger an error path when the API is used
&g= t; incorrectly.

Really?! I've used TSAN and got a bu= nch of false positives, I believe, but maybe they're not false positive= s? How do you remove the false positives, or know that they're not fals= e positives?

> Note that certain kind of errors= could actually be flag at compile time
> with the proper tooling.=C2= =A0 For example, the Linux kernel uses a `__rcu'
> attribute that= Sparse can understand to flag improper use of
> RCU=E2=80=91protecte= d pointers.=C2=A0 I=E2=80=99d be very open to exposing something similar> (an attribute) for static checkers.

wow than= ks for the info! I knew compile time checks would be possible but requiring= compiler operability which is a higher=C2=A0hanging fruit for me. Is '= __rcu' compatible with custom concurrency? For example rcu_dereference = a pointer then locking a mutex inside the pointer then unlock read then con= tinue using the pointer? I cant come up with something usefull other than a= language rework. Is it much work making the __urcu attribute?=C2=A0
<= /div>
f= re. 5. sep. 2025 kl. 20:04 skrev Olivier Dion <odion@efficios.com>= ;:
On Thu, 04 Se= p 2025, Thobias Knudsen <thobknu@gmail.com> wrote:
>> I am confuse about the overall discussion here.=C2=A0 Are we talki= ng about
>> static checking of RCU pointers usage or runtime checking?
>>
>> Is is possible to see the implementation you made so I can underst= and
>> better?
>
> Sorry for being late to answer :/
> The library overrides a subset of urcu and lfht functions with macros = and
> replaces them with other functions which checks in runtime if the func= tions
> are called in the correct order.
> here is the code: https://github.com= /ThobiasKnudsen/urcu_lfht_safe

It looks like you want runtime verification for the usage of the API.
Did you know that URCU can now be compiled against ThreadSanitizer
(TSAN)?=C2=A0 If a user misuses the API or makes incorrect assumptions abou= t
the guarantees offered by RCU, TSAN will most likely detect those
issues.=C2=A0 Coupled with the other debug features we already have, this makes it very hard to not trigger an error path when the API is used
incorrectly.

Note that certain kind of errors could actually be flag at compile time
with the proper tooling.=C2=A0 For example, the Linux kernel uses a `__rcu&= #39;
attribute that Sparse can understand to flag improper use of
RCU=E2=80=91protected pointers.=C2=A0 I=E2=80=99d be very open to exposing = something similar
(an attribute) for static checkers.

[...]

Thanks,
Olivier
--
Olivier Dion
EfficiOS Inc.
https://www.efficios.com
--00000000000050ccc4063e3af15b--