Re: Shutting down a VM with Kernel 4.14 will sometime hang and a reboot is the only way to recover.

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: David Hill <dhill@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, Willem de Bruijn <willemb@google.com>,
	netdev <netdev@vger.kernel.org>
Subject: Re: Shutting down a VM with Kernel 4.14 will sometime hang and a reboot is the only way to recover.
Date: Tue, 19 Dec 2017 11:19:51 -0500	[thread overview]
Message-ID: <CAF=yD-L2w2qAJFRtj-m8s8i7kw6_L0O9FhH6oWx4C0X_i94ksA@mail.gmail.com> (raw)
In-Reply-To: <cd0ea113-34ff-d24a-b798-819dfb536c76@redhat.com>

>> It looks like the first bad commit would be the following:
>>
>> [jenkins@zappa linux-stable-new]$ sudo bash bisect.sh -g
>> 3ece782693c4b64d588dd217868558ab9a19bfe7 is the first bad commit
>> commit 3ece782693c4b64d588dd217868558ab9a19bfe7
>> Author: Willem de Bruijn <willemb@google.com>
>> Date:   Thu Aug 3 16:29:38 2017 -0400
>>
>>     sock: skb_copy_ubufs support for compound pages
>>
>>     Refine skb_copy_ubufs to support compound pages. With upcoming TCP
>>     zerocopy sendmsg, such fragments may appear.
>>
>>     The existing code replaces each page one for one. Splitting each
>>     compound page into an independent number of regular pages can result
>>     in exceeding limit MAX_SKB_FRAGS if data is not exactly page aligned.
>>
>>     Instead, fill all destination pages but the last to PAGE_SIZE.
>>     Split the existing alloc + copy loop into separate stages:
>>     1. compute bytelength and minimum number of pages to store this.
>>     2. allocate
>>     3. copy, filling each page except the last to PAGE_SIZE bytes
>>     4. update skb frag array
>>
>>     Signed-off-by: Willem de Bruijn <willemb@google.com>
>>     Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> :040000 040000 f1b652be7e59b1046400cad8e6be25028a88b8e2
>> 6ecf86d9f06a2d98946f531f1e4cf803de071b10 M    include
>> :040000 040000 8420cf451fcf51f669ce81437ce7e0aacc33d2eb
>> 4fc8384362693e4619fab39b0a945f6f2349226b M    net
>>
>> Here is the bisect log:
>
>
> Thanks for the hard bisecting.
>
> Cc netdev and Willem.

This is being discussed in

http://lkml.kernel.org/r/<CAF=yD-LWyCD4Y0aJ9O0e_CHLR+3JOeKicRRTEVCPxgw4XOcqGQ@mail.gmail.com>

David also previously reported this at

  https://bugzilla.kernel.org/show_bug.cgi?id=197861

which has a pointer to the above thread, too. Let's discuss this in a
single thread. I have suggested a fix there.

Thanks for bisecting. Please also test the patch in the above thread
if possible.