Manuel Bouyer wrote:
I guess it's a side effect of the malloc implementation; but I don't think we can rely on it either. Better use uvm_km_alloc() for this; which take an explicit alignement parameter.
Well, the man page of malloc(9) does state that the return value is suitably aligned. I thought the same about kmem_alloc(), but looks like my supposition is wrong.
Who is at fault here? Should NetBSD add some checks against invalid mappings (when hypercall returns EINVAL for a foreign domain), or should xentools check the validity (against a poison for example) and abort the operation if it triggers?If the hypercall returns a proper error code, it should be used and handled appropriately, I'd say.
In fact, we end up like this:- first, we try the mapping inside the IOCTL_PRIVCMD_MMAP(BATCH); when it fails (pmap_enter_ma returns an error), we flag the address as invalid inside the privcmd_object/uobj.
- second, when privpgop_fault is called. However, we never fall back to pmap_enter_ma (which will return the same error as before): we check against INVALID_PAGE, and if positive, issue a continue. Since error is set to 0 by default, we end up in a loop with privpgop_fault.
IMHO, in case of an INVALID_PAGE, we should return EFAULT, just to indicate that the thing is indeed wrong, like in [1]. The caller is free to find through the ioctl which element in the array is faulty.
[1] http://www.netbsd.org/~jym/privcmd.diff -- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost