linux-alpha.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	 Arnd Bergmann <arnd@kernel.org>,
	linux-alpha@vger.kernel.org,  Arnd Bergmann <arnd@arndb.de>,
	 Richard Henderson <richard.henderson@linaro.org>,
	 Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	 Matt Turner <mattst88@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Marc Zyngier <maz@kernel.org>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	 linux-kernel@vger.kernel.org, Michael Cree <mcree@orcon.net.nz>,
	 Frank Scheiner <frank.scheiner@web.de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10
Date: Tue, 2 Jul 2024 00:50:42 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2406031953550.9248@angie.orcam.me.uk> (raw)
In-Reply-To: <12a3f8ac-c542-4065-a464-fc246e355d1d@paulmck-laptop>

On Mon, 3 Jun 2024, Paul E. McKenney wrote:

> >  This is a fairly recent addition, thank you for putting it all together.  
> > I used to rely solely on Documentation/memory-barriers.txt.  Thanks for 
> > the reference.
> 
> It has been in the kernel since April 2018, but OK.  And a big "thank you"

 When you've been around for 25+ years, 5 years back seems like yesterday.

> to all the people who made this possible and who continue contributing
> to it.  And Documentation/memory-barriers.txt still matters, though the
> long-term goal is for it to be subsumed into tools/memory-model.  Things
> like compiler optimizations make this difficult, but not impossible.

 I realise these are tough matters and I second your gratitude.

> Another precaution is to ensure that any contraints of a non-common-case
> architecture be tested for.  For example, if I add a 64-bit divide, I
> get yelled at promptly.  In contrast, that long list of byte accesses
> that Arnd posted were suffered in silence.  So they accumulated well
> past the point where they can reasonably be backed out.

 Well, it's easy to notice and yell when you get an unresolved link-time 
reference to __divdi3 or suchlike.  While such heisenbugs as those caused 
by the race condition from concurrent unprotected rmw accesses may all be 
too easily blamed on cosmic rays or any other random instability.

 Take for example the GCC bug I mentioned in my reply to Linus in this 
thread, GCC PR rtl-optimization/115565.  It took 20 years to spot, even 
though it's in heavily used code and it does not depend on timing: with 
the right conditions it will trigger every time.

 If I were aware of these issues, I would definitely have got at them 
sooner.  Anyway, as mentioned in the other reply, I've overcome system 
setup issues now and will be working on the problem discussed here.

  Maciej

  reply	other threads:[~2024-07-01 23:50 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03  8:11 [PATCH 00/14] alpha: cleanups for 6.10 Arnd Bergmann
2024-05-03  8:11 ` [PATCH 01/14] alpha: sort scr_mem{cpy,move}w() out Arnd Bergmann
2024-05-03  8:11 ` [PATCH 02/14] alpha: fix modversions for strcpy() et.al Arnd Bergmann
2024-05-03  8:11 ` [PATCH 03/14] alpha: add clone3() support Arnd Bergmann
2024-05-03  8:11 ` [PATCH 04/14] alpha: don't make functions public without a reason Arnd Bergmann
2024-05-03  8:11 ` [PATCH 05/14] alpha: sys_sio: fix misspelled ifdefs Arnd Bergmann
2024-05-03  8:11 ` [PATCH 06/14] alpha: missing includes Arnd Bergmann
2024-05-03  8:11 ` [PATCH 07/14] alpha: core_lca: take the unused functions out Arnd Bergmann
2024-05-03  8:11 ` [PATCH 08/14] alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest Arnd Bergmann
2024-05-03  8:11 ` [PATCH 09/14] alpha: trim the unused stuff from asm-offsets.c Arnd Bergmann
2024-05-03  8:11 ` [PATCH 10/14] alpha: remove DECpc AXP150 (Jensen) support Arnd Bergmann
2024-05-03 16:07   ` Linus Torvalds
2024-05-03 17:00   ` Al Viro
2024-05-03 20:07     ` Arnd Bergmann
2024-05-03  8:11 ` [PATCH 11/14] alpha: sable: remove early machine support Arnd Bergmann
2024-05-03  8:11 ` [PATCH 12/14] alpha: remove LCA and APECS based machines Arnd Bergmann
2024-05-03  8:11 ` [PATCH 13/14] alpha: cabriolet: remove EV5 CPU support Arnd Bergmann
2024-05-03  8:11 ` [PATCH 14/14] alpha: drop pre-EV56 support Arnd Bergmann
2024-05-04 15:00   ` Richard Henderson
2024-05-06 10:06     ` Arnd Bergmann
2024-06-03  6:02   ` Jiri Slaby
2024-06-04 13:58     ` Greg KH
2024-05-03 16:06 ` [PATCH 00/14] alpha: cleanups for 6.10 Matt Turner
2024-05-03 20:15   ` Arnd Bergmann
2024-05-06  9:16     ` Michael Cree
2024-05-06 10:11       ` Arnd Bergmann
2024-05-03 16:53 ` John Paul Adrian Glaubitz
2024-05-03 17:19   ` Paul E. McKenney
2024-05-27 23:49   ` Maciej W. Rozycki
2024-05-28 14:43     ` Paul E. McKenney
2024-05-29 18:50       ` Maciej W. Rozycki
2024-05-29 22:09         ` Paul E. McKenney
2024-05-30 22:59           ` Maciej W. Rozycki
2024-05-31  3:56           ` Maciej W. Rozycki
2024-05-31 19:33             ` Paul E. McKenney
2024-06-03 16:22               ` Maciej W. Rozycki
2024-06-03 17:08                 ` Paul E. McKenney
2024-07-01 23:50                   ` Maciej W. Rozycki [this message]
2024-05-30  1:08         ` Linus Torvalds
2024-05-30 22:57           ` Maciej W. Rozycki
2024-05-31  0:10             ` Linus Torvalds
2024-06-03 11:09               ` Maciej W. Rozycki
2024-06-03 11:36                 ` John Paul Adrian Glaubitz
2024-06-03 16:57                 ` Linus Torvalds
2024-07-01 23:48                   ` Maciej W. Rozycki
2024-05-31 15:48         ` Arnd Bergmann
2024-05-31 16:32           ` Linus Torvalds
2024-05-31 16:54             ` Arnd Bergmann
2024-06-01 13:51             ` David Laight
2024-07-01 23:48             ` Maciej W. Rozycki
2024-07-02  1:13               ` Linus Torvalds
2024-07-03  0:12                 ` Maciej W. Rozycki
2024-07-03  0:50                   ` Linus Torvalds
2024-07-04 22:21                     ` Maciej W. Rozycki
2024-06-03 11:33           ` Maciej W. Rozycki

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=alpine.DEB.2.21.2406031953550.9248@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=frank.scheiner@web.de \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=maz@kernel.org \
    --cc=mcree@orcon.net.nz \
    --cc=paulmck@kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).