[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: xen crash in tmem: checking a xen pfn for domain ownership
Gfn_to_mfn() takes a domain as a parameter. It looks up gfn in that domain's p2m. The only RAM-typed pfns that can be present in a domain's p2m, if it is not sharing pages via memshr, are the domain's own pages. As far as I know, at least. It does no harm for you to switch to gfn_to_mfn_unshare(), but I doubt this is the fix for your current problem. -- Keir On 17/09/2010 17:48, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote: > Thanks for the reply, but I'm not sure I understand. > > Ignore memory sharing for now... > > Are you saying, yes, the ownership check IS performed? > E.g. if gpfn is a random number, NULL will always be > returned (unless of course the random number happens > to be a valid gfn for current->domain)? > > Or are you saying its plausible that this IS the problem > (that I am not checking for ownership)? > > Now bring memory sharing back in... > > Since tmem and memory sharing are supposed to be complementary > (though I don't think anybody has ever tried using both > together), are you saying I should change this one > call from gfn_to_mfn() to gfn_to_mfn_unshare() for > some reason (e.g. maybe to avoid a race)? Note > that this code is just getting a virtual address > to copy a page to/from the guest. > > Thanks, > Dan > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] >> Sent: Friday, September 17, 2010 10:35 AM >> To: Dan Magenheimer; Jan Beulich >> Cc: Xen-devel >> Subject: Re: xen crash in tmem: checking a xen pfn for domain ownership >> >> If you could be doing memory sharing then you might need to use >> gfn_to_mfn_unshare()? Otherwise it looks pretty plausible, and that one >> flaw >> is pretty minor as you're probably not using memshr. >> >> -- Keir >> >> On 17/09/2010 17:29, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> >> wrote: >> >>> Does the construct: >>> >>> xen_pfn_t gpfn; >>> p2m_type_t t; >>> unsigned long mfn; >>> >>> mfn = mfn_x(gfn_to_mfn(current->domain, gpfn, &t)); >>> if (t != p2m_ram_rw || cli_mfn == INVALID_MFN) >>> return NULL; /* bad */ >>> return map_domain_page(mfn) >>> >>> somehow check to ensure that pfn belongs to current->domain? >>> (See cli_mfn_to_va() in common/tmem_xen.c.) >>> >>> If not, is there an easy way to perform that check? >>> (preferably one that works for both HVM and PV guests) >>> >>> In debugging a tmem Linux-side guest patch, I discovered >>> that a bad mfn passed by the guest can crash Xen and >>> I think this assumption might be the problem. >>> >>> Thanks, >>> Dan >> >> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |