linux-kernel - Re: [PATCH v3 0/6] Enable strict percpu address space checks

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]

Message-ID: <CAFULd4bJ71PT8-CetpF6fb7ufUQb24ZPNnStkvbjXSsuXGMqew@mail.gmail.com>
Date: Fri, 13 Dec 2024 05:28:50 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: x86@...nel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-bcachefs@...r.kernel.org, linux-arch@...r.kernel.org, 
	netdev@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, 
	Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, 
	Ingo Molnar <mingo@...nel.org>, Nadav Amit <nadav.amit@...il.com>, Brian Gerst <brgerst@...il.com>, 
	Dan Carpenter <dan.carpenter@...aro.org>, "H . Peter Anvin" <hpa@...or.com>, 
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3 0/6] Enable strict percpu address space checks

On Fri, Dec 13, 2024 at 4:35 AM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Sun,  8 Dec 2024 21:45:15 +0100 Uros Bizjak <ubizjak@...il.com> wrote:
>
> > Enable strict percpu address space checks via x86 named address space
> > qualifiers. Percpu variables are declared in __seg_gs/__seg_fs named
> > AS and kept named AS qualified until they are dereferenced via percpu
> > accessor. This approach enables various compiler checks for
> > cross-namespace variable assignments.
> >
> > Please note that current version of sparse doesn't know anything about
> > __typeof_unqual__() operator. Avoid the usage of __typeof_unqual__()
> > when sparse checking is active to prevent sparse errors with unknowing
> > keyword. The proposed patch by Dan Carpenter to implement
> > __typeof_unqual__() handling in sparse is located at:
>
> google("what the hell is typeof_unequal") failed me.

It is not "typeof_unequal", but "typeof_unqual", as in "unqualified".

Apparently, google does not like expletives, googling for "What is
typeof_unqual?" returns some very informative hits, e.g.:

https://en.cppreference.com/w/c/keyword/typeof_unqual
https://learn.microsoft.com/en-us/cpp/c-language/typeof-unqual-c?view=msvc-170
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
https://dev.to/pauljlucas/typeof-in-c23-55p2

> I think it would be nice to include within the changelog (and code
> comments!) an explanation-for-others of what this thing is and why
> anyone would want to use it.  Rather than assuming that all kernel
> developers are typeof() experts!

The comment above definition of TYPEOF_UNQUAL in [PATCH 2/6]
summarises the above as:

+ * Define TYPEOF_UNQUAL() to use __typeof_unqual__() as typeof
+ * operator when available, to return unqualified type of the exp.

which is basically what the standard says in its reference document.

Thanks,
Uros.