Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Randy Dunlap
On 11/16/20 11:28 AM, Randy Dunlap wrote: > On 11/16/20 10:30 AM, Andreas Schwab wrote: >> On Nov 16 2020, Randy Dunlap wrote: >> >>> What kernel version are you building? >> >> 5.10-rc4 >> >> Andreas. > > OK, thanks. > > My build machine is slow, but I have a patch that I am testing: > > --- >

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Andreas Schwab
On Nov 16 2020, Nick Desaulniers wrote: > A lot of VDSO's reset KBUILD_CFLAGS or use a new variable for their > compiler flags. As such, they're missing `-include` command line flag > that injects include/linux/compiler_types.h, It's not missing here. Andreas. -- Andreas Schwab,

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Nick Desaulniers
On Mon, Nov 16, 2020 at 9:47 AM Andreas Schwab wrote: > > On Okt 14 2020, Arvind Sankar wrote: > > > Commit > > 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually > > exclusive") > > > > neglected to copy barrier_data() from compiler-gcc.h into > > compiler-clang.h. The

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Randy Dunlap
On 11/16/20 10:30 AM, Andreas Schwab wrote: On Nov 16 2020, Randy Dunlap wrote: What kernel version are you building? 5.10-rc4 Andreas. OK, thanks. My build machine is slow, but I have a patch that I am testing: --- From: Randy Dunlap riscv's uses barrier() so it should #include to

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Andreas Schwab
On Nov 16 2020, Randy Dunlap wrote: > What kernel version are you building? 5.10-rc4 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Randy Dunlap
On 11/16/20 9:47 AM, Andreas Schwab wrote: > On Okt 14 2020, Arvind Sankar wrote: > >> Commit >> 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually >> exclusive") >> >> neglected to copy barrier_data() from compiler-gcc.h into >> compiler-clang.h. The definition in

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-11-16 Thread Andreas Schwab
On Okt 14 2020, Arvind Sankar wrote: > Commit > 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually > exclusive") > > neglected to copy barrier_data() from compiler-gcc.h into > compiler-clang.h. The definition in compiler-gcc.h was really to work > around clang's more

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-21 Thread Kees Cook
On Wed, Oct 14, 2020 at 05:26:31PM -0400, Arvind Sankar wrote: > Commit > 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually > exclusive") > > neglected to copy barrier_data() from compiler-gcc.h into > compiler-clang.h. The definition in compiler-gcc.h was really to work >

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-15 Thread Nick Desaulniers
On Thu, Oct 15, 2020 at 8:39 AM Arvind Sankar wrote: > > On Thu, Oct 15, 2020 at 03:24:09PM +, David Laight wrote: > > > I think the comment is unclear now that you bring it up, but the problem > > > it actually addresses is not that the data is held in registers: in the > > >

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-15 Thread Arvind Sankar
On Thu, Oct 15, 2020 at 03:24:09PM +, David Laight wrote: > > I think the comment is unclear now that you bring it up, but the problem > > it actually addresses is not that the data is held in registers: in the > > sha256_transform() case mentioned in the commit message, for example, > > the

RE: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-15 Thread David Laight
From: Arvind Sankar > Sent: 15 October 2020 15:45 > > On Thu, Oct 15, 2020 at 08:50:05AM +, David Laight wrote: > > From: Arvind Sankar > > > Sent: 14 October 2020 22:27 > > ... > > > +/* > > > + * This version is i.e. to prevent dead stores elimination on @ptr > > > + * where gcc and llvm

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-15 Thread Arvind Sankar
On Thu, Oct 15, 2020 at 08:50:05AM +, David Laight wrote: > From: Arvind Sankar > > Sent: 14 October 2020 22:27 > ... > > +/* > > + * This version is i.e. to prevent dead stores elimination on @ptr > > + * where gcc and llvm may behave differently when otherwise using > > + * normal barrier():

RE: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-15 Thread David Laight
From: Arvind Sankar > Sent: 14 October 2020 22:27 ... > +/* > + * This version is i.e. to prevent dead stores elimination on @ptr > + * where gcc and llvm may behave differently when otherwise using > + * normal barrier(): while gcc behavior gets along with a normal > + * barrier(), llvm needs an

Re: [PATCH] compiler.h: Fix barrier_data() on clang

2020-10-14 Thread Nick Desaulniers
On Wed, Oct 14, 2020 at 2:26 PM Arvind Sankar wrote: > > Commit > 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually > exclusive") > > neglected to copy barrier_data() from compiler-gcc.h into > compiler-clang.h. The definition in compiler-gcc.h was really to work > around

[PATCH] compiler.h: Fix barrier_data() on clang

2020-10-14 Thread Arvind Sankar
Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") neglected to copy barrier_data() from compiler-gcc.h into compiler-clang.h. The definition in compiler-gcc.h was really to work around clang's more aggressive optimization, so this broke barrier_data() on