This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Missing checks for xc_map_foreign_range() failure
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Fri, 31 Aug 2007 16:06:54 +0200
Delivery-date: Fri, 31 Aug 2007 07:09:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
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

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

<Prev in Thread] Current Thread [Next in Thread>