Re: [PATCH] x86: fix typo(?) in step.c

[Jan Beulich]

>>> Ingo Molnar <mingo@xxxxxxx> 06.03.08 14:11 >>>
>
>* Roland McGrath <roland@xxxxxxxxxx> wrote:
>
>> I know.  That completely misses the point I just made:
>> 
>>    As I said then, one of my concerns was with the low-level tweaks 
>>    not yet sufficiently baked, independent from my reservations about 
>>    the ptrace feature.  Your #if'ing out of the user ABI additions for 
>>    2.6.25 does nothing to remove the unknown new risks from all the 
>>    tweaks with fingers in the low-level arch stuff.  This is the sort 
>>    of thing I was concerned about.
>> 
>> You didn't revert the parts that ever could have caused problems for 
>> anyone except those using the new ptrace extensions, i.e. changes to 
>> step.c, context switch, whatever else was touched we've lost track of 
>> now.  I keep saying that those are not baked, 100% independent of the 
>> ptrace feature.  You don't seem to be hearing me.
>
>well the issue is that both regset and bts had regressions, so the 
>safest was to do the minimal step of undoing any externally visible 
>changes. Feel free to send a reverter patch for the other lowlevel bts 
>bits as well.

So, is this going to be fully reverted, or is it worth pointing out/fixing
other issues? The thing I'm recognizing right now is that
eee3af4a2c83a97fff107ddc445d9df6fded9ce4 made the writes to
DebugCtlMSR unconditional, which means any attempt to do
debugging on i[345]86 will ultimately cause the kernel to oops. All of
that stuff should really depend on CONFIG_X86_DEBUGCTLMSR...

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/