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: <20130823200514.GA11391@mtj.dyndns.org>
Date:	Fri, 23 Aug 2013 16:05:14 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	akpm@...uxfoundation.org, linux-arch@...r.kernel.org,
	Steven Rostedt <srostedt@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [guv 00/16] [RFC] percpu: Replace __get_cpu_var uses throughout
 the kernel

Hello, Christoph.

On Fri, Aug 23, 2013 at 07:01:56PM +0000, Christoph Lameter wrote:
> This patch converts __get_cpu_var into either and explicit address
> calculation using this_cpu_ptr() or into a use of this_cpu
> operations that use the offset. Thereby address calcualtions are
> avoided and less registers are used when code is generated.

Yeah, we should have done this long ago.  Eventually, I think we'd be
better off dropping all _var() accessors.  They were okay when we had
segration between static and dynamic ones but are now just adding to
confusion.

On a cursory scan,

* Each patch probably needs a brief explanation of why this is
  happening, especially if these patches are gonna be routed
  separately.

* It would be a lot easier to route the patches if each had cc's to
  the maintainers of the affected subsystems.

* Dunno what's the convention around conccinelle scripts but do we
  need to keep them around if the accessor being converted gets
  removed at the end of the series?

How do you want to route the patches?  I'm gonna apply the second
patch which updates __verify_pcpu_ptr() to the percpu tree right away
and push it to Linus early during the merge window so that pushing
other patches through different trees from there on isn't too painful.

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