[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Missing checks for xc_map_foreign_range() failure


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Markus Armbruster <armbru@xxxxxxxxxx>
  • Date: Fri, 31 Aug 2007 16:06:54 +0200
  • Delivery-date: Fri, 31 Aug 2007 07:09:27 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

privcmd_ioctl() case IOCTL_PRIVCMD_MMAPBATCH has two different ways to
indicate failure:

1. The usual way: do nothing and return error code.

2. An unusual way: set the most significant four bits of those
   elements of the mfn array argument that could not be mapped, and
   return 0.

   When the array isn't writable, the error information is simply
   discarded.

xc_map_foreign_range() behaves exactly the same.  Its second failure
mode isn't documented anywhere I can see.  Doc bug.

Some users of xc_map_foreign_range() search the array for failed mfns.
Others don't.  All check the return value.

There might be uses for the second failure mode of
xc_map_foreign_range() which justify this awkward API.
qemu_remap_bucket() looks like such a case.

Other, more naive uses would profit from a less awkward convenience
function that either succeeds completely or fails completely.  As far
as I can see, these uses all neglect to check for the second failure
mode so far.  Potential crash bugs.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.