* Dmitry Vyukov: > On Tue, 26 Sept 2023 at 21:51, Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Dmitry Vyukov: >> >> > In reality it's a bit more involved since the field is actually 8 >> > bytes and only partially overlaps with rseq.cpu_id_start (it's an >> > 8-byte pointer with high 4 bytes overlap rseq.cpu_id_start): >> > >> > https://github.com/google/tcmalloc/blob/229908285e216cca8b844c1781bf16b838128d1b/tcmalloc/internal/percpu.h#L101-L165 >> >> This does not compose with other rseq users, as noted in the sources: >> >> // Note: this makes __rseq_abi.cpu_id_start unusable for its original purpose. >> >> For a core library such a malloc replacement, that is a very bad trap. > > I agree. I wouldn't do this if there were other options. That's why I > am looking for official kernel support for this. > If we would have a separate 8 bytes that are overwritten with 0 when a > thread is descheduled, that would be perfect. That only solves part of the problem because these fields would still have to be locked to tcmalloc. I think you'd need a rescheduling counter, then every library could keep their reference values in library-private thread-local storage. Thanks, Florian
