Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > Wait a sec; just how would that work for ITER_KVEC? AFAICS, in your > tree that would blow with -EFAULT... You're right. I wonder if I should handle ITER_KVEC in iov_iter_extract_pages(), though I'm sure I've been told that a kvec might point to data that doesn't have a matching page struct. Or maybe it's that the refcount shouldn't be changed on it. A question for the 9p devs: Looking more into p9_virtio_zc_request(), it might be better to use netfs_extract_iter_to_sg(), since the page list is going to get turned into one, instead of calling p9_get_mapped_pages() and pack_sg_list(). This would, however, require that chan->sg[] be populated outside of the spinlock'd section - is there any reason that this can't be the case? There's nothing inside the locked section that makes sure the chan can be used before it launches into loading up the scatterlist. There is a wait afterwards, but it has to drop the lock first, so wouldn't stop a parallel op from clobbering chan->sg[] anyway. Further, if virtqueue_add_sgs() fails with -ENOSPC and we go round again to req_retry_pinned, do we actually need to reload chan->sg[]? David
