linux-kernel - Re: [PATCH] Code clean up for percpu

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]

Date:	Wed, 19 Oct 2011 11:26:42 +0200
From:	Avi Kivity <avi@...hat.com>
To:	"Alex,Shi" <alex.shi@...el.com>
CC:	Christoph Lameter <cl@...two.org>, "tj@...nel.org" <tj@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	"Huang, Ying" <ying.huang@...el.com>, tglx@...utronix.de,
	mingo@...hat.com,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	davem@...emloft.net, kaber@...sh.net, a.p.zijlstra@...llo.nl,
	kvm@...r.kernel.org, jeremy@...source.com
Subject: Re: [PATCH] Code clean up for percpu_xxx() functions

On 10/19/2011 11:23 AM, Alex,Shi wrote:
> > Well do the obvious (where you can see that interrupts or preemption are
> > disabled in the function or in a calling function). Leave the rest as is
> > and provide separate patches for them?
>
> Thanks for comments! I initialized the patch as following accordingly,
> And cc to more maintainers for review. I checked all code except xen/kvm
> part, totally a idiot for them. 
>
>
>
> ==========
>
> Since percpu_xxx() serial functions are duplicate with this_cpu_xxx().
> Removing percpu_xxx() definition and replacing them by this_cpu_xxx() in
> code.
>
> And further more, as Christoph Lameter's requirement, I try to use
> __this_cpu_xx to replace this_cpu_xxx if it is in preempt safe scenario.
> The preempt safe scenarios include:
> 1, in irq/softirq/nmi handler
> 2, protected by preempt_disable
> 3, protected by spin_lock
> 4, if the code context imply that it is preempt safe, like the code is
> follows or be followed a preempt safe code.
>
> I left the xen/kvm part code unchanged, since no any idea of them.
>
>

All of the kvm usage is in preemption disabled contexts.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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