On Thu, 14 May 2026 at 10:22, David Laight <[email protected]> wrote: > > On Mon, 11 May 2026 22:00:49 +0200 > Marco Elver <[email protected]> wrote: > > > When using CONFIG_KMALLOC_PARTITION_RANDOM, _RET_IP_ was previously used > > to identify the allocation site. _RET_IP_, however, evaluates to the > > caller's parent's instruction pointer rather than the actual allocation > > site; this would lead to collisions where a function performs multiple > > allocations. > > > > With the generalization to kmalloc_token_t, we now generate the token at > > the outermost macro, and using _THIS_IP_ would fix this for all cases. > > > > Unfortunately, the generic implementation of _THIS_IP_ relies on taking > > the address of a local label, which is considered broken by both GCC [1] > > and Clang [2] because label addresses are only expected to be used with > > computed gotos. While the generic version more or less works today, it > > is known to be brittle. For example, Clang -O2 always returns 1 when > > this function is inlined: > > > > static inline unsigned long get_ip(void) > > { return ({ __label__ __here; __here: (unsigned long)&&__here; }); } > > > > To provide a reliable unique identifier without breaking architectures > > relying on the generic _THIS_IP_, introduce _CODE_LOCATION_: it resolves > > to _THIS_IP_ where architectures provide a safe implementation, and > > falls back to a zero-cost static marker where _THIS_IP_ is broken. > > Doesn't that mean that all the other uses of _THIS_IP_ (which seem to mostly > be tracking lock requests) are basically broken on everything except x86-64.
It seems to mostly work, but yeah, it's probably broken in some places. > Would it be better to actually fit that? > It isn't as though it is hard asm, you just need to look at how gcc generates > PIC references to static data. Yeah, I have patches waiting to be sent - I sent one for arm64: https://lore.kernel.org/all/[email protected]/ The rest of my patches are to-be-sent, when I get around to testing - which I didn't yet for most of them since setting up test environments for all of them is a PITA. Though I can send and let arch maintainers review them - this would be the tentative list: https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git/log/?h=alloc-token
