From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 156F7371D04; Tue, 31 Mar 2026 19:52:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774986731; cv=none; b=FcOUQEOJIw9FkyBRh9k0wUgOCSDlttDWMIJbnHC9wy1opQCF3bWEqjG1MngUePOi765/Uf3gc9J4OKER7Et+SmdqfCHmTICaYIY8+/G33ImTXG9pWZ1GvUuEGYVGsYJQIDVauFa7QQYDCZvdQJXsKeZE1LeVW1onfvUYNlCZ0zg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774986731; c=relaxed/simple; bh=yDqHYQlphNi7NM7Fr9Z0F57GE+N/2wp/OlWZUNKCtFM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WS08QpLt+jRNutdD+YTG9aTdzB3lYuQVlft3/WlZIooirEHzDHQ90ihPdDwtyMAWvy/rh8mHgsPJ+O+UysnEhpQ5UC3ZI8iSVqKkxz9WWHs22Zjg5sYCi/yqnF6tqYIvOGDScW6OwBbvfUZeMPGysv/4m2pUri3EdITLbrlrYh8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GoS4l/ty; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GoS4l/ty" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 850ACC19423; Tue, 31 Mar 2026 19:52:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774986730; bh=yDqHYQlphNi7NM7Fr9Z0F57GE+N/2wp/OlWZUNKCtFM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GoS4l/tyGpgkmFwUGs4aAbnB1/BYsqPONwZgpACMtl6kEqKP+DAfcl8RvP1T8zwha 4q0mIhdzm5L84l9/QOKb1qs8zQw/vMoNicYpclxNEwoIUd9Fa4CyL5rIscq2G4oLDr xC8LiQi9xCR+HHp26+Sfh9RoSrP6eu82EuykpIIwt0+5N5zudICUDTYLKU8QECw4zy fFz4itvKaPgiJaSUKhqkKVdQW7ejg2YeCvQ6YrCY3ulZKEMkrj9Cmb84to6ppt3I5B jF0nNbH0Pxw5H55bdqdJ7jEEMjoc/kESkP7rAb2bkqS97TUb7HWnF7W20X/D1Fj7Oc o9WyB/1v1fIMg== Date: Tue, 31 Mar 2026 12:52:10 -0700 From: Kees Cook To: Justin Stitt Cc: Miguel Ojeda , Peter Zijlstra , Marco Elver , Andrey Konovalov , Andrey Ryabinin , Jonathan Corbet , Shuah Khan , Miguel Ojeda , Nathan Chancellor , kasan-dev@googlegroups.com, linux-doc@vger.kernel.org, llvm@lists.linux.dev, Linus Torvalds , Nicolas Schier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kbuild@vger.kernel.org Subject: Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap Message-ID: <202603311249.30B44C66@keescook> References: <20260331163716.work.696-kees@kernel.org> <20260331163725.2765789-3-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 > wrote: > > > > On Tue, Mar 31, 2026 at 6:37 PM Kees Cook 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