On Tue, Mar 31, 2026 at 01:11:22PM -0700, Linus Torvalds wrote:

On Tue, 31 Mar 2026 at 13:03, Kees Cook [off-list ref] wrote:

quoted

Mark Rutland had strong reservations about function-level annotations,
but I wonder if the combination of new type _and_ function-level
annotation could get us something near what would be palatable:

Yes, if we had some way to specify the label, that actually looks
really nice to me.

So with _this_ kind of interface, all my reservations about it go away.

And as long as the compiler actually requires that label to exist when
trapping arithmetic is done, I don't think people will use it without
having fixups.

quoted

Or we could make the label a global part of the language itself so it
wouldn't need to be a function annotation, but rather a _required_
element of any function that uses a trapping type?

Yes, I'd be ok with that too, because I think in practice you
typically only ever have one, and I guess you could use local labels -
or multiple functions - if you really needed to have different
targets.

Yeah, as you mentioned earlier, I'd agree that nesting is rarely
useful. The only thing I'd want to be careful about is ordering/scope. I
*think* it would just operate as a "goto" and things like the cleanup.h
handlers wouldn't be involved: they operate when a scope is crossed
like before. And I think the overflow result wouldn't be represented
anywhere. i.e. the wrapped/truncated value wouldn't be stored:

int func()
{
	...
	u8 __ob_trap product = 5;
	...
	product = a * b; // if store is truncated, goto __overflow
	...
	return product;

__overflow:
	pr_info("%u\n", product); // shows "5"
	return -1;
}

(Isn't this just an implicit "try"?)

-Kees

-- 
Kees Cook