linux-kernel - Re: [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup

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, 28 Nov 2007 15:36:06 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Rusty Russell <rusty@...tcorp.com.au>
cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...e.de>, Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [patch 05/14] percpu: Use a Kconfig variable to configure arch
 specific percpu setup

On Thu, 29 Nov 2007, Rusty Russell wrote:

> But the PDA itself is silly (Jeremy ported it to i386 and I balked).  We have 
> a generic one: it's called the per-cpu data.  Having a completely separate 
> per-cpu structure for x86-64 is a mistake.

Yes ultimately the pda can be dissolved. However, the stack canary 
probably has to be kept for backward compatibility.

> Setting up gs as the per-cpu offset has lovely properties and avoids YA 
> arch-specific concept; see the i386 code.  Introducing a generic 
> read_percpu()/write_percpu() would even make it optimal.

The code becomes much simpler if gs would point to the beginning of the 
per cpu area and if the __per_cpu_offset[i] would do the same. No weird 
__per_cpu_start offsetting anymore.

The offsets are smaller if they are relative to the per cpu areas which 
will make more compact instructions possible.

The generic write/readpercpu functionality introduced by the cpu_alloc 
patchset works best with offsets relative to an arch dependent 
register. All per cpu data (pda, percpu and allocpercpu) is handles as an 
offset relative to the start of the per cpu data.

If the current offset by __per_cpu_start is kept then a per cpu allocator 
may have to dish out addresses that go beyond __per_cpu_end.

I think dealing with a per cpu variable as if it would be an offset 
relative to a base is natural for the typical addressing of cpus based on 
an offset relative to some register.

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