summaryrefslogtreecommitdiffstats
path: root/lib/Makefile
diff options
context:
space:
mode:
authorConnor Kuehl <ckuehl@redhat.com>2021-03-18 08:52:22 -0500
committerMiklos Szeredi <mszeredi@redhat.com>2021-04-14 10:40:57 +0200
commita7f0d7aab0b4f3f0780b1f77356e2fe7202ac0cb (patch)
treeaeaccd4413406edb9128aa1f9794d7337c7e66c9 /lib/Makefile
parentc79c5e0178922a9e092ec8fed026750f39dcaef4 (diff)
downloadlinux-a7f0d7aab0b4f3f0780b1f77356e2fe7202ac0cb.tar.bz2
virtiofs: split requests that exceed virtqueue size
If an incoming FUSE request can't fit on the virtqueue, the request is placed onto a workqueue so a worker can try to resubmit it later where there will (hopefully) be space for it next time. This is fine for requests that aren't larger than a virtqueue's maximum capacity. However, if a request's size exceeds the maximum capacity of the virtqueue (even if the virtqueue is empty), it will be doomed to a life of being placed on the workqueue, removed, discovered it won't fit, and placed on the workqueue yet again. Furthermore, from section 2.6.5.3.1 (Driver Requirements: Indirect Descriptors) of the virtio spec: "A driver MUST NOT create a descriptor chain longer than the Queue Size of the device." To fix this, limit the number of pages FUSE will use for an overall request. This way, each request can realistically fit on the virtqueue when it is decomposed into a scattergather list and avoid violating section 2.6.5.3.1 of the virtio spec. Signed-off-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'lib/Makefile')
0 files changed, 0 insertions, 0 deletions