[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48B43E2E.5000207@zytor.com>
Date: Tue, 26 Aug 2008 10:32:30 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC: "Luiz Fernando N. Capitulino" <lcapitulino@...driva.com.br>,
Gerhard Brauer <gerhard.brauer@....de>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Colin Ian King <colin.king@...ntu.com>
Subject: Re: 2.6.{26.2,27-rc} oops on virtualbox
I have been unable to replicate this on my own hardware mostly because
my testing machine decided to blow its DVD drive in some very strange
way, but I did pick apart the data from Luiz, and found it very interesting:
The code sequence before patching looks like:
c012fc69: 51 push %ecx
c012fc6a: 52 push %edx
c012fc6b: ff 15 40 b9 41 c0 call *0xc041b940
c012fc71: 5a pop %edx
c012fc72: 59 pop %ecx
After patching:
50 9d 0f 1f 84 00 00 00 <00> 00
... which disassembles to (in Intel notation):
C012FC69 50 push eax
C012FC6A 9D popfd
C012FC6B 0F1F840000000000 nop dword [eax+eax+0x0]
We do, indeed have a return point that falls in the *middle* of a
patched instruction, and if the patching happens in the middle of the
instruction call, then, well, bad things happen.
Furthermore, why on Earth is %ecx/%edx pushed and popped in-line here?
Surely it should be the responsibility of the PV call to present a
no-clobber interface (using an assembly wrapper if necessary[*]), rather
than bloating every callsite like this?
-hpa
[*] One can compile gcc code with -fcall-saved-* to use nonstandard
register conventions. Unfortunately stock gcc only lets you do this
with a file parameter, and doesn't support doing this with attributes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists