On Aug 30, 2006, at 8:10 PM, [EMAIL PROTECTED] wrote:

I saw this fire once and was mightily confused by the "type" printed.

Thanks Amos, this pointed out a lot of INVALID_MFN cleanup that needed to be done, should push that soon. Amos, IIRC the address that actually _was_ printed was was a paddr of 0xc000000 (192Mib), too bad thats all the inof we have :(

Hollis, ASAICT the only way Amos could have gotten here (and passed the BUG() in pfn2mfn()) is if one of the user_copy routines tried to access a PFN_TYPE_REMOTE or PFN_TYPE_IO, that paddr is not an IO type so the question I have for you is: Is it possible for Xen (on behalf of a privileged domain) use a user_copy routine to access another domains memory?

-JX



Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>

---

 usercopy.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -r e12aa1195f58 xen/arch/powerpc/usercopy.c
--- a/xen/arch/powerpc/usercopy.c       Wed Aug 30 18:35:20 2006 -0400
+++ b/xen/arch/powerpc/usercopy.c       Wed Aug 30 20:08:35 2006 -0400
@@ -52,8 +52,8 @@ static unsigned long paddr_to_maddr(unsi
         case PFN_TYPE_LOGICAL:
             break;
         default:
-            panic("%s: called with bad memory address type: 0x%lx\n",
-                    __func__, paddr);
+            panic("%s: address 0x%lx has bad address type: 0x%x\n",
+                    __func__, paddr, mtype);
             break;
     }
     pa <<= PAGE_SHIFT;


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Reply via email to