linux-kernel - Re: [PATCH 3/9] net: xfrm: use this_cpu

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121101091842.GA2719@secunet.com>
Date:	Thu, 1 Nov 2012 10:18:42 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Shan Wei <shanwei88@...il.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	David Miller <davem@...emloft.net>,
	NetDev <netdev@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Kernel-Maillist <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/9] net: xfrm: use this_cpu_ptr per-cpu helper

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 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.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/