> Can you try SysRq-i when you noticed io_schedule() deadlock? The intent of
> doing so is to test whether the reason of sleeping is that someone who is
> responsible to wake up failed to wake up or not. If someone failed to wake up,
> io_schedule() deadlock situation will continue because of uninterruptible sleep.
> If the reason is out of memory, terminating all processes should reclaim memory
> and allow someone who is responsible to wake up to wake up and io_schedule()
> deadlock situation should be solved.
>
> Also, can you try a debug patch shown below? This patch calls dump_page() in
> order to help understand state of the page in question. If someone failed to
> unlock the page, this patch should report forever. If someone failed to wake
> up, this patch should report only once (because of sleep with timeout).
>
> ----------------------------------------
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 693f622..192ed67f 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -36,6 +36,9 @@
>  #include <linux/cleancache.h>
>  #include <linux/shmem_fs.h>
>  #include <linux/rmap.h>
> +#include <linux/oom.h>          /* oom_lock */
> +#include <linux/sched/debug.h>  /* sched_show_task() */
> +#include <linux/sched/sysctl.h> /* sysctl_hung_task_timeout_secs */
>  #include "internal.h"
>
>  #define CREATE_TRACE_POINTS
> @@ -1076,6 +1079,7 @@ static inline int wait_on_page_bit_common(wait_queue_head_t *q,
>         struct wait_page_queue wait_page;
>         wait_queue_entry_t *wait = &wait_page.wait;
>         int ret = 0;
> +       unsigned long start = jiffies;
>
>         init_wait(wait);
>         wait->flags = lock ? WQ_FLAG_EXCLUSIVE : 0;
> @@ -1084,6 +1088,10 @@ static inline int wait_on_page_bit_common(wait_queue_head_t *q,
>         wait_page.bit_nr = bit_nr;
>
>         for (;;) {
> +               unsigned long timeout = sysctl_hung_task_timeout_secs;
> +               if (!timeout)
> +                       timeout = 60;
> +
>                 spin_lock_irq(&q->lock);
>
>                 if (likely(list_empty(&wait->entry))) {
> @@ -1095,8 +1103,17 @@ static inline int wait_on_page_bit_common(wait_queue_head_t *q,
>
>                 spin_unlock_irq(&q->lock);
>
> -               if (likely(test_bit(bit_nr, &page->flags))) {
> -                       io_schedule();
> +               if (likely(test_bit(bit_nr, &page->flags)) &&
> +                   io_schedule_timeout(timeout * HZ) == 0) {
> +                       char buf[32];
> +                       struct task_struct *t = current;
> +                       snprintf(buf, sizeof(buf), "stuck on bit %u", bit_nr);
> +                       mutex_lock(&oom_lock);
> +                       pr_err("INFO: task %s:%d blocked for %lu seconds.\n",
> +                              t->comm, t->pid, (jiffies - start) / HZ);
> +                       sched_show_task(t);
> +                       dump_page(page, buf);
> +                       mutex_unlock(&oom_lock);
>                 }
>
>                 if (lock) {
> ----------------------------------------

Yes, I reproduced KVM hang with patch above.
New dmesg is attached.
But I don't know how SysRq-i helps in real life, because after SysRq-i
system became unusable.
Why memory couldn't be reclaimed after OOM without SysRq-i?

>
> I tried to reproduce your problem using plain idle Fedora 27 guest (RAM 4GB + SWAP 4GB).
> While the system apparently hang after OOM killer, the system seemed to be just under
> swap memory thrashing situation, for heavy disk I/O had been observed from the host side.
> Thus, my case might be different from your case.
>

It's looks like you repeated my case correctly. Did you succeed to
reproduce freeze virtual guest machine?
After OOM heavy disk I/O must ended, but virtual machine in KVM wouldn't alive.
Also some command cause freeze.
For example on my machine impossible run `ps aux` because `ps aux`
command freeze imminently after start.
Also impossible open new tab in gnome-terminal.



--
Best Regards,
Mike Gavrilov.