Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada wrote: > Sorry for chiming in late. > > I noticed this thread today, > honestly, the commit made me upset. > > > Can I suggest another way to make it less fragile? > __attribute((...)) can be placed after 'struct'. > >

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada wrote: > Sorry for chiming in late. > > I noticed this thread today, > honestly, the commit made me upset. > > > Can I suggest another way to make it less fragile? > __attribute((...)) can be placed after 'struct'. > > > So, we can write: > > >

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada wrote: > > Can I suggest another way to make it less fragile? > __attribute((...)) can be placed after 'struct'. That avoids the actual bug, but it wouldn't have helped _find_ the problem in the first place. If

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada wrote: > > Can I suggest another way to make it less fragile? > __attribute((...)) can be placed after 'struct'. That avoids the actual bug, but it wouldn't have helped _find_ the problem in the first place. If somebody ever does the same thing,

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

Hi Linus, 2018-02-22 7:47 GMT+09:00 Linus Torvalds : > On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero > wrote: >> >> One can see that offsets used to access various members of struct path are >> different, and also that the

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

Hi Linus, 2018-02-22 7:47 GMT+09:00 Linus Torvalds : > On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero > wrote: >> >> One can see that offsets used to access various members of struct path are >> different, and also that the original file from step 3 contains an object >> named

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 4:23 PM, Kees Cook wrote: > On Wed, Feb 21, 2018 at 4:22 PM, Linus Torvalds > wrote: >> On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote: >>> >>> Do you want me to send the patch for this, or do

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 4:23 PM, Kees Cook wrote: > On Wed, Feb 21, 2018 at 4:22 PM, Linus Torvalds > wrote: >> On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote: >>> >>> Do you want me to send the patch for this, or do you already have it >>> prepared? >> >> I'd rather get something explicitly

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 4:22 PM, Linus Torvalds wrote: > On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote: >> >> Do you want me to send the patch for this, or do you already have it >> prepared? > > I'd rather get something explicitly tested.

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 4:22 PM, Linus Torvalds wrote: > On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote: >> >> Do you want me to send the patch for this, or do you already have it >> prepared? > > I'd rather get something explicitly tested. I tried my earlier patch > with "make allmodconfig"

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote: > > Do you want me to send the patch for this, or do you already have it > prepared? I'd rather get something explicitly tested. I tried my earlier patch with "make allmodconfig" (and a fix to nfsd to make it compile), but

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote: > > Do you want me to send the patch for this, or do you already have it > prepared? I'd rather get something explicitly tested. I tried my earlier patch with "make allmodconfig" (and a fix to nfsd to make it compile), but now I'm back to testing

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 3:24 PM, Linus Torvalds wrote: > On Wed, Feb 21, 2018 at 2:52 PM, Kees Cook wrote: >> >> I'll play with Linus's suggestion and see what we get. > > It may be just as well to just include from > and be done with it.

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 3:24 PM, Linus Torvalds wrote: > On Wed, Feb 21, 2018 at 2:52 PM, Kees Cook wrote: >> >> I'll play with Linus's suggestion and see what we get. > > It may be just as well to just include from > and be done with it. Hah, yeah, that would certainly solve it too. :) > I

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:47 PM, Linus Torvalds wrote: > And other attribute specifiers we encourage people to put in other > parts of the type, like __user etc, so they don't have that same > parsing issue. Looking at other attributes we use on structs, we may

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:47 PM, Linus Torvalds wrote: > And other attribute specifiers we encourage people to put in other > parts of the type, like __user etc, so they don't have that same > parsing issue. Looking at other attributes we use on structs, we may have similar risks for these:

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:52 PM, Kees Cook wrote: > > I'll play with Linus's suggestion and see what we get. It may be just as well to just include from and be done with it. If you look at that hacky script I documented in commit 23c35f48f5fb ("pinctrl: remove include

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:52 PM, Kees Cook wrote: > > I'll play with Linus's suggestion and see what we get. It may be just as well to just include from and be done with it. If you look at that hacky script I documented in commit 23c35f48f5fb ("pinctrl: remove include file from ") and run it

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero wrote: > One can see that offsets used to access various members of struct path are > different, and also that the original file from step 3 contains an object > named "__randomize_layout". > > This is caused by a

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero wrote: > One can see that offsets used to access various members of struct path are > different, and also that the original file from step 3 contains an object > named "__randomize_layout". > > This is caused by a fact that the current version

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero wrote: > > One can see that offsets used to access various members of struct path are > different, and also that the original file from step 3 contains an object > named "__randomize_layout". Whee. Thanks for

Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero wrote: > > One can see that offsets used to access various members of struct path are > different, and also that the original file from step 3 contains an object > named "__randomize_layout". Whee. Thanks for root-causing this issue, and this

RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On 18.11.2017 06:14, Kees Cook wrote: > On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: >> On 2017-11-17 04:55 PM, Linus Torvalds wrote: >>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: I am still getting the crash at

RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On 18.11.2017 06:14, Kees Cook wrote: > On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: >> On 2017-11-17 04:55 PM, Linus Torvalds wrote: >>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: I am still getting the crash at d9e12200852d, I figured I would double-check

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 9:29 PM, Linus Torvalds wrote: > On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook wrote: >> >> FWIW, myself doing a build at d9e12200852d with and without >> GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 9:29 PM, Linus Torvalds wrote: > On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook wrote: >> >> FWIW, myself doing a build at d9e12200852d with and without >> GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output >> where I did spot-checks. > > That would probably

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook wrote: > > FWIW, myself doing a build at d9e12200852d with and without > GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output > where I did spot-checks. That would probably be a good thing to check anyway - check

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook wrote: > > FWIW, myself doing a build at d9e12200852d with and without > GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output > where I did spot-checks. That would probably be a good thing to check anyway - check the difference between

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: > On 2017-11-17 04:55 PM, Linus Torvalds wrote: >> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: >>> >>> I am still getting the crash at d9e12200852d, I figured I would >>> double-check the

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: > On 2017-11-17 04:55 PM, Linus Torvalds wrote: >> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: >>> >>> I am still getting the crash at d9e12200852d, I figured I would >>> double-check the "good" and "bad" kernels before starting a

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-17 04:55 PM, Linus Torvalds wrote: > On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: >> >> I am still getting the crash at d9e12200852d, I figured I would >> double-check the "good" and "bad" kernels before starting a full bisect. > > .. but without

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-17 04:55 PM, Linus Torvalds wrote: > On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: >> >> I am still getting the crash at d9e12200852d, I figured I would >> double-check the "good" and "bad" kernels before starting a full bisect. > > .. but without GCC_PLUGIN_RANDSTRUCT it's

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: > > I am still getting the crash at d9e12200852d, I figured I would > double-check the "good" and "bad" kernels before starting a full bisect. .. but without GCC_PLUGIN_RANDSTRUCT it's solid? Kees removed even the

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: > > I am still getting the crash at d9e12200852d, I figured I would > double-check the "good" and "bad" kernels before starting a full bisect. .. but without GCC_PLUGIN_RANDSTRUCT it's solid? Kees removed even the baseline "randomize pure

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-17 01:26 PM, Kees Cook wrote: > On Fri, Nov 17, 2017 at 11:03 AM, Patrick McLean wrote: >> On 2017-11-16 04:54 PM, Kees Cook wrote: >>> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: On 2017-11-11 09:31 AM, Linus Torvalds wrote:

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-17 01:26 PM, Kees Cook wrote: > On Fri, Nov 17, 2017 at 11:03 AM, Patrick McLean wrote: >> On 2017-11-16 04:54 PM, Kees Cook wrote: >>> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: On 2017-11-11 09:31 AM, Linus Torvalds wrote: > Boris Lukashev points out that

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 11:03 AM, Patrick McLean wrote: > On 2017-11-16 04:54 PM, Kees Cook wrote: >> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: >>> On 2017-11-11 09:31 AM, Linus Torvalds wrote: Boris Lukashev points out that Patrick

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 11:03 AM, Patrick McLean wrote: > On 2017-11-16 04:54 PM, Kees Cook wrote: >> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: >>> On 2017-11-11 09:31 AM, Linus Torvalds wrote: Boris Lukashev points out that Patrick should probably check a newer version of

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-16 04:54 PM, Kees Cook wrote: > On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: >> On 2017-11-11 09:31 AM, Linus Torvalds wrote: >>> Boris Lukashev points out that Patrick should probably check a newer >>> version of gcc. >>> >>> I looked around, and in one

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-16 04:54 PM, Kees Cook wrote: > On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: >> On 2017-11-11 09:31 AM, Linus Torvalds wrote: >>> Boris Lukashev points out that Patrick should probably check a newer >>> version of gcc. >>> >>> I looked around, and in one of the emails,

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: > On 2017-11-11 09:31 AM, Linus Torvalds wrote: >> Boris Lukashev points out that Patrick should probably check a newer >> version of gcc. >> >> I looked around, and in one of the emails, Patrick said: >> >> "No

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote: > On 2017-11-11 09:31 AM, Linus Torvalds wrote: >> Boris Lukashev points out that Patrick should probably check a newer >> version of gcc. >> >> I looked around, and in one of the emails, Patrick said: >> >> "No changes, both the working

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Tue, Nov 14, 2017 at 3:53 PM, Rasmus Villemoes wrote: > > Odd. 7.2 and 7.1 (both of which I've just compiled from source, no > special configure flags or anything) generate exactly the same (good) > code for fs/namespace.o after patching. I also tried with >

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Tue, Nov 14, 2017 at 3:53 PM, Rasmus Villemoes wrote: > > Odd. 7.2 and 7.1 (both of which I've just compiled from source, no > special configure flags or anything) generate exactly the same (good) > code for fs/namespace.o after patching. I also tried with > CONFIG_CC_OPTIMIZE_FOR_SIZE=y just

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On 14 November 2017 at 23:43, Linus Torvalds wrote: > On Tue, Nov 14, 2017 at 2:24 PM, Rasmus Villemoes > wrote: >> >> Can you be more specific? That's not what I see with gcc 7.1. > > I have gcc-7.2.1, and it made a horrible mess of the

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On 14 November 2017 at 23:43, Linus Torvalds wrote: > On Tue, Nov 14, 2017 at 2:24 PM, Rasmus Villemoes > wrote: >> >> Can you be more specific? That's not what I see with gcc 7.1. > > I have gcc-7.2.1, and it made a horrible mess of the do_mount() code. Odd. 7.2 and 7.1 (both of which I've

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Tue, Nov 14, 2017 at 2:24 PM, Rasmus Villemoes wrote: > > Can you be more specific? That's not what I see with gcc 7.1. I have gcc-7.2.1, and it made a horrible mess of the do_mount() code. Look for the comment "/* Separate the per-mountpoint flags */" and do the

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Tue, Nov 14, 2017 at 2:24 PM, Rasmus Villemoes wrote: > > Can you be more specific? That's not what I see with gcc 7.1. I have gcc-7.2.1, and it made a horrible mess of the do_mount() code. Look for the comment "/* Separate the per-mountpoint flags */" and do the obvious conversion of the

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On 14 November 2017 at 00:54, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 3:30 PM, Linus Torvalds > wrote: >> >> So let's just rewrite that mnt_flags conversion that way, justr to get >> gcc to generate the obvious code. > > Oh

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On 14 November 2017 at 00:54, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 3:30 PM, Linus Torvalds > wrote: >> >> So let's just rewrite that mnt_flags conversion that way, justr to get >> gcc to generate the obvious code. > > Oh wow. I tried to do the same thing in fs/namespace.c where it

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Mon, Nov 13, 2017 at 3:30 PM, Linus Torvalds wrote: > > So let's just rewrite that mnt_flags conversion that way, justr to get > gcc to generate the obvious code. Oh wow. I tried to do the same thing in fs/namespace.c where it does the reverse bit translation,

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Mon, Nov 13, 2017 at 3:30 PM, Linus Torvalds wrote: > > So let's just rewrite that mnt_flags conversion that way, justr to get > gcc to generate the obvious code. Oh wow. I tried to do the same thing in fs/namespace.c where it does the reverse bit translation, and gcc makes a _horrible_ mess

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Mon, Nov 13, 2017 at 2:59 PM, Rasmus Villemoes wrote: >> Sadly, gcc makes a mess of it and actually generates code that looks >> like the original C.[...] > > Actually, new enough gcc (7.1, I think) does contain a pattern that does > this, but unfortunately only if

Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Mon, Nov 13, 2017 at 2:59 PM, Rasmus Villemoes wrote: >> Sadly, gcc makes a mess of it and actually generates code that looks >> like the original C.[...] > > Actually, new enough gcc (7.1, I think) does contain a pattern that does > this, but unfortunately only if one spells it > > y |= (x

bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Thu, Nov 09 2017, Linus Torvalds wrote: > The code disassembles to > >0: 83 c9 08 or $0x8,%ecx >3: 40 f6 c6 04 test $0x4,%sil >7: 0f 45 d1 cmovne %ecx,%edx >a: 89 d1mov%edx,%ecx >c:

bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11]

On Thu, Nov 09 2017, Linus Torvalds wrote: > The code disassembles to > >0: 83 c9 08 or $0x8,%ecx >3: 40 f6 c6 04 test $0x4,%sil >7: 0f 45 d1 cmovne %ecx,%edx >a: 89 d1mov%edx,%ecx >c: 80 cd 04 or

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-11 09:31 AM, Linus Torvalds wrote: > Boris Lukashev points out that Patrick should probably check a newer > version of gcc. > > I looked around, and in one of the emails, Patrick said: > > "No changes, both the working and broken kernels were built with >distro-provided gcc

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-11 09:31 AM, Linus Torvalds wrote: > Boris Lukashev points out that Patrick should probably check a newer > version of gcc. > > I looked around, and in one of the emails, Patrick said: > > "No changes, both the working and broken kernels were built with >distro-provided gcc

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

Boris Lukashev points out that Patrick should probably check a newer version of gcc. I looked around, and in one of the emails, Patrick said: "No changes, both the working and broken kernels were built with distro-provided gcc 5.4.0 and binutils 2.28.1" and gcc-5.4.0 is certainly not very

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

Boris Lukashev points out that Patrick should probably check a newer version of gcc. I looked around, and in one of the emails, Patrick said: "No changes, both the working and broken kernels were built with distro-provided gcc 5.4.0 and binutils 2.28.1" and gcc-5.4.0 is certainly not very

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 6:36 PM, Linus Torvalds wrote: > [ Bringing in the gcc plugin people and the kernel hardening list, > since it now is no longer even remotely looking like a nfsd, vfs or > filesystem issue any more ] > > Kees, Emese, > the whole thread is on

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 6:36 PM, Linus Torvalds wrote: > [ Bringing in the gcc plugin people and the kernel hardening list, > since it now is no longer even remotely looking like a nfsd, vfs or > filesystem issue any more ] > > Kees, Emese, > the whole thread is on lkml, but there's clearly

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, 8 Nov 2017 16:43:17 -0800 Patrick McLean wrote: > As of 4.13.11 (and also with 4.14-rc) we have an issue where when > serving nfs4 sometimes we get the following BUG. When this bug happens, > it usually also causes the motherboard to no longer POST until we >

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, 8 Nov 2017 16:43:17 -0800 Patrick McLean wrote: > As of 4.13.11 (and also with 4.14-rc) we have an issue where when > serving nfs4 sometimes we get the following BUG. When this bug happens, > it usually also causes the motherboard to no longer POST until we > externally re-flash the BIOS

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

[ Bringing in the gcc plugin people and the kernel hardening list, since it now is no longer even remotely looking like a nfsd, vfs or filesystem issue any more ] Kees, Emese, the whole thread is on lkml, but there's clearly something horribly wrong with RANDSTRUCT, and it's not new even though

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

[ Bringing in the gcc plugin people and the kernel hardening list, since it now is no longer even remotely looking like a nfsd, vfs or filesystem issue any more ] Kees, Emese, the whole thread is on lkml, but there's clearly something horribly wrong with RANDSTRUCT, and it's not new even though

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 08:13:06PM -0500, J. Bruce Fields wrote: > On Fri, Nov 10, 2017 at 03:26:27PM -0800, Patrick McLean wrote: > > > > > > On 2017-11-10 10:42 AM, Linus Torvalds wrote: > > > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean > > > wrote: > > >> > > >>

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 08:13:06PM -0500, J. Bruce Fields wrote: > On Fri, Nov 10, 2017 at 03:26:27PM -0800, Patrick McLean wrote: > > > > > > On 2017-11-10 10:42 AM, Linus Torvalds wrote: > > > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean > > > wrote: > > >> > > >> Something must have

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 03:26:27PM -0800, Patrick McLean wrote: > > > On 2017-11-10 10:42 AM, Linus Torvalds wrote: > > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: > >> > >> Something must have changed since 4.13.8 to trigger this though. > > > > Arnd pointed to

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 03:26:27PM -0800, Patrick McLean wrote: > > > On 2017-11-10 10:42 AM, Linus Torvalds wrote: > > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: > >> > >> Something must have changed since 4.13.8 to trigger this though. > > > > Arnd pointed to some commits that

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-10 03:26 PM, Patrick McLean wrote: > > > On 2017-11-10 10:42 AM, Linus Torvalds wrote: >> On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: >>> >>> Something must have changed since 4.13.8 to trigger this though. >> >> Arnd pointed to some commits that might

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-10 03:26 PM, Patrick McLean wrote: > > > On 2017-11-10 10:42 AM, Linus Torvalds wrote: >> On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: >>> >>> Something must have changed since 4.13.8 to trigger this though. >> >> Arnd pointed to some commits that might be relevant for the

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-10 10:42 AM, Linus Torvalds wrote: > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: >> >> Something must have changed since 4.13.8 to trigger this though. > > Arnd pointed to some commits that might be relevant for the cp210x > module, but those are all

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-10 10:42 AM, Linus Torvalds wrote: > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: >> >> Something must have changed since 4.13.8 to trigger this though. > > Arnd pointed to some commits that might be relevant for the cp210x > module, but those are all already in 4.13.8, so

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: > > Something must have changed since 4.13.8 to trigger this though. Well, yes and no. Obviously something changed, but it doesn't necessarily have to be anything particular. Almost every time we've seen compiler bugs,

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote: > > Something must have changed since 4.13.8 to trigger this though. Well, yes and no. Obviously something changed, but it doesn't necessarily have to be anything particular. Almost every time we've seen compiler bugs, it's been an

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 2:58 AM, Patrick McLean wrote: > On 2017-11-09 12:04 PM, Linus Torvalds wrote: >> On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote: > > We will check our fork against the in-kernel cp201x driver to make sure > we didn't miss

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 10, 2017 at 2:58 AM, Patrick McLean wrote: > On 2017-11-09 12:04 PM, Linus Torvalds wrote: >> On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote: > > We will check our fork against the in-kernel cp201x driver to make sure > we didn't miss anything, but it seems odd we would be

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 12:04 PM, Linus Torvalds wrote: > On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote: >> >> We do have CONFIG_GCC_PLUGIN_STRUCTLEAK and >> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled on these boxes as well as >> CONFIG_GCC_PLUGIN_RANDSTRUCT as you pointed

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 12:04 PM, Linus Torvalds wrote: > On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote: >> >> We do have CONFIG_GCC_PLUGIN_STRUCTLEAK and >> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled on these boxes as well as >> CONFIG_GCC_PLUGIN_RANDSTRUCT as you pointed out before. > > It

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 11:51 AM, Patrick McLean wrote: > On 2017-11-09 11:37 AM, Al Viro wrote: >> On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: >> Here is the BUG we are getting: > [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at > 0230

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 11:51 AM, Patrick McLean wrote: > On 2017-11-09 11:37 AM, Al Viro wrote: >> On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: >> Here is the BUG we are getting: > [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at > 0230

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 12:47 PM, J. Bruce Fields wrote: > On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: >> Anyway, that cmovne noise makes it a bit hard to see the actual part >> that matters (and that traps) but I'm almost certain that it's the >> "mnt->mnt_sb->s_flags" loading that is

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 12:47 PM, J. Bruce Fields wrote: > On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: >> Anyway, that cmovne noise makes it a bit hard to see the actual part >> that matters (and that traps) but I'm almost certain that it's the >> "mnt->mnt_sb->s_flags" loading that is

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 09, 2017 at 12:04:19PM -0800, Linus Torvalds wrote: > That case has probably not gotten a huge amount of testing. As Al > points out, it can cause absolutely horrendous cache access pattern > changes, but it might also be triggering some corruption in case > there's a problem with

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 09, 2017 at 12:04:19PM -0800, Linus Torvalds wrote: > That case has probably not gotten a huge amount of testing. As Al > points out, it can cause absolutely horrendous cache access pattern > changes, but it might also be triggering some corruption in case > there's a problem with

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: > Anyway, that cmovne noise makes it a bit hard to see the actual part > that matters (and that traps) but I'm almost certain that it's the > "mnt->mnt_sb->s_flags" loading that is part of calculate_f_flags() > when it then does > >

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: > Anyway, that cmovne noise makes it a bit hard to see the actual part > that matters (and that traps) but I'm almost certain that it's the > "mnt->mnt_sb->s_flags" loading that is part of calculate_f_flags() > when it then does > >

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote: > > We do have CONFIG_GCC_PLUGIN_STRUCTLEAK and > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled on these boxes as well as > CONFIG_GCC_PLUGIN_RANDSTRUCT as you pointed out before. It might be worth just verifying

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote: > > We do have CONFIG_GCC_PLUGIN_STRUCTLEAK and > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled on these boxes as well as > CONFIG_GCC_PLUGIN_RANDSTRUCT as you pointed out before. It might be worth just verifying without RANDSTRUCT in

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 11:37 AM, Al Viro wrote: > On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: > >>> Here is the BUG we are getting: [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at 0230 [ 58.963918] IP: vfs_statfs+0x73/0xb0 >> >> The

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 11:37 AM, Al Viro wrote: > On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: > >>> Here is the BUG we are getting: [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at 0230 [ 58.963918] IP: vfs_statfs+0x73/0xb0 >> >> The

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 11:38 AM, Al Viro wrote: > On Thu, Nov 09, 2017 at 11:34:19AM -0800, Patrick McLean wrote: > >>> In particular, there are *no* nfsd changes in that 4.13.8..4.13.11 >>> range. There is a bunch of xfs changes, though. What's the underlying >>> filesystem that you are exporting? >>

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-09 11:38 AM, Al Viro wrote: > On Thu, Nov 09, 2017 at 11:34:19AM -0800, Patrick McLean wrote: > >>> In particular, there are *no* nfsd changes in that 4.13.8..4.13.11 >>> range. There is a bunch of xfs changes, though. What's the underlying >>> filesystem that you are exporting? >>

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 09, 2017 at 11:34:19AM -0800, Patrick McLean wrote: > > In particular, there are *no* nfsd changes in that 4.13.8..4.13.11 > > range. There is a bunch of xfs changes, though. What's the underlying > > filesystem that you are exporting? > > It's an ext4 filesystem. Had there been

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Thu, Nov 09, 2017 at 11:34:19AM -0800, Patrick McLean wrote: > > In particular, there are *no* nfsd changes in that 4.13.8..4.13.11 > > range. There is a bunch of xfs changes, though. What's the underlying > > filesystem that you are exporting? > > It's an ext4 filesystem. Had there been

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: > > Here is the BUG we are getting: > >> [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at > >> 0230 > >> [ 58.963918] IP: vfs_statfs+0x73/0xb0 > > The code disassembles to > 2a:* 48 8b b7 30

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote: > > Here is the BUG we are getting: > >> [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at > >> 0230 > >> [ 58.963918] IP: vfs_statfs+0x73/0xb0 > > The code disassembles to > 2a:* 48 8b b7 30

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-08 06:40 PM, Linus Torvalds wrote: > On Wed, Nov 8, 2017 at 4:43 PM, Patrick McLean wrote: >> As of 4.13.11 (and also with 4.14-rc) we have an issue where when >> serving nfs4 sometimes we get the following BUG. When this bug happens, >> it usually also causes

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On 2017-11-08 06:40 PM, Linus Torvalds wrote: > On Wed, Nov 8, 2017 at 4:43 PM, Patrick McLean wrote: >> As of 4.13.11 (and also with 4.14-rc) we have an issue where when >> serving nfs4 sometimes we get the following BUG. When this bug happens, >> it usually also causes the motherboard to no

  1   2   >