|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Missing checks for xc_map_foreign_range() failure
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Missing checks for xc_map_foreign_range() failure,
Markus Armbruster <=
|
|
|
|
|