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

[Uros Bizjak <ubizjak@gmail.com>]

On Fri, Dec 13, 2024 at 4:35 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Sun,  8 Dec 2024 21:45:15 +0100 Uros Bizjak <ubizjak@gmail.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.