lkml.org 
[lkml]   [2008]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86: fix typo(?) in step.c
>>> Ingo Molnar <mingo@elte.hu> 06.03.08 14:11 >>>
>
>* Roland McGrath <roland@redhat.com> 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



\
 
 \ /
  Last update: 2008-03-10 12:55    [W:0.042 / U:15.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site