On Mon, May 11, 2026 at 11:34:53AM +0200, Marco Elver wrote:
> 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.
Thanks!
> > > 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.
Ack.
> > 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.
Ouch, I see.
> 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.
Ack.
--
Cheers,
Harry / Hyeonggon
