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: <4AD6E29B.8000506@kernel.org>
Date:	Thu, 15 Oct 2009 17:51:39 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	"Luck, Tony" <tony.luck@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
	"mingo@...hat.com" <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"cebbert@...hat.com" <cebbert@...hat.com>
Subject: Re: [PATCH 13/16] percpu: remove per_cpu__ prefix.

Hello, Christoph, Tony.

Christoph Lameter wrote:
> On Wed, 14 Oct 2009, Luck, Tony wrote:
> 
>>> we would still have to use per cpu operations to get to the contents of
>>> these variables.
>> That's good.
>>
>>> Hope that addresses your concerns.
>> But then I don't understand the original patch that was going to do:
>>
>>> -#define __ia64_per_cpu_var(var)	per_cpu__##var
>>> +#define __ia64_per_cpu_var(var)	var
>> Presumably all actual use of __ia64_per_cpu_var is being replaced
>> by some other "per cpu operations"?

Yeah, I wasn't so sure what to do about these, so just left them as
no-op for the moment.

> Hmmm... Right. IA64 is a special case because the access of the per cpu
> variable at a specific address causes per cpu TLBs to do the relocation.
> 
> Other platforms have to add a per cpu specific offset to a variable to get
> the right per cpu variable.
> 
> As a result IA64 strictly does not need this_cpu_read() and
> this_cpu_write(). However, not using the operations is going to cause
> the sparse annotation by Tejun to trigger errors. this_cpu_read() is
> likely a noop for IA64 that just changes the annotations so that sparse
> warnings do not trigger. Tejun?

__ia64_per_cpu_var() is slightly different from this_cpu_read() in
that the former only works for percpu variables which fall on the
first percpu page - ie. static percpu vars in the kernel image.  So,
__ia64_per_cpu_var() is a bit more efficient than this_cpu_read() as
it doesn't have to compute the address.

So, what we can do is to leave the macro alone for now and then add
sparse annotation to it later in the patch as it's basically another
specialized accessor.  How does that sound?

Thanks.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ