On Tue, Mar 31, 2026 at 10:09:33AM -0700, Justin Stitt wrote: > Hi, > > On Tue, Mar 31, 2026 at 10:02 AM Miguel Ojeda > <[email protected]> wrote: > > > > On Tue, Mar 31, 2026 at 6:37 PM Kees Cook <[email protected]> wrote: > > > > > > +/* > > > + * Optional: only supported by Clang with -Xclang > > > -experimental-foverflow-behavior-types > > > + * passed via CONFIG_OVERFLOW_BEHAVIOR_TYPES. When not available, define > > > empty macros for > > > + * the trap/wrap annotations. > > > + * > > > + * clang: https://clang.llvm.org/docs/OverflowBehaviorTypes.html > > > + */ > > > +#if !__has_attribute(overflow_behavior) || > > > !defined(OVERFLOW_BEHAVIOR_TYPES) > > > +# define __ob_trap > > > +# define __ob_wrap > > > +#endif > > > > Should that have `CONFIG_*`? i.e. > > > > !defined(CONFIG_OVERFLOW_BEHAVIOR_TYPES) > > > > In addition, since this depends on a `CONFIG_`, with the current setup > > we would put them elsewhere instead of `compiler_attributes.h` until > > they are promoted to be "unconditional" (i.e. without the compiler > > flag): > > > > * Any other "attributes" (i.e. those that depend on a configuration > > option, > > * on a compiler, on an architecture, on plugins, on other > > attributes...) > > * should be defined elsewhere (e.g. compiler_types.h or compiler-*.h). > > * The intention is to keep this file as simple as possible, as well as > > * compiler- and version-agnostic (e.g. avoiding GCC_VERSION checks). > > > > However, thinking about it, why is the config needed? > > > > i.e. if the compiler is not passed that flag, shouldn't the > > `__has_attribute` simply return false? > > > > Also, I am a bit confused -- does the compiler flag automatically > > recognize the names like `__ob_trap`? i.e. I see the docs mention > > using the attribute, > > > > typedef unsigned int __attribute__((overflow_behavior(trap))) safe_uint; > > typedef unsigned int __attribute__((overflow_behavior(wrap))) > > wrapping_uint; > > > > But then we don't actually use it? > > __ob_trap and __ob_wrap are defined by the compiler. > > There are some examples within the documentation additions of this patch. > > Kees, is it possible to make it more clear about what we expect of > kernel developers in terms of style? Should they use keyword > spellings? attribute spellings? only use custom types?
I think for this series, __ob_trap/__ob_wrap is what should be used. And for other folks, the background here is that we originally wanted to use macros for "__trap" and "__wrap", but the powerpc C compiler (both Clang and GCC) have a builtin macro named "__trap" already. So I switched to just using the Clang-native type qualifier. We can use the attribute style too, but there was a lot of confusion during the Clang development phases where people kept forgetting this was a type qualifier, not an attribute (i.e. the attribute is an internal alias for the qualifier, and the qualifier is a new type). -- Kees Cook
