On Tue, 2007-03-13 at 16:57 +0100, Andi Kleen wrote:
> On Tue, Mar 13, 2007 at 05:23:52PM +1100, Rusty Russell wrote:
> > In particular, it's been put in GCC 4.1 for
> > CONFIG_CC_STACKPROTECTOR, which assumes %gs:40 will give the stack
> > canary.
>
> Yes that was always ugly, but I don't know a
On Tue, 2007-03-13 at 08:31 -0700, Jeremy Fitzhardinge wrote:
> Paul Mackerras wrote:
> > There is a fundamental problem with using __thread, which is that gcc
> > assumes that the addresses of __thread variables are constant within
> > one thread, and that therefore it can cache the result of
Jeremy Fitzhardinge writes:
> Or do you mean that if you have:
>
> preempt_disable();
> use_my_percpu++;
> preempt_enable();
> // switch cpus
> preempt_disable();
> use_my_percpu++;
> preempt_enable();
>
> then it will still use the old pointer to
On Tue, Mar 13, 2007 at 05:23:52PM +1100, Rusty Russell wrote:
> On Tue, 2007-03-13 at 08:59 +1100, Rusty Russell wrote:
> > On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
> > > > Rusty's pda->per_cpu patch will deal with this once and for all; have
> > >
> > > Not on x86-64.
> >
> >
Paul Mackerras wrote:
> There is a fundamental problem with using __thread, which is that gcc
> assumes that the addresses of __thread variables are constant within
> one thread, and that therefore it can cache the result of address
> calculations. However, with preempt, threads in the kernel
Rusty Russell writes:
> The ideal solution has always been to use __thread, but no architecture
> has yet managed it (I tried for i386, and it quickly caused unbearable
> pain). On x86-64 that uses "%fs" on x86-64, not "%gs" as the kernel
> does, but I might try that if I feel particularly
Rusty Russell writes:
The ideal solution has always been to use __thread, but no architecture
has yet managed it (I tried for i386, and it quickly caused unbearable
pain). On x86-64 that uses %fs on x86-64, not %gs as the kernel
does, but I might try that if I feel particularly masochistic
Paul Mackerras wrote:
There is a fundamental problem with using __thread, which is that gcc
assumes that the addresses of __thread variables are constant within
one thread, and that therefore it can cache the result of address
calculations. However, with preempt, threads in the kernel can't
On Tue, Mar 13, 2007 at 05:23:52PM +1100, Rusty Russell wrote:
On Tue, 2007-03-13 at 08:59 +1100, Rusty Russell wrote:
On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
Rusty's pda-per_cpu patch will deal with this once and for all; have
Not on x86-64.
Indeed. Perhaps it's
Jeremy Fitzhardinge writes:
Or do you mean that if you have:
preempt_disable();
use_my_percpu++;
preempt_enable();
// switch cpus
preempt_disable();
use_my_percpu++;
preempt_enable();
then it will still use the old pointer to use_my_percpu?
On Tue, 2007-03-13 at 08:31 -0700, Jeremy Fitzhardinge wrote:
Paul Mackerras wrote:
There is a fundamental problem with using __thread, which is that gcc
assumes that the addresses of __thread variables are constant within
one thread, and that therefore it can cache the result of address
On Tue, 2007-03-13 at 16:57 +0100, Andi Kleen wrote:
On Tue, Mar 13, 2007 at 05:23:52PM +1100, Rusty Russell wrote:
In particular, it's been put in GCC 4.1 for
CONFIG_CC_STACKPROTECTOR, which assumes %gs:40 will give the stack
canary.
Yes that was always ugly, but I don't know a better
On Tue, 2007-03-13 at 08:59 +1100, Rusty Russell wrote:
> On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
> > > Rusty's pda->per_cpu patch will deal with this once and for all; have
> >
> > Not on x86-64.
>
> Indeed. Perhaps it's time I join the modern world and compile a 64-bit
>
On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
> > Rusty's pda->per_cpu patch will deal with this once and for all; have
>
> Not on x86-64.
Indeed. Perhaps it's time I join the modern world and compile a 64-bit
kernel...
Will prepare patches,
Rusty.
-
To unsubscribe from this list:
Dnia 12-03-2007, pon o godzinie 02:19 +0100, Andi Kleen napisał(a):
> Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
> fixed the in kernel build.
>
> Does it work with this patch?
Yes! Thank you.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^
On Mon, Mar 12, 2007 at 07:45:25AM -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> >> Rusty's pda->per_cpu patch will deal with this once and for all; have
> >>
> >
> > Not on x86-64.
> >
>
> Have you considered dropping pda in x86-64? Segment based percpu
> doesn't really have
Andi Kleen wrote:
>> Rusty's pda->per_cpu patch will deal with this once and for all; have
>>
>
> Not on x86-64.
>
Have you considered dropping pda in x86-64? Segment based percpu
doesn't really have any disadvantages.
>> you picked it up yet?
>>
>
> Not yet.
>
There will be
On Sun, Mar 11, 2007 at 05:25:46PM -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
> > fixed the in kernel build.
> >
> > Does it work with this patch?
> >
> > -Andi
> >
> > Export _proxy_pda for gcc 4.2
> >
>
> Gak.
On Sun, Mar 11, 2007 at 05:25:46PM -0700, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
fixed the in kernel build.
Does it work with this patch?
-Andi
Export _proxy_pda for gcc 4.2
Gak. It seemed like such a
Andi Kleen wrote:
Rusty's pda-per_cpu patch will deal with this once and for all; have
Not on x86-64.
Have you considered dropping pda in x86-64? Segment based percpu
doesn't really have any disadvantages.
you picked it up yet?
Not yet.
There will be interactions with
On Mon, Mar 12, 2007 at 07:45:25AM -0700, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Rusty's pda-per_cpu patch will deal with this once and for all; have
Not on x86-64.
Have you considered dropping pda in x86-64? Segment based percpu
doesn't really have any disadvantages.
Dnia 12-03-2007, pon o godzinie 02:19 +0100, Andi Kleen napisał(a):
Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
fixed the in kernel build.
Does it work with this patch?
Yes! Thank you.
--
__( Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^
On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
Rusty's pda-per_cpu patch will deal with this once and for all; have
Not on x86-64.
Indeed. Perhaps it's time I join the modern world and compile a 64-bit
kernel...
Will prepare patches,
Rusty.
-
To unsubscribe from this list: send the
On Tue, 2007-03-13 at 08:59 +1100, Rusty Russell wrote:
On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
Rusty's pda-per_cpu patch will deal with this once and for all; have
Not on x86-64.
Indeed. Perhaps it's time I join the modern world and compile a 64-bit
kernel...
Will
Andi Kleen wrote:
> Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
> fixed the in kernel build.
>
> Does it work with this patch?
>
> -Andi
>
> Export _proxy_pda for gcc 4.2
>
Gak. It seemed like such a good idea at the time.
Rusty's pda->per_cpu patch will deal with this
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:
>
> I've heard that it now builds with gcc-4.2.0 snapshots. This is strange:
> if the problem has been fixed for gcc-4.2.0, why doesn't it work for
> gcc-4.1.2? arch/i386/kernel/vmlinux.lds.S does contain _proxy_pda = 0;
Hmm, it probably
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes:
I've heard that it now builds with gcc-4.2.0 snapshots. This is strange:
if the problem has been fixed for gcc-4.2.0, why doesn't it work for
gcc-4.1.2? arch/i386/kernel/vmlinux.lds.S does contain _proxy_pda = 0;
Hmm, it probably needs a
Andi Kleen wrote:
Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
fixed the in kernel build.
Does it work with this patch?
-Andi
Export _proxy_pda for gcc 4.2
Gak. It seemed like such a good idea at the time.
Rusty's pda-per_cpu patch will deal with this once and
On Thu, Mar 08, 2007 at 01:57:59AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> This is linux-2.6.20.1 with lots of patches from PLD Linux (I believe
> the patches don't affect the issue), compiled with gcc-4.1.2 and
> binutils-2.17.50.0.12 on x86.
>...
Please test a plain 2.6.20 from
On Thu, Mar 08, 2007 at 01:57:59AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
This is linux-2.6.20.1 with lots of patches from PLD Linux (I believe
the patches don't affect the issue), compiled with gcc-4.1.2 and
binutils-2.17.50.0.12 on x86.
...
Please test a plain 2.6.20 from ftp.kernel.org.
If
30 matches
Mail list logo
