From: Markus Armbruster Subject: Missing checks for xc_map_foreign_range() failure Date: Fri, 31 Aug 2007 16:06:54 +0200 Message-ID: <87k5rbre69.fsf@pike.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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.