On 3/9/24 05:26, Hou Tao wrote: > Hi, > > On 3/1/2024 9:42 PM, Miklos Szeredi wrote: >> On Wed, 28 Feb 2024 at 15:40, Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: >> >>> So instead of limiting both the values of max_read and max_write in >>> kernel, capping the maximal length of kvec iter IO by using max_pages in >>> fuse_direct_io() just like it does for ubuf/iovec iter IO. Now the max >>> value for max_pages is 256, so on host with 4KB page size, the maximal >>> size passed to kmalloc() in copy_args_to_argbuf() is about 1MB+40B. The >>> allocation of 2MB of physically contiguous memory will still incur >>> significant stress on the memory subsystem, but the warning is fixed. >>> Additionally, the requirement for huge physically contiguous memory will >>> be removed in the following patch. >> So the issue will be fixed properly by following patches? >> >> In that case this patch could be omitted, right? > > Sorry for the late reply. Being busy with off-site workshop these days. > > No, this patch is still necessary and it is used to limit the number of > scatterlist used for fuse request and reply in virtio-fs. If the length > of out_args[0].size is not limited, the number of scatterlist used to > map the fuse request may be greater than the queue size of virtio-queue > and the fuse request may hang forever. I'm currently also totally busy and didn't carefully check, but isn't there something missing that limits fc->max_write/fc->max_read? Thanks, Bernd
