Re: racy leak sanitizer builds, was Re: [PATCH 0/9] commit-reach: -Wsign-compare follow-ups
- From
Jeff King <peff@peff.net>
- Date
- Dec 30, 2024, 04:32 UTC
- Message-ID
- <20241230043242.GA112402@coredump.intra.peff.net>
- In-Reply-To
- <20241229165715.GA3158370@coredump.intra.peff.net>
On Sun, Dec 29, 2024 at 11:57:15AM -0500, Jeff King wrote:
Show 16 quoted lines
> One of the reasons I hadn't sent anything is that I was waffling between > two approaches: > > - implement barriers everywhere and just use them. More work, but we'd > have the tool if we wanted to use it later, and all builds behave > the same. > > - make a "maybe_barrier" interface that might be a noop, and let most > platforms compile without them. They are not needed for correct > operation in most cases, but only to work around a sanitizer problem. > And it is not even a problem that comes up frequently; it is a race > that we occasionally see in CI. So enabling it only for our > linux-leaks CI job would be enough to dull the pain. > > And there is no risk of any portability or run-time issues, because > the code is a noop for most builds.
I sent the "maybe" interface in this series if you want to take a look:
https://lore.kernel.org/git/20241230042325.GA112439@coredump.intra.peff.net/
I'm not married to that approach, but it seemed like the easiest place to start. And I especially wanted to see how much hand-waving was required to justify it in the third patch. It's a fair bit. ;)
-Peff