linux-kernel - help? usage of indirect per-cpu variables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 27 Sep 2016 13:41:30 -0600
From:   Chris Friesen <chris.friesen@...driver.com>
To:     lkml <linux-kernel@...r.kernel.org>
Subject: help?  usage of indirect per-cpu variables

Hi,

I'm trying to wrap my head around indirect percpu variables, and I'm hoping 
someone can school me on how they work.

For example, in mm/slub.c we have "struct kmem_cache *s".  s->cpu_slab is a 
per-cpu variable, so we access it with something like:

	c = raw_cpu_ptr(s->cpu_slab);

and then a bit later on we do

	object = c->freelist;

So far so good.  Essentially the raw_cpu_ptr() macro applies a unique per-CPU 
offset to s->cpu_slab to generate "c" which is a real pointer so we can 
dereference it to get c->freelist.

What confuses me is how we can do something like this:

	this_cpu_cmpxchg_double(s->cpu_slab->freelist,
				s->cpu_slab->tid,
				object, tid,
				next_object, next_tid(tid))

If s->cpu_slab is a special pointer that needs to be accessed only via the 
per-CPU macros, then how is it valid to specify "s->cpu_slab->freelist"?  Since 
s->cpuslab isn't actually a valid address, how can we dereference it?

Thanks,
Chris