On Mon, 11 May 2026 at 10:31, 'Harry Yoo (Oracle)' via kasan-dev
<[email protected]> wrote:
>
> On Fri, May 08, 2026 at 04:21:36PM +0200, Marco Elver wrote:
> > I think I have a solution for this mess, see below.
> >
> > I would not send it as 1 series, but only include the slab changes (+
> > instruction_pointer.h change to introduce _CODE_LOCATION_) as one
> > series, to go through the slab tree. The rest of the patches would go to
> > respective arch maintainers.
>
> I'm assuming this will be a follow-up and reviewing patch 1
> (and waiting for Jon's thuoghts on patch 2)
I'll be sending v4 shortly.
> > diff --git a/include/linux/instruction_pointer.h
> > b/include/linux/instruction_pointer.h
> > index aa0b3ffea935..dfe73aafddb8 100644
> > --- a/include/linux/instruction_pointer.h
> > +++ b/include/linux/instruction_pointer.h
> > @@ -8,6 +8,30 @@
> >
> > #ifndef _THIS_IP_
> > #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
> > +/*
> > + * The current generic definition of _THIS_IP_ is considered broken by GCC
> > [1]
> > + * and Clang [2]. In particular, the address of a label is only expected
> > to be
> > + * used with a computed goto.
> > + *
> > + * [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071
> > + * [2] https://github.com/llvm/llvm-project/issues/138272
> > + *
> > + * Mark it as broken, so that appropriate fallback options can be
> > implemented
> > + * for architectures that do not define their won _THIS_IP_.
> > + */
> > +#define HAS_BROKEN_THIS_IP
> > +#endif
>
> As long as _THIS_IP_ is broken on some arches, it cannot be used anyway
> when in a general API that can be used by arbitrary users?
It more or less works today, and for debugging or tracing it's "good
enough" in most cases.
The plan would be to phase out the generic _THIS_IP_ once all
architectures have a correct _THIS_IP_ implementation.
> Is it something that can be fixed in all arches over time?
Yes, I have patches for that.
> > +/*
> > + * _CODE_LOCATION_ provides a unique identifier for the current code
> > location.
> > + * When _THIS_IP_ is broken (generic version), we fall back to a static
> > marker
> > + * which guarantees uniqueness and resolves to a constant address at link
> > time,
> > + * avoiding runtime overhead and compiler optimizations breaking it.
> > + */
> > +#ifdef HAS_BROKEN_THIS_IP
> > +#define _CODE_LOCATION_ ({ static const char __here; (unsigned
> > long)&__here; })
>
> Nice!
>
> Yes, we don't really need the exact code location
> for partitioning kmalloc caches.
>
> IIRC lockdep does a similar thing to define lock classes (unique for
> each lock init location)
>
> > +#else
> > +#define _CODE_LOCATION_ _THIS_IP_
> > #endif
>
> Probably we don't need this fallback?
x86-64 is the only arch that has working fast _THIS_IP_, and adding
static __here markers to bss is rather wasteful.
More architectures will be supporting _THIS_IP_ properly once I get to
send the patches. The mainstream architectures all have a reasonable
and fast way to get the current IP, so we don't need to waste bss
space there.
