linux-kernel - Re: [GIT pull] timers/vdso for v7.0-rc1

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHk-=whO6onPiyQcyVa1ihg3rYWog0680+wu=Jc7s34Je5fO2A@mail.gmail.com>
Date: Tue, 10 Feb 2026 18:03:54 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [GIT pull] timers/vdso for v7.0-rc1

On Tue, 10 Feb 2026 at 17:38, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So __builtin_memcpy() at least should work. I'm still not convinced
> that it's necessarily the *better* option, but at least my immediate
> worries are not a problem.

So because I worried about the interaction with named address spaces,
and started looking at the implementation closer, I just went
"WHAA??".

The __put_unaligned_t() implementation looks entirely sane and straightforward.

But that __get_unaligned_t() code is just a mess. Why does it play
those crazy type games? The normal way to avoid all of that when the
worry is aliasing is to just use a union.

IOW, why is it doing all those odd things, when it would appear that
the simple implementation would be something like this:

    #define __get_unaligned_t(type, ptr) ({                                 \
        union { type __val; char __arr[]; } __res;                      \
        __builtin_memcpy(__res.__arr, (void *)(ptr), sizeof(type));     \
        __res.__val;                                                    \
    })

which is a lot more idiomatic and doesn't play any odd games with
types (you could make "__arr[]" do that "sizeof(type)" too, but there
isn't really any upside)

Am I missing some odd case?

                Linus