On Thu, Apr 18, 2019 at 10:19:04AM +0800, Ming Lei wrote:
Hi Paolo,
On Wed, Apr 17, 2019 at 01:52:07PM +0200, Paolo Bonzini wrote:
Because bio_kmalloc uses inline iovecs, the limit on the number of entries is not BIO_MAX_PAGES but rather UIO_MAXIOV, which indeed is already checked in bio_kmalloc. This could cause SG_IO requests to be truncated and the HBA to report a DMA overrun.
BIO_MAX_PAGES only limits the single bio's max vector number, if one bio can't hold all user space request, new bio will be allocated and appended to the passthrough request if queue limits aren't reached.
So I understand SG_IO request shouldn't be truncated because of BIO_MAX_PAGES, or could you explain it in a bit detail or provide a reproducer?
Note that if the argument to iov_iter_npages were changed to UIO_MAXIOV, we would still truncate SG_IO requests beyond UIO_MAXIOV pages. Changing it to UIO_MAXIOV + 1 instead ensures that bio_kmalloc notices that the request is too big and blocks it.
We should pass UIO_MAXIOV instead of UIO_MAXIOV + 1, otherwise bio_kmalloc() will fail. Otherwise, the patch looks fine, but shouldn't be a fix if my above analysis is correct.
Also we have enabled multipage bvec for passthough IO[1], we shouldn't need to allocate so big max io vectors any more, and actually the reasonable number is (PAGE_SIZE - sizeof(struct bio)) / sizeof(struct bio_vec), then we can avoid to stress mm for high order allocation.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit...
Thanks, Ming