From: Gerald Schaefer
Date: Thu, 16 Jan 2014 16:54:48 +0100
> commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu
> handling for rds. chpfirst is the result of __this_cpu_read(), so it is
> an absolute pointer and not __percpu. Therefore, __this_cpu_write()
> should not
From: Gerald Schaefer gerald.schae...@de.ibm.com
Date: Thu, 16 Jan 2014 16:54:48 +0100
commit ae4b46e9d net: rds: use this_cpu_* per-cpu helper broke per-cpu
handling for rds. chpfirst is the result of __this_cpu_read(), so it is
an absolute pointer and not __percpu. Therefore,
commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu
handling for rds. chpfirst is the result of __this_cpu_read(), so it is
an absolute pointer and not __percpu. Therefore, __this_cpu_write()
should not operate on chpfirst, but rather on cache->percpu->first, just
like
commit ae4b46e9d net: rds: use this_cpu_* per-cpu helper broke per-cpu
handling for rds. chpfirst is the result of __this_cpu_read(), so it is
an absolute pointer and not __percpu. Therefore, __this_cpu_write()
should not operate on chpfirst, but rather on cache-percpu-first, just
like
4 matches
Mail list logo