linux-kernel - Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 13 May 2024 11:26:14 +0200
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Akira Yokosawa <akiyks@...il.com>, paulmck@...nel.org
Cc: arnd@...db.de, ink@...assic.park.msu.ru, linux-alpha@...r.kernel.org, 
 linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
 mattst88@...il.com,  richard.henderson@...aro.org,
 torvalds@...ux-foundation.org,  viro@...iv.linux.org.uk, Ulrich Teichert
 <krypton@...ich-teichert.org>
Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Mon, 2024-05-13 at 12:50 +0900, Akira Yokosawa wrote:
> > So why didn't the people running current mainline on pre-EV56 Alpha
> > systems notice?  One possibility is that they are upgrading their
> > kernels only occasionally.  Another possibility is that they are seeing
> > the failures, but are not tracing the obtuse failure modes back to the
> > change(s) in question.  Yet another possibility is that the resulting
> > failures are very low probability, with mean times to failure that are
> > so long that you won't notice anything on a single system.
> 
> Another possibility is that the Jensen system was booted into uni processer
> mode.  Looking at the early boot log [1] provided by Ulrich (+CCed) back in
> Sept. 2021, I see the following by running "grep -i cpu":
> 
> > > > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
> 
> [    0.000000] Memory: 90256K/131072K available (8897K kernel code, 9499K rwdata, \
> 2704K rodata, 312K init, 437K bss, 40816K reserved, 0K cma-reserved) [    0.000000] \
> random: get_random_u64 called from __kmem_cache_create+0x54/0x600 with crng_init=0 [  \
> 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [    0.000000]
>                                                      ^^^^^^
> 
> Without any concurrent atomic updates, the "broken" atomic accesses won't
> matter, I guess.

At least from my perspective, the machines that matter for hobbyists are uni-processors,
i.e. workstations. I don't know of any early Alpha workstations from the tip of my head
that are multi-processor.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913