linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnd Bergmann <arnd@kernel.org>,
	linux-toolchains@vger.kernel.org,
	Mark Rutland <mark.rutland@arm.com>,
	Theodore Ts'o <tytso@mit.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues
Date: Fri, 8 Jan 2021 20:29:24 +0000	[thread overview]
Message-ID: <20210108202924.GY1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAHk-=whnKkj5CSbj-uG_MVVUsPZ6ppd_MFhZf_kpXDkh2MAVRA@mail.gmail.com>

On Fri, Jan 08, 2021 at 12:02:53PM -0800, Linus Torvalds wrote:
> Well, honestly, I'm always in favor of having people not use ancient
> compilers, but both of the issues at hand do seem to be specific to
> arm64.
> 
> The "gcc before 5.1 generates incorrect stack pointer writes on arm64"
> sounds pretty much deadly, and I think means that yes, for arm64 we
> simply need to require 5.1 or newer.
> 
> I also suspect there is much less reason to use old gcc's on arm64. I
> can't imagine that people really run very old setups, Is some old RHEL
> version even relevant for arm64?

For me, six years old for a compiler is really not "very old" - and,
when I first encountered this problem, it was over 12 months ago.
Apart from the kernel, I am not in the habbit of upgrading stuff for
the sake of upgrading - I tend to stick with what I have and what
works. Not everyone on this planet has a desire to have the latest
and greatest all the time.

Since then, I've _not_ wanted to change the compiler in case the
problem vanishes without explanation - it had the feeling of being
way more serious than a compiler bug, potentially a memory ordering
bug.

It took about a year just to start being able to work out what was
going on - it would take up to about three months to show for me,
and when it did, it spat out an ext4 inode checksum error and made
the rootfs read-only.

To "hide" that by upgrading the compiler, and then to be in the
situation where you do not trust any aarch64 machine with your data
is no real solution. That's exactly where I was until this had been
found. The aarch64 architecture had completely lost my trust as a
viable computing platform - and I was at the point of considering
disposing of all my aarch64 hardware and replacing it with x86.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2021-01-08 20:30 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 15:47 Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues Russell King - ARM Linux admin
2021-01-05 18:27 ` Darrick J. Wong
2021-01-05 19:50   ` Russell King - ARM Linux admin
2021-01-06 11:53 ` Mark Rutland
2021-01-06 12:13   ` Russell King - ARM Linux admin
2021-01-06 13:52   ` Russell King - ARM Linux admin
2021-01-06 17:20     ` Will Deacon
2021-01-06 17:46       ` Russell King - ARM Linux admin
2021-01-06 21:04       ` Arnd Bergmann
2021-01-06 22:00         ` Arnd Bergmann
2021-01-06 22:32       ` Russell King - ARM Linux admin
2021-01-07 11:18         ` Russell King - ARM Linux admin
2021-01-07 12:45           ` Russell King - ARM Linux admin
2021-01-07 13:16             ` Arnd Bergmann
2021-01-07 13:37               ` Russell King - ARM Linux admin
2021-01-07 16:27                 ` Theodore Ts'o
2021-01-07 17:00                   ` Florian Weimer
2021-01-07 21:48                   ` Arnd Bergmann
2021-01-07 22:14                     ` Russell King - ARM Linux admin
2021-01-07 22:41                       ` Eric Biggers
2021-01-08  8:21                         ` Ard Biesheuvel
2021-01-07 22:27                     ` Eric Biggers
2021-01-07 23:53                       ` Darrick J. Wong
2021-01-08  8:05                         ` Arnd Bergmann
2021-01-08  9:13                   ` Peter Zijlstra
2021-01-08 10:31                   ` Pavel Machek
2021-01-07 21:20                 ` Arnd Bergmann
2021-01-08  9:21                   ` Peter Zijlstra
2021-01-08  9:26                     ` Will Deacon
2021-01-08 20:02                       ` Linus Torvalds
2021-01-08 20:22                         ` Arnd Bergmann
2021-01-08 21:20                           ` Nick Desaulniers
2021-01-08 20:29                         ` Russell King - ARM Linux admin [this message]
2021-01-12 13:20                         ` Lukas Wunner
2021-01-12 13:31                           ` Florian Weimer
2021-01-12 13:46                             ` David Laight
2021-01-12 17:28                           ` Linus Torvalds
2021-01-14 13:13                             ` Lukas Wunner

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=20210108202924.GY1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=adilger.kernel@dilger.ca \
    --cc=arnd@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=will@kernel.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).