Re: VMs getting into stuck states since kernel ~5.13

["Arkadiusz Miśkiewicz" <a.miskiewicz@gmail.com>]

W dniu 08.12.2021 o 19:54, Chris Murphy pisze:
> Hi,
> 
> I'm trying to help progress a kernel regression hitting Fedora
> infrastructure in which dozens of VMs run concurrently to execute QA
> testing. The problem doesn't happen immediately, but all the VM's get
> stuck and then any new process also gets stuck, so extracting
> information from the system has been difficult and there's not a lot
> to go on, but this is what I've got so far.

Does qemu there have this fix?

https://github.com/qemu/qemu/commit/cc071629539dc1f303175a7e2d4ab854c0a8b20f

block: introduce max_hw_iov for use in scsi-generic
Linux limits the size of iovecs to 1024 (UIO_MAXIOV in the kernel
sources, IOV_MAX in POSIX).  Because of this, on some host adapters
requests with many iovecs are rejected with -EINVAL by the
io_submit() or readv()/writev() system calls.

In fact, the same limit applies to SG_IO as well.  To fix both the
EINVAL and the possible performance issues from using fewer iovecs
than allowed by Linux (some HBAs have max_segments as low as 128),
introduce a separate entry in BlockLimits to hold the max_segments
value from sysfs.  This new limit is used only for SG_IO and clamped
to bs->bl.max_iov anyway, just like max_hw_transfer is clamped to
bs->bl.max_transfer.


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )