From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kca8GS/AzWhA5woAWB0awg (envelope-from ) for ; Fri, 19 Sep 2025 16:42:23 -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=mx header.b=AXigk04B; 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=Z680ChON; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 612581E0BA; Fri, 19 Sep 2025 16:42:23 -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 m228-15.mailgun.net (m228-15.mailgun.net [159.135.228.15]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with UTF8SMTPS id 6ED511E04C for ; Fri, 19 Sep 2025 16:42:21 -0400 (EDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=lists.lttng.org; q=dns/txt; s=mx; t=1758314540; x=1758321740; h=Sender: Sender: Cc: Reply-To: From: From: List-Subscribe: List-Help: List-Post: List-Archive: List-Unsubscribe: List-Id: Content-Type: To: To: Subject: Subject: Message-ID: Date: In-Reply-To: References: MIME-Version; bh=Y1dcchnK1Z06eTTk3lp24wICQeoMkgH3XRWNOHVHYRM=; b=AXigk04BkJ4klyU/G4dCNEKrH/hu7oH9GaZ8waj+HRAn+aXtvfaIrKzVL0afHIYV3uvBAI/tjzeCxnE4Wgg36I6SsNdBY45TLiNrHYaBnVdfeneGZoRX1hhGtE6/y37l++8b+BmWTgWl1DTebUIENAD7+ALq9S26Ky6Zi/wXLfxRWfj2128cJ7HgVj6ZGGu6/eibmlfU8PrxWI6SdY2lPc9uK6pKwXf2LhmsejHSwHKPT/YGZIdCYNM4BtiyLyTOe7WEqcjwlYBjicKardBWQGaMcqFExJOtHcK8dJIaT6bISoTdwaSJ3NoORqwggL3xmSmvd9uNBl8ufxJlyJiGeA== X-Mailgun-Sid: WyJkOTk2OCIsInB1YmxpYy1pbmJveEBzaW1hcmsuY2EiLCI2MDIzMjMiXQ== Received: from lists.lttng.org (lists.lttng.org [158.69.130.29]) by 4a34b115784c8085b5592da04f64c4dc0f7f102ce2f9ebe3a826917f619beafe with SMTP id 68cdc02c09daa9397e77b231 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Fri, 19 Sep 2025 20:42:20 GMT X-Mailgun-Sending-Ip: 159.135.228.15 ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cT4F83DK9z16nt ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1758314540; b=D1y/fIPwGRLDBy/UWG1YL04OtsmQosfZ2xgsi7lchLDWrhxEgnB7HxY+bxoNrBAfx043 2A8xeZRv6jRZ5I422Uvx88scuFeuSKSQmk4snG6bQ36/N5Vg/HPxk15dcx+vkQGmHRlBA 6rZ+XnZa7woyyZMbZG5gsnUYC8/lkJUFLMYhBTe4mtaVlo+oMcmGqu2cOtrYacB7O4ho0 nMgL4sjjj5b/z6750EJPslr1FsKLXNFyD6d6m++3hG1g8Yo0SdZ2+LFpQ6vP42s8OBYlI SG2nDgCN9S/oEGrDSO2Qj2l256oXu4RaOMEMqMFUQChJduswqVYGgV/GclXwgNVcw5w== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1758314540; h=DKIM-Signature:MIME-Version:Date:Message-ID:Subject:To:From:From; bh=YpataeHCm8az2en+hO3Fho1oiHNVes5WguqK0UNgCuE=; b=QW2IEM/iZ9cR81WkdZFhq8Fsi8pL3mELyszDMbXWUySvZTEd01ZlcGoVnqZ4tezplgB5 T+3vj5ufvNpb2diXB36w61GUUlNIrm6oK+mAG7E5QFn4VEih2OfltGyXm+/BOQOWw4V2V ux98oMaWBqVdDQKHX0dfafL5s/YG3U5v6qG3h2KMaUO7NWslFWn+etCvLX0Fmd9c1OGDq ZiAwtvb9qAScftuMVkZfgHO3cX2rfAIU0puvCQgZAqIzdEYExVb9dn/E1ycgFl4K8CFtn NGQ4y/xG1GdxhN4GtAnPwOWkv2ttpbuqM1KeanNZmkbz6sfWLnVfqeTkFKut8Ifwf2g== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cT4F83DK9z16nt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1758314540; bh=YpataeHCm8az2en+hO3Fho1oiHNVes5WguqK0UNgCuE=; 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=Z680ChON2IigyTY+GKosOISHtfte2p9wFnN8lNAS62QvKlgx2krO+B0lxUgMvfK8D edqm8TpWGVPgaYlgcnadnAsztPrbEBK34TLLITkWZOigjGt94FKNGsbz2rOjN0WPXH FRbWzZBQhoZ3wPZxMnJnU0ANNMppJ95EAMe4GiWvg3YUljbJgV0c59o4Y9wRI8t8Vm QVv3ZjgBS34ChPSVeJQ2/QBuMrzhXgcjcTV3nrCVYcf0xL9+uGzr4/lrh2C3OkIyxF EGKHRMGshZfMPJkG5RjRHiKV1tu7c1t30oXMOrAseGGOzxDJkkXITEpFzm02ZdOY/t vrKCXWJ03oV0A== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cT4F83DK9z16nt; Fri, 19 Sep 2025 16:42:20 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cT4F75Lf5z16ns DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cT4F75Lf5z16ns Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lists.lttng.org (Postfix) with ESMTPS id 4cT4F75Lf5z16ns for ; Fri, 19 Sep 2025 16:42:19 -0400 (EDT) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b042eb09948so436331266b.3 for ; Fri, 19 Sep 2025 13:42:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758314538; x=1758919338; 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=Y1dcchnK1Z06eTTk3lp24wICQeoMkgH3XRWNOHVHYRM=; b=qIUZGczbsySg0z8oGZB151SPy76hbAypySSYPwxtbBa7Egwbm1sV6nRiw/B4vrzgcW ZyOtprrA7o6+YRw94FDZbbK58Qv4f9WHSEZbZwRlONN2vdSplCvyuV/1PxGc8jaqQTpg 6eRTAv43xCzgy5AHRrdqXB1+eP+j5usADJ0eURKYSsp/AdL84+UqXig7UdVS9eTWeKtk 7R95RBB6p4NxrFagVQFLpcbCf/yNvaD9+yZIxQdGV9FRUpvMzUowDivjSK7TlLtDDvCU gSe5I8ca+3or2TcMT+T6BIDor8hb2IQQZCvyHiByxxY0sj/zqJ/SzuzkOqhHEkjlAJPd d0Dw== X-Forwarded-Encrypted: i=1; AJvYcCUIHFs4+5NKmdKq/VumY6hhS1mxKO8JFK+fyFNY4UGBPan3HXJW8mw07rZkrNmkRY+EysJ+G0Kr330=@lists.lttng.org X-Gm-Message-State: AOJu0YwQ3qC1hlHhfpX2lVeBknKL6bqmI55/yhy7Slwm0TlfRmTr1PkQ I9MW3MepCpqP9GseiSwx/i+WMGkvOw/b3YYZJmH7q7qGIiQketJdzj15RVrgjhVWuoLs4Glfwio sj3wMcLCBQA4feg3cCzss53rQIQ80cIpmwM+5 X-Gm-Gg: ASbGncuIbLqX+b7wWlwPTne6jjGziBwjr//rRpWaSFH1RwEJ2AM69kuXxrvEmzCviqQ ENb/gDzeDQDeErUSIQ19GV9AxjYUe3YTtBoCAyzCkbqwgXLE4a1bXnRL81q4olbefCRDGq3FXxk lHOu8Z1Or0ZAyghTwQBXi87uBQY3yEaHM38ZVZOzQgCMRl7gnd8Emu/t5yI0SeH/G+Kj7Sa6Zgb 6DtIe67vwxChEHP X-Google-Smtp-Source: AGHT+IECSuAtUIybiRfqDKyg+9JNArRPsGBjHRAqIMpsrogFALIaR9t7d7V0kszTiBUJLWaaX1R7jK4rmnQuSX/0sQQ= X-Received: by 2002:a17:907:1b13:b0:b04:31c6:a41f with SMTP id a640c23a62f3a-b24f50aa979mr454807866b.41.1758314538043; Fri, 19 Sep 2025 13:42:18 -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> <87bjnlrege.fsf@laura> In-Reply-To: Date: Fri, 19 Sep 2025 22:42:05 +0200 X-Gm-Features: AS18NWBgm4zyF2O9esdtcOWCU8F9zd7PhQHyOzCu7unmefqOcIFERq-oXKoCsKo Message-ID: Subject: Re: URCU feature request? To: Olivier Dion Content-Type: multipart/alternative; boundary="000000000000718c09063f2d810d" 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" --000000000000718c09063f2d810d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot to say Thanks, Thobias fre. 19. sep. 2025 kl. 22:39 skrev Thobias Knudsen : > >Since 0.15.0, we've introduce an annotation layer (not part of the > >public API), making TSAN compatible with URCU. See > >`include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro. > > > >However, IIRC, you also need to compile URCU with the configuration > >option `--enable-compiler-atomic-builtins' so that atomic operations are > >implemented with the configured toolchain's builtin atomics. I don't > >recall if this was strictly necessary. > > > >If you encounter false positives with TSAN, please send me a minimal > >reproducible example together with: > > > > - the toolchain you=E2=80=99re using > > > > - the version of URCU > > > > - the configuration flags you used > > > >I will be happy to have a look. > > Sorry for the late answer. I had to find the time to fix some bugs to get > it all running before switching to urcu v0.15.0 and setting the flags and > macros for thread sanitizer support. Creating a minimum reproducible > example would take some time as I don't have any good idea of the > exact place where the thread sanitizer issues arise because they are > scattered all over tsm.c and test_tsm.c. If you have linux debian family > then you can clone my repo and run it: > https://github.com/ThobiasKnudsen/Logos. ./scripts/build.sh --debug > --tsan && ./build/bin/test_tsm. I tried running with and without thread > sanitizer support and got the same issues. In the test_tsm when only one > thread is running, the thread sanitizer produces warnings still. I did fi= nd > a place where the thread sanitizer said there was a race and the write wa= s > within a node not yet inserted into the cds_lfht. That seems like a false > positive. The read for the same case should be inside rcu_read_lock as > everything within lines 263 to 904 inside test_tsm.c is within a read > section. > > Read of size 1 at 0x7b1400085ea1 by thread T6: > #0 tsm_base_node_is_valid /Logos/src/tsm.c:721 (test_tsm+0xa548) > #1 _tsm_tsm_type_is_valid /Logos/src/tsm.c:364 (test_tsm+0xb1bf) > #2 tsm_node_is_valid /Logos/src/tsm.c:1553 (test_tsm+0x9984) > #3 tsm_node_defer_free /Logos/src/tsm.c:1888 (test_tsm+0xb2fc) > #4 stress_thread /Logos/src/tests/test_tsm.c:549 (test_tsm+0x46a6) > > Previous write of size 1 at 0x7b1400085ea1 by thread T9: > #0 tsm_base_node_create /Logos/src/tsm.c:683 (test_tsm+0x6f2a) > #1 stress_thread /Logos/src/tests/test_tsm.c:843 (test_tsm+0x5ce0) > > >I don=E2=80=99t see why that would be a problem for the static-check alg= orithm I > >described above. If a pointer needs to be protected by a mutex for > >mutation, that falls outside the scope of RCU, as far as I know. > > If I understand correctly the __rcu checks that reads are not done outsid= e > read sections and unsafe writes are not done at all. If this is correct > then if you are using custom concurrency for __rcu protected data outside > the read section or unsafe writes is that allowed? Because if it's not th= at > would be a limitation for __rcu. > > man. 8. sep. 2025 kl. 02:10 skrev Olivier Dion : > >> On Sun, 07 Sep 2025, Thobias Knudsen wrote: >> >> 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 abo= ut >> >> 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? >> >> Since 0.15.0, we've introduce an annotation layer (not part of the >> public API), making TSAN compatible with URCU. See >> `include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro. >> >> However, IIRC, you also need to compile URCU with the configuration >> option `--enable-compiler-atomic-builtins' so that atomic operations are >> implemented with the configured toolchain's builtin atomics. I don't >> recall if this was stricly necessary. >> >> If you encounter false positives with TSAN, please send me a minimal >> reproducible example together with: >> >> - the toolchain you=E2=80=99re using >> >> - the version of URCU >> >> - the configuration flags you used >> >> I will be happy to have a look. >> >> >> Note that certain kind of errors could actually be flag at compile ti= me >> >> 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= something 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. >> >> I don=E2=80=99t know the details of `__rcu' from the Linux kernel. I thi= nk it=E2=80=99s >> just a macro that expands to nothing by default, but Sparse treats it as >> an attribute. I=E2=80=99m not sure exactly what checks Sparse performs = with it, >> but I suspect it involves traversing the program=E2=80=99s control-flow = graph >> (CFG), ensuring that pointers marked with the `__rcu' qualifier are: >> >> - obtained via rcu_dereference >> >> - only dereferenced under RCU lock protection >> >> > 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 don=E2=80=99t see why that would be a problem for the static-check alg= orithm I >> described above. If a pointer needs to be protected by a mutex for >> mutation, that falls outside the scope of RCU, as far as I know. >> >> > I cant come up with something usefull other than a language rework. Is >> > it much work making the __urcu attribute? >> >> I suppose not. On top of my head, it would involve adding some pointer >> qualifier and function attributes to the primitives exposed by URCU. >> Users would also need to use the pointer qualifier when working with >> RCU-protected pointers. The qualifier and the attributes would expand >> to nothing by default, letting static checkers defining them to internal >> values. I suggest you read `Documentation/RCU/rcu_dereference.rst' in >> the Linux kernel tree if you are interested. >> >> In its current state, this would not be very useful because none of the >> major compilers provide static analysis for RCU. However, implementing >> such analysis, as a plugin, wouldn=E2=80=99t be overly difficult for som= eone >> familiar with Clang or GCC, I suppose. >> >> [...] >> >> Thanks, >> Olivier >> -- >> Olivier Dion >> EfficiOS Inc. >> https://www.efficios.com >> > --000000000000718c09063f2d810d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I forgot to say

Thanks,
Thobi= as

fre. 19. sep. 2025 kl. 22:39 skrev Thobias Kn= udsen <thobknu@gmail.com>:
= >Since 0.15.0, we've introduce an annotation layer (not part of the<= br>>public API), making TSAN compatible with URCU.=C2=A0 See
>`inc= lude/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.
><= br>>However, IIRC, you also need to compile URCU with the configuration<= br>>option `--enable-compiler-atomic-builtins' so that atomic operat= ions are
>implemented with the configured toolchain's builtin ato= mics.=C2=A0 I don't
>recall if this was strictly necessary.
&g= t;
>If you encounter false positives with TSAN, please send me a mini= mal
>reproducible example together with:
>
> - the toolch= ain you=E2=80=99re using
>
> - the version of URCU
>
&= gt; - the configuration flags you used
>
>I will be happy to ha= ve a look.

Sorry for the late answer. I had to find the = time to fix some bugs to get it all running before switching to urcu v0.15.= 0 and setting the flags and macros for thread sanitizer=C2=A0support. Creat= ing a minimum reproducible example would take some time as I don't have= any good idea of the exact=C2=A0place where the thread sanitizer issues ar= ise=C2=A0because they are scattered all over tsm.c and test_tsm.c. If you h= ave linux debian family then you can clone my repo and run it:=C2=A0https://gith= ub.com/ThobiasKnudsen/Logos. ./scripts/build.sh --debug --tsan &&am= p; ./build/bin/test_tsm. I tried running with and without thread sanitizer = support and got the same issues. In the test_tsm when only one thread is ru= nning, the thread sanitizer produces warnings still. I did find a place whe= re the thread sanitizer said there=C2=A0was a race and the write was within= a node not yet inserted into the cds_lfht. That seems like a false positiv= e. The read for the same case should be inside rcu_read_lock as everything = within lines 263 to 904 inside test_tsm.c is within a read section.

=C2=A0 Read of size 1 at 0x7b1400085ea1 by thread T6:
= =C2=A0 =C2=A0 #0 tsm_base_node_is_valid /Logos/src/tsm.c:721 (test_tsm+0xa5= 48)
=C2=A0 =C2=A0 #1 _tsm_tsm_type_is_valid /Logos/src/tsm.c:364 (test_t= sm+0xb1bf)
=C2=A0 =C2=A0 #2 tsm_node_is_valid /Logos/src/tsm.c:1553 (tes= t_tsm+0x9984)
=C2=A0 =C2=A0 #3 tsm_node_defer_free /Logos/src/tsm.c:1888= (test_tsm+0xb2fc)
=C2=A0 =C2=A0 #4 stress_thread /Logos/src/tests/test_= tsm.c:549 (test_tsm+0x46a6)

=C2=A0 Previous write of size 1 at 0x7b1= 400085ea1 by thread T9:
=C2=A0 =C2=A0 #0 tsm_base_node_create /Logos/src= /tsm.c:683 (test_tsm+0x6f2a)
=C2=A0 =C2=A0 #1 stress_thread /Logos/src/t= ests/test_tsm.c:843 (test_tsm+0x5ce0)

>I do= n=E2=80=99t see why that would be a problem for the static-check algorithm = I
>described above.=C2=A0 If a pointer needs to be protected by a mut= ex for
>mutation, that falls outside the scope of RCU, as far as I kn= ow.

If I understand correctly the __rcu checks tha= t reads are not done outside read sections and unsafe writes are not done a= t all. If this is correct then if you are using custom concurrency for __rc= u protected data outside the read section or unsafe writes is that allowed?= Because if it's not that would be a limitation for __rcu.=C2=A0
<= /div>
m= an. 8. sep. 2025 kl. 02:10 skrev Olivier Dion <odion@efficios.com>:
On Sun, 07 Sep 2025, Thobias Knu= dsen <thobknu@gma= il.com> wrote:
>> It looks like you want runtime verification for the usage of the A= PI.
>> Did you know that URCU can now be compiled against ThreadSanitizer=
>> (TSAN)?=C2=A0 If a user misuses the API or makes incorrect assumpt= ions about
>> the guarantees offered by RCU, TSAN will most likely detect those<= br> >> issues.=C2=A0 Coupled with the other debug features we already hav= e, this
>> makes it very hard to not trigger an error path when the API is us= ed
>> incorrectly.
>
> Really?! I've used TSAN and got a bunch of false positives, I beli= eve, but
> maybe they're not false positives? How do you remove the false pos= itives,
> or know that they're not false positives?

Since 0.15.0, we've introduce an annotation layer (not part of the
public API), making TSAN compatible with URCU.=C2=A0 See
`include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.

However, IIRC, you also need to compile URCU with the configuration
option `--enable-compiler-atomic-builtins' so that atomic operations ar= e
implemented with the configured toolchain's builtin atomics.=C2=A0 I do= n't
recall if this was stricly necessary.

If you encounter false positives with TSAN, please send me a minimal
reproducible example together with:

=C2=A0- the toolchain you=E2=80=99re using

=C2=A0- the version of URCU

=C2=A0- the configuration flags you used

I will be happy to have a look.

>> 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=91protected pointers.=C2=A0 I=E2=80=99d be very open to = exposing something 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.=

I don=E2=80=99t know the details of `__rcu' from the Linux kernel. I th= ink it=E2=80=99s
just a macro that expands to nothing by default, but Sparse treats it as an attribute.=C2=A0 I=E2=80=99m not sure exactly what checks Sparse perform= s with it,
but I suspect it involves traversing the program=E2=80=99s control-flow gra= ph
(CFG), ensuring that pointers marked with the `__rcu' qualifier are:
=C2=A0 - obtained via rcu_dereference

=C2=A0 - only dereferenced under RCU lock protection

> 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 don=E2=80=99t see why that would be a problem for the static-check algori= thm I
described above.=C2=A0 If a pointer needs to be protected by a mutex for mutation, that falls outside the scope of RCU, as far as I know.

> I cant come up with something usefull other than a language rework. Is=
> it much work making the __urcu attribute?

I suppose not.=C2=A0 On top of my head, it would involve adding some pointe= r
qualifier and function attributes to the primitives exposed by URCU.
Users would also need to use the pointer qualifier when working with
RCU-protected pointers.=C2=A0 The qualifier and the attributes would expand=
to nothing by default, letting static checkers defining them to internal values.=C2=A0 I suggest you read `Documentation/RCU/rcu_dereference.rst'= ; in
the Linux kernel tree if you are interested.

In its current state, this would not be very useful because none of the
major compilers provide static analysis for RCU.=C2=A0 However, implementin= g
such analysis, as a plugin, wouldn=E2=80=99t be overly difficult for someon= e
familiar with Clang or GCC, I suppose.

[...]

Thanks,
Olivier
--
Olivier Dion
EfficiOS Inc.
h= ttps://www.efficios.com
--000000000000718c09063f2d810d--