[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170824154102.62a02190@xeon-e3>
Date: Thu, 24 Aug 2017 15:41:02 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: kys@...hange.microsoft.com, Haiyang Zhang <haiyangz@...rosoft.com>
Cc: kys@...rosoft.com, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
olaf@...fle.de, apw@...onical.com, vkuznets@...hat.com,
jasowang@...hat.com, leann.ogasawara@...onical.com,
marcelo.cerri@...onical.com, sthemmin@...rosoft.com
Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Fix rescind handling issues
On Fri, 11 Aug 2017 10:03:59 -0700
kys@...hange.microsoft.com wrote:
> From: K. Y. Srinivasan <kys@...rosoft.com>
>
> This patch handles the following issues that were observed when we are
> handling racing channel offer message and rescind message for the same
> offer:
>
> 1. Since the host does not respond to messages on a rescinded channel,
> in the current code, we could be indefinitely blocked on the vmbus_open() call.
>
> 2. When a rescinded channel is being closed, if there is a pending interrupt on the
> channel, we could end up freeing the channel that the interrupt handler would run on.
>
> Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
> Reviewed-by: Dexuan Cui <decui@...rosoft.com>
> Tested-by: Dexuan Cui <decui@...rosoft.com>
This patch breaks re-initialization of the network device on MTU changes.
Doing:
# ip li set dev eth1 mtu 9000
will hang in rndis_filter_add waiting for subchannel notification.
This is likely because when the vmbus device is reopened the sub channels
are not correctly created. Not sure what is wrong with the patch, but my
suspicion is that the close/rescind events are no longer being sent to the
host.
Powered by blists - more mailing lists