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
| ||
|
Date: Thu, 1 Nov 2012 12:15:50 -0000 From: "David Laight" <David.Laight@...LAB.COM> To: "Shan Wei" <shanwei88@...il.com>, "Christoph Lameter" <cl@...ux.com> Cc: <steffen.klassert@...unet.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 > 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? 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
Powered by blists - more mailing lists