Messages in this thread | | | Date | Mon, 10 Mar 2008 11:53:19 +0000 | From | "Jan Beulich" <> | Subject | Re: [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
| |