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'.
>
>
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:
>
>
>
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
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,
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
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
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
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
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.
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"
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
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
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.
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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,
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
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
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
>
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
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
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
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
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
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
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
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,
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
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
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
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:
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
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
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
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
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
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
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
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
>
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
[ 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
[ 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
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:
> > >>
> > >>
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
>
>
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
>
>
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
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
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
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
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?
>>
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?
>>
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
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
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
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
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
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 - 100 of 106 matches
Mail list logo