Re: [Xen-devel] xenwatch_dev_cb into D states with abnormal socket connect between host and VM

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Oct 23, 2014 at 08:02:24AM +0000, Dingweiping wrote:
> Hi,
> 
> I have met a netback issue.
> 
> when a socket connect between Host and VMïthe server in Host and
> client in VMïif the client send messageïbut server donât receive
> packet with some unknown reasonïnow shutdown the VMï netbackâs
> xenwatch_dev_cb kernel thread into D states, Until kill server
> process, netback exit D states,
> 
> the stack of xenwatch_dev_cb is:
> [<ffffffffa0947135>] netif_disconnect+0x75/0x200 [netbk]
> [<ffffffffa0945f06>] netback_disconnect+0x76/0xb0 [netbk]
> [<ffffffffa094671a>] frontend_changed+0x12a/0x430 [netbk]
> [<ffffffff802f5add>] xenwatch_dev_callback+0x8d/0x120
> [<ffffffff80069c16>] kthread+0x96/0xa0
> [<ffffffff80415f74>] kernel_thread_helper+0x4/0x10
> 
> By analyzing the module drivers/xen/netback, I think the reason is as
> follows:
> 
> 1.       the thread hold in wait_event(netif->waiting_to_free,
> atomic_read(&netif->refcnt) == 0) in netif_disconnect fun, because
> netif->refcnt not equal 0ï
> 
> 2.       when the socket connected but server donât receive
> packetïthe skb from netback will be queued in socketâs list, and
> skbâs page canât be unmap, the netbackâs refcnt canât be decrease.
> 
> Xen4.1.2 and host is SUSE 11 SP3, kernel 3.0.93-0.8-xen;
> 

If you're using SuSE kernel, then you should probably report this
problem to SuSE. Anyway, this kernel is really old and probably has some
vendor specific patches, I don't think I can provide much help here.

IMHO netback is doing the right thing. Resource is still in use, there's
no way netback just releases that.

In any case, probably the first step would be to investigate the
"unknown reason" that prevent server from receiving the packet? Or
investigate why this packet is not timed out and eventually get freed?
If the packet is delivered to host stack, netback is out of the
picture. Don't try to solve a problem that doesn't exist. :-)

Wei.

> Does anyone have met such problems? Thanks.
> 
> Best regards, Zhang Yabin
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel