From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Patrick McLean <chutzpah@gentoo.org>,
Bruce Fields <bfields@redhat.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
stable <stable@vger.kernel.org>,
Thorsten Leemhuis <regressions@leemhuis.info>
Subject: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11
Date: Thu, 9 Nov 2017 21:16:13 +0000 [thread overview]
Message-ID: <20171109211613.GE21978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFwqUbd5xVno7tH+yYD=yeu4nBdY=mpZQ+3fA0OEPS_WtQ@mail.gmail.com>
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 the plugin, or with some piece of kernel code
> that gets confused by it.
I suspect that it might be an effect of randomize shite done both to
struct mount *AND* to struct vfsmount embedded into it. With
pointers to embedded struct vfsmount kept around a lot, and container_of()
used to get from them to corresponding struct mount.
That smells like a combination of idiocy that might have never occured
to the authors of said gcc plugin.
On the other hand, triggered gcc bugs certainly do add randomness, so good
luck explaining to the security community that it's not a good idea...
next prev parent reply other threads:[~2017-11-09 21:16 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 0:43 [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11 Patrick McLean
2017-11-09 2:40 ` Linus Torvalds
2017-11-09 3:45 ` Al Viro
2017-11-09 19:34 ` Patrick McLean
2017-11-09 19:38 ` Al Viro
2017-11-09 19:42 ` Patrick McLean
2017-11-09 19:37 ` Al Viro
2017-11-09 19:51 ` Patrick McLean
2017-11-09 20:04 ` Linus Torvalds
2017-11-09 21:16 ` Al Viro [this message]
2017-11-10 1:58 ` Patrick McLean
2017-11-10 13:53 ` Arnd Bergmann
2017-11-10 18:42 ` Linus Torvalds
2017-11-10 23:26 ` Patrick McLean
2017-11-11 0:27 ` Patrick McLean
2017-11-11 2:36 ` Linus Torvalds
2017-11-11 16:13 ` Kees Cook
2017-11-11 17:31 ` Linus Torvalds
2017-11-13 22:48 ` Patrick McLean
2017-11-17 0:54 ` Kees Cook
2017-11-17 19:03 ` Patrick McLean
2017-11-17 21:26 ` Kees Cook
2017-11-18 0:27 ` Patrick McLean
2017-11-18 0:55 ` Linus Torvalds
2017-11-18 1:54 ` Patrick McLean
2017-11-18 5:14 ` Kees Cook
2017-11-18 5:29 ` Linus Torvalds
2017-11-18 8:20 ` Kees Cook
2018-02-21 22:19 ` RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11) Maciej S. Szmigiero
2018-02-21 22:47 ` Linus Torvalds
2018-02-21 23:34 ` Kees Cook
2018-03-05 9:27 ` Masahiro Yamada
2018-03-05 19:15 ` Kees Cook
2018-03-05 19:18 ` Linus Torvalds
2018-02-21 22:52 ` Kees Cook
2018-02-21 23:24 ` Linus Torvalds
2018-02-22 0:12 ` Kees Cook
2018-02-22 0:22 ` Linus Torvalds
2018-02-22 0:23 ` Kees Cook
2018-02-22 0:27 ` Kees Cook
2017-11-11 1:13 ` [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11 J. Bruce Fields
2017-11-11 2:32 ` Al Viro
2017-11-10 1:47 ` Patrick McLean
2017-11-09 20:47 ` J. Bruce Fields
2017-11-09 23:07 ` Patrick McLean
2017-11-13 22:59 ` bit tweaks [was: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11] Rasmus Villemoes
2017-11-13 23:30 ` Linus Torvalds
2017-11-13 23:54 ` Linus Torvalds
2017-11-11 2:47 ` [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11 Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171109211613.GE21978@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bfields@redhat.com \
--cc=chutzpah@gentoo.org \
--cc=darrick.wong@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=regressions@leemhuis.info \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).