On Thursday 29 November 2007 10:36:06 Christoph Lameter wrote:
> 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.
It is a little weird, but it gave flexibility
On Thursday 29 November 2007 10:36:06 Christoph Lameter wrote:
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.
It is a little weird, but it gave flexibility for
Second portion. Add a new seg_offset macro to calculate the offset. This
can be avoided if the linker relocates the per cpu area to zero. Includes
a patch to read trickle count via both methods to verify that it actually
works. Both patches on top of the per cpu cleanup patches that I sent
Here is the first of two patches for x86_64 that move the pda into the per
cpu area and then make the x86 percpu macros work for x86_64. This needs
to be generalized for other arches. The __per_cpu_start offsets can be
taken care of by the linker. We can also tell the linker to completely
Christoph Lameter wrote:
> x86_64 can use a 32 bit offset instead of a 64 bit addres because it uses
> the small model. A load of a 64 bit address would require much more
> expensive instructions. A load of a 64 bit address is currently avoided
> through the use of the pda that contains the
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> > percpu references are quite frequent already (vm statistics) and will be
> > more frequent after we have converted the per cpu arrays to per cpu
> > allocations.
> >
>
> Well, I think the point is moot, because x86 will always use 32-bit
>
Christoph Lameter wrote:
> The percpu areas need to be allocated in a NUMA aware fashion. Otherwise
> you use distant memory for the most performance sensitive areas. The NUMA
> subsystem must be so far up that these allocations can be performed in the
> right way. And this means at least you
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> Don't think it matters either way. Before percpu is allocated, NUMA
> issues don't matter. Once they are - by whatever mechanism - you can
> set the segment bases up appropriately. The fact that you chose to put
> percpu data at address X
Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
>
>
>> I don't see the problem. The way i386 does it inherently supports
>> per-cpu data very early on (it uses the prototype percpu section until
>> the real percpu values are set up).
>>
>
> Ok so we could do
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> I don't see the problem. The way i386 does it inherently supports
> per-cpu data very early on (it uses the prototype percpu section until
> the real percpu values are set up).
Ok so we could do that for x86_64 as well? There is more complicated
> * drop support for stack-protector (does it really help? do people
> use it?)
AFAIK we only ever had a single classical stack buffer overflow in the kernel.
It certainly doesn't seem to be a common security problem it is solving.
-Andi
-
To unsubscribe from this list: send the line
Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
>
> > Yes, I would like to convert x86_64 to match i386's percpu, and drop the
>
>> pda altogether. The only thing preventing this is the stack canary, and
>> I'm wondering how much value there is in keeping it, given
On Thu, 29 Nov 2007, Andi Kleen wrote:
> On Wed, Nov 28, 2007 at 04:11:37PM -0800, Christoph Lameter wrote:
> > 1. The stack canary
>
> You would need to change gcc with a new option and only allow the stack
> checking when the compiler supports the new option. However the problem
> is still how
On Wed, Nov 28, 2007 at 04:11:37PM -0800, Christoph Lameter wrote:
> 1. The stack canary
You would need to change gcc with a new option and only allow the stack
checking when the compiler supports the new option. However the problem
is still how to get a reasonable fixed offset. Or perhaps just
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> Yes, I would like to convert x86_64 to match i386's percpu, and drop the
> pda altogether. The only thing preventing this is the stack canary, and
> I'm wondering how much value there is in keeping it, given the
> disadvantages of having this
Rusty Russell wrote:
> On Thursday 29 November 2007 05:51:29 Christoph Lameter wrote:
>
>> On Wed, 28 Nov 2007, Rusty Russell wrote:
>>
>>> On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
>>>
On Tue, 27 Nov 2007, Rusty Russell wrote:
> Have you
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,
On Thursday 29 November 2007 05:51:29 Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Rusty Russell wrote:
> > On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
> > > On Tue, 27 Nov 2007, Rusty Russell wrote:
> > > > Have you considered moving x86-64's setup_per_cpu_areas into
On Wed, 28 Nov 2007, Rusty Russell wrote:
> On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
> > On Tue, 27 Nov 2007, Rusty Russell wrote:
> > > Have you considered moving x86-64's setup_per_cpu_areas into generic
> > > code? It's a bit messier because some archs might not have set
On Wed, 28 Nov 2007, Rusty Russell wrote:
On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
On Tue, 27 Nov 2007, Rusty Russell wrote:
Have you considered moving x86-64's setup_per_cpu_areas into generic
code? It's a bit messier because some archs might not have set up NUMA
On Thursday 29 November 2007 05:51:29 Christoph Lameter wrote:
On Wed, 28 Nov 2007, Rusty Russell wrote:
On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
On Tue, 27 Nov 2007, Rusty Russell wrote:
Have you considered moving x86-64's setup_per_cpu_areas into generic
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
Rusty Russell wrote:
On Thursday 29 November 2007 05:51:29 Christoph Lameter wrote:
On Wed, 28 Nov 2007, Rusty Russell wrote:
On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
On Tue, 27 Nov 2007, Rusty Russell wrote:
Have you considered moving
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
Yes, I would like to convert x86_64 to match i386's percpu, and drop the
pda altogether. The only thing preventing this is the stack canary, and
I'm wondering how much value there is in keeping it, given the
disadvantages of having this
On Thu, 29 Nov 2007, Andi Kleen wrote:
On Wed, Nov 28, 2007 at 04:11:37PM -0800, Christoph Lameter wrote:
1. The stack canary
You would need to change gcc with a new option and only allow the stack
checking when the compiler supports the new option. However the problem
is still how to get
Christoph Lameter wrote:
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
Yes, I would like to convert x86_64 to match i386's percpu, and drop the
pda altogether. The only thing preventing this is the stack canary, and
I'm wondering how much value there is in keeping it, given the
On Wed, Nov 28, 2007 at 04:11:37PM -0800, Christoph Lameter wrote:
1. The stack canary
You would need to change gcc with a new option and only allow the stack
checking when the compiler supports the new option. However the problem
is still how to get a reasonable fixed offset. Or perhaps just
* drop support for stack-protector (does it really help? do people
use it?)
AFAIK we only ever had a single classical stack buffer overflow in the kernel.
It certainly doesn't seem to be a common security problem it is solving.
-Andi
-
To unsubscribe from this list: send the line
Christoph Lameter wrote:
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
I don't see the problem. The way i386 does it inherently supports
per-cpu data very early on (it uses the prototype percpu section until
the real percpu values are set up).
Ok so we could do that for x86_64
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
Don't think it matters either way. Before percpu is allocated, NUMA
issues don't matter. Once they are - by whatever mechanism - you can
set the segment bases up appropriately. The fact that you chose to put
percpu data at address X doesn't
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
I don't see the problem. The way i386 does it inherently supports
per-cpu data very early on (it uses the prototype percpu section until
the real percpu values are set up).
Ok so we could do that for x86_64 as well? There is more complicated
Christoph Lameter wrote:
The percpu areas need to be allocated in a NUMA aware fashion. Otherwise
you use distant memory for the most performance sensitive areas. The NUMA
subsystem must be so far up that these allocations can be performed in the
right way. And this means at least you need
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
percpu references are quite frequent already (vm statistics) and will be
more frequent after we have converted the per cpu arrays to per cpu
allocations.
Well, I think the point is moot, because x86 will always use 32-bit
offsets.
Christoph Lameter wrote:
x86_64 can use a 32 bit offset instead of a 64 bit addres because it uses
the small model. A load of a 64 bit address would require much more
expensive instructions. A load of a 64 bit address is currently avoided
through the use of the pda that contains the full 64
Second portion. Add a new seg_offset macro to calculate the offset. This
can be avoided if the linker relocates the per cpu area to zero. Includes
a patch to read trickle count via both methods to verify that it actually
works. Both patches on top of the per cpu cleanup patches that I sent
Here is the first of two patches for x86_64 that move the pda into the per
cpu area and then make the x86 percpu macros work for x86_64. This needs
to be generalized for other arches. The __per_cpu_start offsets can be
taken care of by the linker. We can also tell the linker to completely
On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
> On Tue, 27 Nov 2007, Rusty Russell wrote:
> > Have you considered moving x86-64's setup_per_cpu_areas into generic
> > code? It's a bit messier because some archs might not have set up NUMA
> > stuff yet, but it's logically
Christoph Lameter wrote:
On Tue, 27 Nov 2007, Randy Dunlap wrote:
+config ARCH_SETS_UP_PER_CPU_AREA
+ bool
+ default y
def_bool y
is the preferred form for those 2-liners above...
+
config ARCH_NO_VIRT_TO_BUS
def_bool y
Ok. Changed.
x86 should use
On Tue, 27 Nov 2007, Randy Dunlap wrote:
> > +config ARCH_SETS_UP_PER_CPU_AREA
> > + bool
> > + default y
>
> def_bool y
> is the preferred form for those 2-liners above...
>
>
> > +
> > config ARCH_NO_VIRT_TO_BUS
> > def_bool y
> >
Ok. Changed.
x86 should use
config
On Mon, 26 Nov 2007 16:14:12 -0800 Christoph Lameter wrote:
> The use of the __GENERIC_PERCPU is a bit problematic since arches
> may want to run their own percpu setup while using the generic
> percpu definitions. Replace it through a kconfig variable.
>
> Cc: Rusty Russell <[EMAIL PROTECTED]>
On Tue, 27 Nov 2007, Rusty Russell wrote:
> Have you considered moving x86-64's setup_per_cpu_areas into generic code?
> It's a bit messier because some archs might not have set up NUMA stuff yet,
> but it's logically generic...
Yes that will happen later. This is just the early cleanup work.
On Tue, 27 Nov 2007, Rusty Russell wrote:
Have you considered moving x86-64's setup_per_cpu_areas into generic code?
It's a bit messier because some archs might not have set up NUMA stuff yet,
but it's logically generic...
Yes that will happen later. This is just the early cleanup work. I
On Mon, 26 Nov 2007 16:14:12 -0800 Christoph Lameter wrote:
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Cc: Rusty Russell [EMAIL PROTECTED]
Cc:
On Tue, 27 Nov 2007, Randy Dunlap wrote:
+config ARCH_SETS_UP_PER_CPU_AREA
+ bool
+ default y
def_bool y
is the preferred form for those 2-liners above...
+
config ARCH_NO_VIRT_TO_BUS
def_bool y
Ok. Changed.
x86 should use
config
Christoph Lameter wrote:
On Tue, 27 Nov 2007, Randy Dunlap wrote:
+config ARCH_SETS_UP_PER_CPU_AREA
+ bool
+ default y
def_bool y
is the preferred form for those 2-liners above...
+
config ARCH_NO_VIRT_TO_BUS
def_bool y
Ok. Changed.
x86 should use
On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
On Tue, 27 Nov 2007, Rusty Russell wrote:
Have you considered moving x86-64's setup_per_cpu_areas into generic
code? It's a bit messier because some archs might not have set up NUMA
stuff yet, but it's logically generic...
On Tuesday 27 November 2007 11:14:12 Christoph Lameter wrote:
> The use of the __GENERIC_PERCPU is a bit problematic since arches
> may want to run their own percpu setup while using the generic
> percpu definitions. Replace it through a kconfig variable.
Thanks for this Christoph!
These patches
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter [EMAIL
On Tuesday 27 November 2007 11:14:12 Christoph Lameter wrote:
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Thanks for this Christoph!
These patches
50 matches
Mail list logo
