* Andi Kleen ([EMAIL PROTECTED]) wrote:
>
> Hallo,
>
> I had some second thoughts about the text patching of DEBUG_RODATA kernels
> using change_page_attr(). Change_page_attr is intrusive and slow and using
> a separate mapping is a little more gentle. I came up with this patch.
> For your
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Hallo,
I had some second thoughts about the text patching of DEBUG_RODATA kernels
using change_page_attr(). Change_page_attr is intrusive and slow and using
a separate mapping is a little more gentle. I came up with this patch.
For your review and
On Fri, Jul 20, 2007 at 11:17:49AM -0400, Mathieu Desnoyers wrote:
> * Zachary Amsden ([EMAIL PROTECTED]) wrote:
> > Mathieu Desnoyers wrote:
> > >Yes, kprobes is case 1: atomic update. And we don't even have to bother
> > >about Intel's erratum. This one is ok. That's mainly the
> >
On Fri, Jul 20, 2007 at 11:17:49AM -0400, Mathieu Desnoyers wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers wrote:
Yes, kprobes is case 1: atomic update. And we don't even have to bother
about Intel's erratum. This one is ok. That's mainly the
alternatives/paravirt
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >Yes, kprobes is case 1: atomic update. And we don't even have to bother
> >about Intel's erratum. This one is ok. That's mainly the
> >alternatives/paravirt code I worry about.
> >
>
> Paravirt and alternatives should all
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Thu, Jul 19, 2007 at 07:49:12PM -0400, Mathieu Desnoyers wrote:
> > * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> > >
> > > > * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > > >
> > > > > >
On Thu, Jul 19, 2007 at 07:49:12PM -0400, Mathieu Desnoyers wrote:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> >
> > > * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > >
> > > > > Ewww you plan to run this in SMP ? So you actually go
On Friday 20 July 2007 02:37:20 Zachary Amsden wrote:
> Andi Kleen wrote:
> > + *addr = opcode;
> > + /* Not strictly needed, but can speed CPU recovery up */
> > + if (cpu_has_clflush)
> > + asm("clflush (%0) " :: "r" (addr) : "memory");
> > + if (addr != oaddr)
> > +
On Thu, Jul 19, 2007 at 06:15:46PM -0700, Zachary Amsden wrote:
> Mathieu Desnoyers wrote:
> >Yes, kprobes is case 1: atomic update. And we don't even have to bother
> >about Intel's erratum. This one is ok. That's mainly the
> >alternatives/paravirt code I worry about.
> >
>
> Paravirt and
* Andi Kleen ([EMAIL PROTECTED]) wrote:
On Thu, Jul 19, 2007 at 07:49:12PM -0400, Mathieu Desnoyers wrote:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Ewww you plan to run this in
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers wrote:
Yes, kprobes is case 1: atomic update. And we don't even have to bother
about Intel's erratum. This one is ok. That's mainly the
alternatives/paravirt code I worry about.
Paravirt and alternatives should all be ok
On Thu, Jul 19, 2007 at 06:15:46PM -0700, Zachary Amsden wrote:
Mathieu Desnoyers wrote:
Yes, kprobes is case 1: atomic update. And we don't even have to bother
about Intel's erratum. This one is ok. That's mainly the
alternatives/paravirt code I worry about.
Paravirt and alternatives
On Friday 20 July 2007 02:37:20 Zachary Amsden wrote:
Andi Kleen wrote:
+ *addr = opcode;
+ /* Not strictly needed, but can speed CPU recovery up */
+ if (cpu_has_clflush)
+ asm(clflush (%0) :: r (addr) : memory);
+ if (addr != oaddr)
+ vunmap(addr);
On Thu, Jul 19, 2007 at 07:49:12PM -0400, Mathieu Desnoyers wrote:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Ewww you plan to run this in SMP ? So you actually go byte
by byte
Mathieu Desnoyers wrote:
Yes, kprobes is case 1: atomic update. And we don't even have to bother
about Intel's erratum. This one is ok. That's mainly the
alternatives/paravirt code I worry about.
Paravirt and alternatives should all be ok because they are done before
SMP bringup and with
Andi Kleen wrote:
+ *addr = opcode;
+ /* Not strictly needed, but can speed CPU recovery up */
+ if (cpu_has_clflush)
+ asm("clflush (%0) " :: "r" (addr) : "memory");
+ if (addr != oaddr)
+ vunmap(addr);
clflush should take oaddr.
If you
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>
> > * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > >
> > > > Ewww you plan to run this in SMP ? So you actually go byte
> > > > by byte changing pieces of instructions non atomically and doing
> >
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Thursday 19 July 2007 22:30:12 Jeremy Fitzhardinge wrote:
> > Andi Kleen wrote:
> > > Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> > >
> > >> I see that IRQs are disabled in alternative_instructions(), but it does
> > >> not protect against NMIs,
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Andi Kleen wrote:
> > Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> >
> >> I see that IRQs are disabled in alternative_instructions(), but it does
> >> not protect against NMIs, which could come at a very inappropriate
> >> moment. MCE and
Andi Kleen wrote:
> Either not use any pvops or make sure all the pvops patching is atomic
> on the local CPU.
>
Erk, not really keen on that. Sounds complicated, unless there's a nice
general algorithm.
> Ok you can avoid MCEs by not enabling them until after you patch (which I
> think
>
On Thursday 19 July 2007 22:51:51 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Normally there are not that many NMIs or MCEs at boot, but it would
> > be still good to avoid the very rare crash by auditing the code first
> > [better than try to debug it on some production system later]
> >
Andi Kleen wrote:
> Normally there are not that many NMIs or MCEs at boot, but it would
> be still good to avoid the very rare crash by auditing the code first
> [better than try to debug it on some production system later]
>
Auditing it for what? If we want to make patching safe against
On Thursday 19 July 2007 22:30:12 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> >
> >> I see that IRQs are disabled in alternative_instructions(), but it does
> >> not protect against NMIs, which could come at a very inappropriate
> >>
Andi Kleen wrote:
> Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>
>> I see that IRQs are disabled in alternative_instructions(), but it does
>> not protect against NMIs, which could come at a very inappropriate
>> moment. MCE and SMIs would potentially cause the same kind of trouble.
>>
>> So
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> >
> > > Ewww you plan to run this in SMP ? So you actually go byte
> > > by byte changing pieces of instructions non atomically and doing
> > > non-Intel's errata friendly XMC. You are really
* Andi Kleen ([EMAIL PROTECTED]) wrote:
>
> > Ewww you plan to run this in SMP ? So you actually go byte
> > by byte changing pieces of instructions non atomically and doing
> > non-Intel's errata friendly XMC. You are really looking for trouble
> > there :) Two distinct errors can
> Ewww you plan to run this in SMP ? So you actually go byte
> by byte changing pieces of instructions non atomically and doing
> non-Intel's errata friendly XMC. You are really looking for trouble
> there :) Two distinct errors can occur:
In this case it is ok because this only
Hi Andi,
* Andi Kleen ([EMAIL PROTECTED]) wrote:
>
> Hallo,
>
> I had some second thoughts about the text patching of DEBUG_RODATA kernels
> using change_page_attr(). Change_page_attr is intrusive and slow and using
> a separate mapping is a little more gentle. I came up with this patch.
> For
On Thursday 19 July 2007 14:25:59 Jan Beulich wrote:
> I like this approach much better, just one small note (I think I
> had the same mistake in my changes initially):
>
> >@@ -202,7 +209,7 @@ static void alternatives_smp_lock(u8 **s
> > continue;
> > if (*ptr >
I like this approach much better, just one small note (I think I
had the same mistake in my changes initially):
>@@ -202,7 +209,7 @@ static void alternatives_smp_lock(u8 **s
> continue;
> if (*ptr > text_end)
> continue;
>-
Hallo,
I had some second thoughts about the text patching of DEBUG_RODATA kernels
using change_page_attr(). Change_page_attr is intrusive and slow and using
a separate mapping is a little more gentle. I came up with this patch.
For your review and testing pleasure.
The main quirk is that it
Hallo,
I had some second thoughts about the text patching of DEBUG_RODATA kernels
using change_page_attr(). Change_page_attr is intrusive and slow and using
a separate mapping is a little more gentle. I came up with this patch.
For your review and testing pleasure.
The main quirk is that it
I like this approach much better, just one small note (I think I
had the same mistake in my changes initially):
@@ -202,7 +209,7 @@ static void alternatives_smp_lock(u8 **s
continue;
if (*ptr text_end)
continue;
- **ptr =
On Thursday 19 July 2007 14:25:59 Jan Beulich wrote:
I like this approach much better, just one small note (I think I
had the same mistake in my changes initially):
@@ -202,7 +209,7 @@ static void alternatives_smp_lock(u8 **s
continue;
if (*ptr text_end)
Hi Andi,
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Hallo,
I had some second thoughts about the text patching of DEBUG_RODATA kernels
using change_page_attr(). Change_page_attr is intrusive and slow and using
a separate mapping is a little more gentle. I came up with this patch.
For your
Ewww you plan to run this in SMP ? So you actually go byte
by byte changing pieces of instructions non atomically and doing
non-Intel's errata friendly XMC. You are really looking for trouble
there :) Two distinct errors can occur:
In this case it is ok because this only happens
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Ewww you plan to run this in SMP ? So you actually go byte
by byte changing pieces of instructions non atomically and doing
non-Intel's errata friendly XMC. You are really looking for trouble
there :) Two distinct errors can occur:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Ewww you plan to run this in SMP ? So you actually go byte
by byte changing pieces of instructions non atomically and doing
non-Intel's errata friendly XMC. You are really looking for
Andi Kleen wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
I see that IRQs are disabled in alternative_instructions(), but it does
not protect against NMIs, which could come at a very inappropriate
moment. MCE and SMIs would potentially cause the same kind of trouble.
So unless you
On Thursday 19 July 2007 22:30:12 Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
I see that IRQs are disabled in alternative_instructions(), but it does
not protect against NMIs, which could come at a very inappropriate
moment. MCE and SMIs
Andi Kleen wrote:
Normally there are not that many NMIs or MCEs at boot, but it would
be still good to avoid the very rare crash by auditing the code first
[better than try to debug it on some production system later]
Auditing it for what? If we want to make patching safe against NMI/MCE,
On Thursday 19 July 2007 22:51:51 Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Normally there are not that many NMIs or MCEs at boot, but it would
be still good to avoid the very rare crash by auditing the code first
[better than try to debug it on some production system later]
Andi Kleen wrote:
Either not use any pvops or make sure all the pvops patching is atomic
on the local CPU.
Erk, not really keen on that. Sounds complicated, unless there's a nice
general algorithm.
Ok you can avoid MCEs by not enabling them until after you patch (which I
think
is the
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Andi Kleen wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
I see that IRQs are disabled in alternative_instructions(), but it does
not protect against NMIs, which could come at a very inappropriate
moment. MCE and SMIs would
* Andi Kleen ([EMAIL PROTECTED]) wrote:
On Thursday 19 July 2007 22:30:12 Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
I see that IRQs are disabled in alternative_instructions(), but it does
not protect against NMIs, which could come at
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Ewww you plan to run this in SMP ? So you actually go byte
by byte changing pieces of instructions non atomically and doing
non-Intel's
Andi Kleen wrote:
+ *addr = opcode;
+ /* Not strictly needed, but can speed CPU recovery up */
+ if (cpu_has_clflush)
+ asm(clflush (%0) :: r (addr) : memory);
+ if (addr != oaddr)
+ vunmap(addr);
clflush should take oaddr.
If you had to
Mathieu Desnoyers wrote:
Yes, kprobes is case 1: atomic update. And we don't even have to bother
about Intel's erratum. This one is ok. That's mainly the
alternatives/paravirt code I worry about.
Paravirt and alternatives should all be ok because they are done before
SMP bringup and with
48 matches
Mail list logo
