On Wed 11-01-23 09:00:04, Jiri Slaby wrote:
> Hi,
>
> after I updated the host from 6.0 to 6.1 (being at 6.1.4 ATM), my qemu VMs
> started stalling (and the host at the same point too). It doesn't happen
> right after boot, maybe a suspend-resume cycle is needed (or longer uptime,
> or a couple of qemu VM starts, or ...). But when it happens, it happens all
> the time till the next reboot.
>
> Older guest's kernels/distros are affected as well as Win10.
>
> In guests, I see for example stalls in memset_orig or
> smp_call_function_many_cond -- traces below.
>
> qemu-kvm-7.1.0-13.34.x86_64 from openSUSE.
>
> It's quite interesting that:
> $ cat /proc/<PID_OF_QEMU>/cmdline
> is stuck at read:
>
> openat(AT_FDCWD, "/proc/12239/cmdline", O_RDONLY) = 3
> newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
> fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f22f0487000
> read(3, ^C^C^C^\^C
This will require mmap_lock for read as well. And that is blocked
because there is a pending writer as well.
[...]
> Is this known? Any idea how to debug this?
I would recommend taking a crashdump when the host is in that state and
examine the state of the blocked lock. Dump will hopefully give you more
information about potential holder of the lock. If it is blocked on
writer then you should get the owner task. If it is in read mode then
this can get more tricky because the exact owner might be different from
the recorded one. Anyway the full list of tasks and their backtraces
could tell more.
HTH
--
Michal Hocko
SUSE Labs
