net: xfrm: use this_cpu_ptr per-cpu helper
Subsystems (3)
PATCH 3/9 net: xfrm: use this_cpu_ptr per-cpu helper
From: Shan Wei <[email protected]>
--- net/xfrm/xfrm_ipcomp.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
net/xfrm/xfrm_ipcomp.c +3 -4
@@ -276,14 +276,13 @@ static struct crypto_comp * __percpu *ipcomp_alloc_tfms(const char *alg_name)struct crypto_comp *__percpu *tfms;int cpu; -/* This can be any valid CPU ID so we don't need locking. */ - cpu =raw_smp_processor_id (); -list_for_each_entry (pos, &ipcomp_tfms_list, list) {struct crypto_comp *tfm; tfms = pos->tfms; - tfm = *per_cpu_ptr (tfms, cpu); + +/* This can be any valid CPU ID so we don't need locking. */ + tfm = *this_cpu_ptr (tfms);if (!strcmp (crypto_comp_name (tfm), alg_name)) { pos->users++;
Signature · 1 line
1.7.1
net/xfrm/xfrm_ipcomp.c static struct crypto_comp * __percpu *ipcomp_alloc_tfms(const char *alg_name) · line 285
Quoted 9 lines · Shan Wei
net/xfrm/xfrm_ipcomp.c +3
-2-list_for_each_entry (pos, &ipcomp_tfms_list, list) {struct crypto_comp *tfm; tfms = pos->tfms; - tfm = *per_cpu_ptr (tfms, cpu); + +/* This can be any valid CPU ID so we don't need locking. */ + tfm = *this_cpu_ptr (tfms);
It would be better to use
this_cpu_read(tfms)
since that would also make it atomic vs interrupts. The above code (both original and modified) could determine a pointer to a per cpu structure and then take an interrupt which would move the task. On return we would be accessing the per cpu variable of another processor.
Quoted 14 lines · Christoph Lameter
net/xfrm/xfrm_ipcomp.c static struct crypto_comp * __percpu *ipcomp_alloc_tfms(const char *alg_name) · line 285
Quoted 9 lines · Shan Wei
net/xfrm/xfrm_ipcomp.c +3
-2-list_for_each_entry (pos, &ipcomp_tfms_list, list) {struct crypto_comp *tfm; tfms = pos->tfms; - tfm = *per_cpu_ptr (tfms, cpu); + +/* This can be any valid CPU ID so we don't need locking. */ + tfm = *this_cpu_ptr (tfms);It would be better to use
Quoted 6 lines
this_cpu_read(tfms)since that would also make it atomic vs interrupts. The above code (both original and modified) could determine a pointer to a per cpu structure and then take an interrupt which would move the task. On return we would be accessing the per cpu variable of another processor.
Please refer to the comment in the patch above.
But I think the patch is wrong anyway because it would introduce a warning, no?
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu said, at 2012/11/1 11:41:
Quoted 4 lines
Please refer to the comment in the patch above.
But I think the patch is wrong anyway because it would introduce a warning, no?
yes, __this_cpu_ptr(or __this_cpu_read) is more reasonable which don't check preemption context.
Quoted 3 lines
Thanks,
Christoph Lameter said, at 2012/11/1 1:35:
Quoted 8 lines
It would be better to use
this_cpu_read(tfms)since that would also make it atomic vs interrupts. The above code (both original and modified) could determine a pointer to a per cpu structure and then take an interrupt which would move the task. On return we would be accessing the per cpu variable of another processor.
this_cpu_read
|-----_this_cpu_generic_read
#define _this_cpu_generic_read(pcp) \
({ typeof(pcp) ret__; \
preempt_disable(); \
ret__ = *this_cpu_ptr(&(pcp)); \
preempt_enable(); \
ret__; \})
this_cpu_read operations locate per-cpu variable with preemption safe， not disable interrupts. why is it atomic vs interrupts?
I have no idea whether we need to disable preemption for this code? At least, xfrm code run well with per_cpu_ptr which don't disable preemption.
Steffen Klassert
maintainerQuoted 19 lines · Shan Wei
Christoph Lameter said, at 2012/11/1 1:35:
Quoted 8 lines
It would be better to use
this_cpu_read(tfms)since that would also make it atomic vs interrupts. The above code (both original and modified) could determine a pointer to a per cpu structure and then take an interrupt which would move the task. On return we would be accessing the per cpu variable of another processor.
this_cpu_read
|-----_this_cpu_generic_read#define _this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = *this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \
Quoted 8 lines
})
this_cpu_readoperations locate per-cpu variable with preemption safe， not disable interrupts. why is it atomic vs interrupts?I have no idea whether we need to disable preemption for this code? At least, xfrm code run well with
per_cpu_ptrwhich don't disable preemption.
We compare the name of the newly allocated crypto transform against the existing ones. The name is the same on every percpu transform and it does not change after the transform is allocated. So we don't care if we get migrated or not, we can just take the transform from an arbitrary cpu to read the name from it.
Quoted 9 lines
this_cpu_read
|-----_this_cpu_generic_read#define _this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = *this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \
Quoted 5 lines
})
this_cpu_readoperations locate per-cpu variable with preemption safe， not disable interrupts. why is it atomic vs interrupts?
Hmmm... what effect do those preemt_dis/enable() actually have? Since a pre-empt can happen either side of them, the value the caller sees can be for the wrong cpu anyway.
The only time I could see them being necessary is if *this_cpu_ptr() itself needs mutex protection in order to function correctly - and that is likely to be port specific. On i386/amd64 where (I guess) it is an access offset by fs/gs this isn't necessary and just wastes cpu cycles.
If the caller cares which cpu the value comes from (eg to increment a counter) then the caller would need to disable pre-emption across the whole operation.
David