Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types

Peter Zijlstra
2026-04-01T08:31:50Z

On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:

(still slowly digesting the thread)

> 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;
> }

Note that there is a 'fun' problem with this in combination with
cleanup.h.

Something like:

int func()
{
u8 __ob_trap prod = 0;

scoped_guard (mutex, &my_lock) {
prod = a * b;
}

return prod;

__overflow:
// whatever
return -1;
}

is fine. *HOWEVER*, something like:

int func()
{
int __ob_trap size = base + count * extra;
int err;

struct my_obj *obj __cleanup(kfree) = kzalloc(size, GFP_KERNEL);

err = my_obj_init(obj);
if (err)
return ERR_PTR(err);

return_ptr(obj);

__overflow:
// what now..
return NULL;
}

is most terribly broken. Specifically, the goto will jump into the scope
of obj -- and that is not allowed.