Hi, On Wed, Apr 01, 2026 at 11:20:27AM +0200, Peter Zijlstra wrote: ... > > So I would like to second this option as being interesting. > > But while pondering it, I did want to note that all of the options, with > the exception of __ob_wrap (which is effectively what we have today for > *everything*), will be 'interesting' to compose with _Atomic, another > one of these qualifiers. > > Now, in the kernel we don't use _Atomic, so strictly speaking I don't > care ;-) But here goes... > > Something like _Atomic int __ob_wrap, is trivial and good. > > _Atomic int __ob_trap is either doable or impossible depending on how > you define the result to be on 'trap'. Specifically, the semantics > proposed where it keeps the old value makes it impossible. > > And _Atomic int __ob_saturate is equally 'challenging', since the > fundamental thing of 'reset to min/max on under/over-flow' is rather > a non-atomic kind of thing. Look at the trouble we went through with > refcount_t to sort of make this work. >
FWIW, I've moved to simply disallow OBT+Atomic. We've got this under -fexperimental so I'm well within my right :). The idea being: __ob_trap isn't workable with Atomic (depending on storage semantics) and __ob_wrap isn't very useful there either, plus I had some parsing bugs where specific ordering of things could result in OBT being silently dropped with _Atomic and those magically go away by disallowing this pairing all together. I just opened the PR over at [1] and it is still pending but this is probably where I'll go with _Atomic and OBT :) Link: https://github.com/llvm/llvm-project/pull/222179 Thanks Justin
