From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OrOIKCEfvmhJJTMAWB0awg (envelope-from ) for ; Sun, 07 Sep 2025 20:11:13 -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=z31qfSGx; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8ECEC1E0BA; Sun, 07 Sep 2025 20:11:13 -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,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 BF01C1E047 for ; Sun, 07 Sep 2025 20:11:08 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cKnRb6tF9z1jBZ ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1757290268; b=AP0dyFEhFgM6wydmlLJIZO7BCVsjNyRTMw8fJxfyC8kY3K/EopwjrRhQNpgZYHiGIAk0 QgN0U7JsyqZteA5TMprSVxeVDHv+HCmiF1ISMWrmauKOXQMy6WxMxqhivjqMibMaAm5hL bRqN9lXWYXCJlzzcFGqVGhb9gUhARSaeNR2dEKYGfLdhk2S2Yhhjv9FUEjE1Uul6/2jnS b2dunk5OOelazLXzTfDU1d8qm+mzVzj2b1laOMwlRs/MrM6wJQ/G05wTFjWnZDGuy51zR nse86+M1o2ZWhjL0NzkEkGFY8YJSe0oAj/azZuv3eZnJpit/hRjRJr0kczPPUPsHwng== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1757290268; h=DKIM-Signature:To:Subject:Date:Message-ID:MIME-Version:From:From; bh=P/hVrdNrFyko0waD4g1KIXxzPqA0dtjuxJpjQ9t8Ir4=; b=CWmwU25XblumYnMi45bECRY4D+3lmsPFDSbYh0yHpZ5LTkMgQ+VJvohMJMn/M79vSyuN iCbatjmQMLNxXqFaFEnb5Dn2m+JXF9pOvzhmA5mkJHd+J4zU1IyIFAFRe3JHrC51MauFf Ylg6W3SSDthss9URL22Fk9tAHCfKjDhuk+2qWa3FzXOUjS8bbey+DK8FozarrV5BbNtC6 wOxQQidwI4/9kFmrmG9/5u94dS/y16OBKdwmVFGkvdDE42Y7A59Lm289LzCksTrKMAI4k jTF9ZSBizefpI7LsHKot32/Gr5Q0va9L5pY8hvR5hskm/E9Gku8EfZbfIJUFDlvT2bw== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cKnRb6tF9z1jBZ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1757290268; bh=P/hVrdNrFyko0waD4g1KIXxzPqA0dtjuxJpjQ9t8Ir4=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=z31qfSGxBMd8P1IlN22DcwWDoUO8R2iJJ84n+/Hu2gcagq0KyDD3IBGXacb0BTa0I roKkKBv+GHssOgjyNV4hSn0+nYVuRhnnP3Y5V4YibVIN97T7jDQ3mAyiFyRYgxO51Q qJc+7VenzEXyrAKODG6+4hKfBhzp5j6b2iKrnZQy34vgqOOKsNsRz8e8wau1e6QPYg 55SfaBKa2r2m/bEYaQtdVZU5MAtVho5cNcfYXOAQgunXWrfIabs6qUlNoaZKYr7ME7 8HziL4iXzyFQbuPA5wq/bp2dlipU9To3iCkzqEKWRnIOlM7fSYntFnDowFbYUuXMet I/Cj73chpys7w== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cKnRb6tF9z1jBZ; Sun, 7 Sep 2025 20:11:07 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cKnRZ0rW2z1hvm DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cKnRZ0rW2z1hvm Received: from smtpout.efficios.com (smtpout.efficios.com [158.69.130.18]) by lists.lttng.org (Postfix) with ESMTPS id 4cKnRZ0rW2z1hvm for ; Sun, 7 Sep 2025 20:11:05 -0400 (EDT) Received: from localhost (199-193-172-8.cpe.axion.ca [199.193.172.8]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4cKnRQ0vy5z94J; Sun, 07 Sep 2025 20:10:58 -0400 (EDT) To: Thobias Knudsen Subject: Re: URCU feature request? In-Reply-To: Organization: EfficiOS References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> <87h5xg7p3u.fsf@laura> Date: Sun, 07 Sep 2025 20:10:57 -0400 Message-ID: <87bjnlrege.fsf@laura> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Olivier Dion via lttng-dev Reply-To: Olivier Dion Cc: lttng-dev@lists.lttng.org Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" 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 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? 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 =20 - the version of URCU =20 - 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. 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 so= mething 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.=20 I don=E2=80=99t know the details of `__rcu' from the Linux kernel. I think = 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 wit= h 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: - obtained via rcu_dereference =20=20 - 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. 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 someone familiar with Clang or GCC, I suppose. [...] Thanks, Olivier --=20 Olivier Dion EfficiOS Inc. https://www.efficios.com