From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iUJ+Aoq/zWjr5QoAWB0awg (envelope-from ) for ; Fri, 19 Sep 2025 16:39:38 -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=iJRNhRvV; 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=gtHqiLpA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 024041E0BA; Fri, 19 Sep 2025 16:39:37 -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 A628D1E04C for ; Fri, 19 Sep 2025 16:39:35 -0400 (EDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=lists.lttng.org; q=dns/txt; s=mx; t=1758314369; x=1758321569; 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=D/au3l3SsTE4kBsWX726dWZJmRK4R4qGJHVBoU0RNFU=; b=iJRNhRvVuER64228Gi4lw4u18zpk999HHIVWItzy8wE+kRyUSjaJalkak4Ctkmsk4v0EHd7Y0vjcnd1AtHS//ni75vgegRSaaYZd5UYb3BXupHLCOzscQFzanE8NQMVpm5kTytxd29X5xk8cQ8szrL3bwOstQbMKT6H4Jd+7xS45Bd9hoF06+JMBQxDzJs14Dsw53JVNPDtDnCcBsKsXDbhViwfzYelF5DDFVVz5MhvWmiRYn3qaePZPl0dzS68XyJRYMBaDblBwYXbpdtTlKMxpht45xXk2s/Xx7rPItKNj/hiCnmLAmNGj7O4QOLxik6oCIKiTsbSwuIZkNVgwcA== X-Mailgun-Sid: WyJkOTk2OCIsInB1YmxpYy1pbmJveEBzaW1hcmsuY2EiLCI2MDIzMjMiXQ== Received: from lists.lttng.org (lists.lttng.org [158.69.130.29]) by d84d96e72ffff991fbc99e71cdf6472e6c2914c137ec8112a015c6a70c2a644e with SMTP id 68cdbf81d32375de8cc8b63d (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Fri, 19 Sep 2025 20:39:29 GMT X-Mailgun-Sending-Ip: 159.135.228.15 ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cT49r0bz1z16qt ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1758314368; b=GYaqLc+pgxoez3uwjGBipNtVMnIAdzPkU9e57n+HQA2N1dDy9vfw00h59LTbF8kKAERw Y81gLiLekNiNaAo1mcWSXWc+rzMf4rD9zsxlYuYfijQNcbHO7mkFZcObfFSQ4Yi4oFtBS cZmdiVCLDU64x83jOUCdquemoapPEA9SGnUOYWIQ9IRmO0s0Fa3JmcV3tFE1ndxo4sDcq 0fujHF64Nf2yG48/2TzE2l0wERCyH2Fnavxw4ORITFwSu1fZ9WCxyQ2ryJjh+a0pSsvtM 5rGvfRd7YAcoaZ0OSITE8+0KN+jIwMRiMjHukaNBKBzJo01POCnl7unQcB1aSpXylig== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1758314368; h=DKIM-Signature:MIME-Version:Date:Message-ID:Subject:To:From:From; bh=WGCJOwm284nhzDF5oEwTEx/Ii/YjcXuaq++cLg3nNm8=; b=Q2QCQjeXDwKwjEalB3e6n7bBC0w3keR88E/e0FQw/33wqORzjSIPVnKyfBd1CX7uADTz DGR3eAdqn8eQRuWJ1NBSAC6xRrTUdMcUgXhVgi/af5NPksH0LqDAMTM4MT2bi2swS4aaE 3pDDVwhtXqcF/LffhspBmdkO3+YA/EFdvZ108Nb3SzWkxHToISiSFaMvFruTG4n8NlcQx RJT/XP1t2zvC/mI/JU9iUIHbeynW1ABu9fJql0pXTe+pISsNn+Gtv0rj5D5SRKag9QPA+ pBtXUUdc+hM1TG6P/2l2M4MleuD+sRCgYhaoKAgWK70KXlWSu/JqfDxMol5cJG41JFA== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cT49r0bz1z16qt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1758314368; bh=WGCJOwm284nhzDF5oEwTEx/Ii/YjcXuaq++cLg3nNm8=; 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=gtHqiLpAV/3ERINuSXHlNXktzy2iuRINLdVbUmTcDcSJK92fHhhl6rKR7YZx36CLZ SRID+Dez8NWMAfP5QdfqBWEp4AS/uCCD2lcthXnRe3K4Du9usK9UDz7ush4/7DrmFz QrG21LSBQCT7thD25J+TNDT+s1YP7XDd34dRHPWbknInms773r1MXmkPPJrDbFSDlo Zw/XOTM2LXe1YftJklS2d5iNF1Y7mF+/afDifyqhYCKQZdcYiQ/bjebaON2r3o21Mm xbFePo7n/YEMURtKIW9gPw3k8t9OqrCrLsg8Hc9bYzC06eqoermTLhV48h4BfGV+8l Bh2ShI+o8D5zQ== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cT49r0bz1z16qt; Fri, 19 Sep 2025 16:39:27 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cT49p5SpNz17Fx DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cT49p5SpNz17Fx Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lists.lttng.org (Postfix) with ESMTPS id 4cT49p5SpNz17Fx for ; Fri, 19 Sep 2025 16:39:26 -0400 (EDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-62fa0653cd1so3033532a12.0 for ; Fri, 19 Sep 2025 13:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758314364; x=1758919164; 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=D/au3l3SsTE4kBsWX726dWZJmRK4R4qGJHVBoU0RNFU=; b=wzIgjrRCsFsArb5MzsZarZKgnqHOkpAMArMVH31oiuzBh23lHvZyKl/Gn9Hngf+qa/ fq23BYrrMCUz/IaPSG+UVcsXM1jgX2Afk4C6a6Hv95aKP320zN5hkNEOTH89hHFraXjV Zv4h0UcqZzyz4YeeHMKBxZ+Yrw6rJp1HXedQ+zoKEkzQpTKIvTt1fnXjHRxkOnHMqDvw rQ2UWyYCTS2B5emrdWLyFYRtRrp+FsALe+Vgkmo8BmdMTphq0H7pw72ydROVWoEXG4Rs xVWhapyySlN5I5agjZnCoMtPvO91tTvuPlPVGjh+gRGcoYpqAJVVNUJtEZY5CES2w41G dQ3Q== X-Forwarded-Encrypted: i=1; AJvYcCWFJO9C14/1uTM8zDThyUE8txu37opoKWOE94mx0BacvsVoLXWDnjEJK6K/KPAPcRVrwMw+qHi2ktQ=@lists.lttng.org X-Gm-Message-State: AOJu0Yxk0TUj/HmrcPLwt3bIo7tUJPvR0zIb1G4QgVvNAzLd6n3EMEbj JQ8ztHC3trvDNjgMaRtJx2tvWnNDizTJPaKjP0tli5Tb6wrZdG//B9ofpBa54PU3yQZGuI6xyov jl6hFRtf0kRpheyAO9tBnMrkR8YZbfszHbaC4rfg= X-Gm-Gg: ASbGncsT0bD6ENqp7pUAcN4oIisyzsXvpF42pIUzykVfjfMixRuuf0fFjxtKM+ei/EL tFvNOliM7e6CXbDbnzlsFTd0ieFQoYXAGAqe/0ZQ/N2WYQzEg9CB2dd7EC9P79iXbTDu0NYOqjR RZ0vTXPvK0IWFp93QLLzjVzls/17ENac0eWetY5kVPHEBHRbteuue8fVB+XPqAs+j8jL6Lixt2r VJIxJ6K087WOWaD X-Google-Smtp-Source: AGHT+IFkOe5xuC5WWjY1WoJq7ZulsWbsXtEVuXD+3FpXLYMMi2AbHsWeJHVsSltL2eDgPZpiV/JhFI6MSabjS6WAyM0= X-Received: by 2002:a05:6402:3202:b0:62b:8a92:d2f0 with SMTP id 4fb4d7f45d1cf-62fc0a7ba4cmr4035884a12.33.1758314363589; Fri, 19 Sep 2025 13:39:23 -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: <87bjnlrege.fsf@laura> Date: Fri, 19 Sep 2025 22:39:11 +0200 X-Gm-Features: AS18NWDfHTnaGOzGYRno-1AAc4ZIeULOsDULNOqkzB_ms5PB9WnIXHY6C-muEJw Message-ID: Subject: Re: URCU feature request? To: Olivier Dion Content-Type: multipart/alternative; boundary="0000000000000b9882063f2d7704" 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" --0000000000000b9882063f2d7704 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >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 find a place where the thread sanitizer said there was a race and the write was 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 algor= ithm 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 outside 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 that 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 abou= t > >> 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 positive= s, > > 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 tim= e > >> 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 b= ut > > 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 thin= k 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 w= ith it, > but I suspect it involves traversing the program=E2=80=99s control-flow g= raph > (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 algo= rithm 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 some= one > familiar with Clang or GCC, I suppose. > > [...] > > Thanks, > Olivier > -- > Olivier Dion > EfficiOS Inc. > https://www.efficios.com > --0000000000000b9882063f2d7704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>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&#= 39; 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 toolchai= n's builtin atomics.=C2=A0 I don't
>recall if this was strict= ly necessary.
>
>If you encounter false positives with TSAN, pl= ease send me a minimal
>reproducible example together with:
>> - the toolchain you=E2=80=99re using
>
> - the version o= f 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 switc= hing to urcu v0.15.0 and setting the flags and macros for thread sanitizer= =C2=A0support. Creating 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 arise=C2=A0because 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:=C2=A0https://gi= thub.com/ThobiasKnudsen/Logos. ./scripts/build.sh --debug --tsan &&= amp; ./build/bin/test_tsm. I tried running with and without thread sanitize= r support and got the same issues. In the test_tsm when only one thread is = running, the thread sanitizer produces warnings still. I did find a place w= here the thread sanitizer said there=C2=A0was a race and the write was with= in a node not yet inserted into the cds_lfht. That seems like a false posit= ive. The read for the same case should be inside rcu_read_lock as everythin= g 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+0x= a548)
=C2=A0 =C2=A0 #1 _tsm_tsm_type_is_valid /Logos/src/tsm.c:364 (test= _tsm+0xb1bf)
=C2=A0 =C2=A0 #2 tsm_node_is_valid /Logos/src/tsm.c:1553 (t= est_tsm+0x9984)
=C2=A0 =C2=A0 #3 tsm_node_defer_free /Logos/src/tsm.c:18= 88 (test_tsm+0xb2fc)
=C2=A0 =C2=A0 #4 stress_thread /Logos/src/tests/tes= t_tsm.c:549 (test_tsm+0x46a6)

=C2=A0 Previous write of size 1 at 0x7= b1400085ea1 by thread T9:
=C2=A0 =C2=A0 #0 tsm_base_node_create /Logos/s= rc/tsm.c:683 (test_tsm+0x6f2a)
=C2=A0 =C2=A0 #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 algorith= m I
>described above.=C2=A0 If a pointer needs to be protected by a m= utex for
>mutation, that falls outside the scope of RCU, as far as I = know.

If I understand correctly the __rcu checks t= hat reads are not done outside 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 allowe= d? Because if it's not that would be a limitation for __rcu.=C2=A0

man. 8. sep. 2025 kl. 02:10 skrev Olivier Dion <<= a href=3D"mailto:odion@efficios.com">odion@efficios.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 07 Sep 2025, Thobi= as Knudsen <thobk= nu@gmail.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
--0000000000000b9882063f2d7704--