Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap

[Kees Cook]

On Wed, Apr 01, 2026 at 11:20:27AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 01, 2026 at 09:19:51AM +0200, Vincent Mailhol wrote:
> > Le 31/03/2026 à 18:37, Kees Cook a écrit :
> 
> > > +  - Saturate (explicitly hold the maximum or minimum representable value)
> > 
> > I just wanted to ask how much consideration was put into this last
> > "saturate" option.
> > 
> > When speaking of "safe" as in "functional safety" this seems a good
> > option to me. The best option is of course proper handling, but as
> > discussed, we are speaking of the scenario in which the code is already
> > buggy and which is the fallout option doing the least damage.
> > 
> > What I have in mind is a new __ob_saturate type qualifier. Something like:
> > 
> > 	void foo(int num)
> > 	{
> > 		int __ob_saturate saturate_var = num;
> > 	
> > 		saturate_var += 42;
> > 	}
> > 
> > would just print a warning and continue execution, thus solving the
> > trapping issue. The above code would generate something equivalent to that:
> > 
> > 	void foo(int num)
> > 	{
> > 		int __ob_saturate saturate_var = num;
> > 	
> > 		if (check_add_overflow(saturate_var, increment,
> > 				       &saturate_var) {
> > 			WARN(true, "saturation occurred");
> > 			saturate_var = type_max(saturate_var);
> > 	}
> 
> 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.

Yeah, this is mainly why we didn't spend time working on an
__ob_saturate implementation: the primary place we want it in Linux is
already solved with all the refcount_t work. That said, if the behavior
could be replicated using a future __ob_saturate, that would be very
nice. :)

-- 
Kees Cook