[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202202031627.0EEB393@keescook>
Date: Thu, 3 Feb 2022 16:28:01 -0800
From: Kees Cook <keescook@...omium.org>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
George Burgess IV <gbiv@...gle.com>, llvm@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH 4/4 v5] fortify: Add Clang support
On Thu, Feb 03, 2022 at 02:13:33PM -0800, Nick Desaulniers wrote:
> On Tue, Feb 1, 2022 at 4:30 PM Kees Cook <keescook@...omium.org> wrote:
> >
> > diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
> > index c45159dbdaa1..5482536d3197 100644
> > --- a/include/linux/fortify-string.h
> > +++ b/include/linux/fortify-string.h
> > @@ -2,7 +2,9 @@
> > #ifndef _LINUX_FORTIFY_STRING_H_
> > #define _LINUX_FORTIFY_STRING_H_
> >
> > -#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
> > +#include <linux/const.h>
> > +
> > +#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline)) __overloadable
>
> Sorry, I just noticed this line (already) uses a mix of open coding
> __attribute__ and not. Would you mind also please changing the open
> coded gnu_inline to simply __gnu_inline to make the entire line
> consistent?
Ah yeah, thanks. Fixed.
--
Kees Cook
Powered by blists - more mailing lists