linux-kernel - Re: [this_cpu_xx V6 3/7] Use this

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: <alpine.DEB.1.10.0910161232420.6120@gentwo.org>
Date:	Fri, 16 Oct 2009 12:44:06 -0400 (EDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
cc:	linux-kernel@...r.kernel.org,
	Pekka Enberg <penberg@...helsinki.fi>,
	Mel Gorman <mel@....ul.ie>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Subject: Re: [this_cpu_xx V6 3/7] Use this_cpu operations in slub

On Thu, 15 Oct 2009, Tejun Heo wrote:

> > Are you defining what __ means for this_cpu_ptr?
>
> I was basically stating the different between raw_smp_processor_id()
> and smp_processor_id() which I thought applied the same to
> __this_cpu_ptr() and this_cpu_ptr().

Ii does apply. __this_cpu_ptr does not use smp_processor_id() but
raw_smp_processor_id(). this_cpu_ptr does not need to disable preempt so
we dont do anything on that level.

> > The vm event counters require both no check and no preempt since they can
> > be implemented in a racy way.
>
> The biggest grief I have is that the meaning of __ is different among
> different accessors.  If that can be cleared up, we would be in much
> better shape without adding any extra macros.  Can we just remove all
> __'s and use meaningful pre or suffixes like raw or irq or whatever?

It currently means that we do not deal with preempt and do not check for
preemption. That is consistent.

Sure we could change the API to have even more macros than the large
amount it already has so that we can check for proper preempt disablement.

I guess that would mean adding

raw_nopreempt_this_cpu_xx  and nopreempt_this_cpu_xx variants? The thing
gets huge. I think we could just leave it. __ suggests that serialization
and checking is not performed like in the full versions and that is true.
--
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/