> this_cpu_read
> |-_this_cpu_generic_read
>
> #define _this_cpu_generic_read(pcp) \
> ({ typeof(pcp) ret__; \
> preempt_disable(); \
> ret__ = *th
On Thu, Nov 01, 2012 at 04:56:54PM +0800, Shan Wei wrote:
> Christoph Lameter said, at 2012/11/1 1:35:
> > 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 pointe
Herbert Xu said, at 2012/11/1 11:41:
> 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.
>
> Thanks,
>
--
To un
Christoph Lameter said, at 2012/11/1 1:35:
> 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
On Wed, Oct 31, 2012 at 05:35:46PM +, Christoph Lameter wrote:
> On Wed, 31 Oct 2012, Shan Wei wrote:
>
> > -
> > list_for_each_entry(pos, &ipcomp_tfms_list, list) {
> > struct crypto_comp *tfm;
> >
> > tfms = pos->tfms;
> > - tfm = *per_cpu_ptr(tfms, cpu)
On Wed, 31 Oct 2012, Shan Wei wrote:
> -
> 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 lock
From: Shan Wei
Signed-off-by: Shan Wei
---
net/xfrm/xfrm_ipcomp.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c
index e5246fb..af6c78a 100644
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -276,14 +2
7 matches
Mail list logo
