On Fri, Apr 09, 2021 at 02:32:56PM +0100, Mel Gorman wrote: > That said, there are some curious users already. > fs/squashfs/decompressor_multi_percpu.c looks like it always uses the > local_lock in CPU 0's per-cpu structure instead of stabilising a per-cpu > pointer. I'm not sure how you read that. You're talking about this: local_lock(&msblk->stream->lock); right? Note that msblk->stream is a per-cpu pointer, so &msblk->stream->lock is that same per-cpu pointer with an offset on. The whole think relies on: &per_cpu_ptr(msblk->stream, cpu)->lock == per_cpu_ptr(&msblk->stream->lock, cpu) Which is true because the lhs: (local_lock_t *)((msblk->stream + per_cpu_offset(cpu)) + offsetof(struct squashfs_stream, lock)) and the rhs: (local_lock_t *)((msblk->stream + offsetof(struct squashfs_stream, lock)) + per_cpu_offset(cpu)) are identical, because addition is associative. > drivers/block/zram/zcomp.c appears to do the same although for > at least one of the zcomp_stream_get() callers, the CPU is pinned for > other reasons (bit spin lock held). I think it happens to work anyway > but it's weird and I'm not a fan. Same thing.
