On Fri, Oct 12, 2018 at 02:52:46AM +0000, Dexuan Cui wrote:
>
> The host may send multiple negotiation packets
> (due to timeout) before the KVP user-mode daemon
> is connected. KVP user-mode daemon is connected.
> We need to defer processing those packets
> until the daemon is negotiated and connected.
> It's okay for guest to respond
> to all negotiation packets.
>
> In addition, the host may send multiple staged
> KVP requests as soon as negotiation is done.
> We need to properly process those packets using one
> tasklet for exclusive access to ring buffer.
>
> This patch is based on the work of
> Nick Meier <Nick.Meier@xxxxxxxxxxxxx>.
>
> Signed-off-by: Long Li <longli@xxxxxxxxxxxxx>
> Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>
> The above is the original changelog of
> a3ade8cc474d ("HV: properly delay KVP packets when negotiation is in progress"
>
> Here I re-worked the original patch because the mainline version
> can't work for the linux-4.4.y branch, on which channel->callback_event
> doesn't exist yet. In the mainline, channel->callback_event was added by:
> 631e63a9f346 ("vmbus: change to per channel tasklet"). Here we don't want
> to backport it to v4.4, as it requires extra supporting changes and fixes,
> which are unnecessary as to the KVP bug we're trying to resolve.
>
> NOTE: before this patch is used, we should cherry-pick the other related
> 3 patches from the mainline first:
>
> 2d0c3b5 ("Drivers: hv: utils: Invoke the poll function after handshake")
> b9830d1 ("Drivers: hv: util: Pass the channel information during the init call")
> 4dbfc2e ("Drivers: hv: kvp: fix IP Failover")
>
> And, actually it would better if we can cherry-pick more fixes from the
> mainline first (the 3 above patches are also included in this 27-patch list):
>
> 01 b003596 Drivers: hv: utils: use memdup_user in hvt_op_write
> 02 2d0c3b5 Drivers: hv: utils: Invoke the poll function after handshake
> 03 1f75338 Drivers: hv: utils: fix memory leak on on_msg() failure
> 04 a72f3a4 Drivers: hv: utils: rename outmsg_lock
> 05 a150256 Drivers: hv: utils: introduce HVUTIL_TRANSPORT_DESTROY mode
> 06 9420098 Drivers: hv: utils: fix crash when device is removed from host side
> 07 77b744a Drivers: hv: utils: fix hvt_op_poll() return value on transport destroy
> 08 b9830d1 Drivers: hv: util: Pass the channel information during the init call
> 09 e66853b Drivers: hv: utils: Remove util transport handler from list if registration fails
> 10 4dbfc2e Drivers: hv: kvp: fix IP Failover
> 11 e0fa3e5 Drivers: hv: utils: fix a race on userspace daemons registration
> 12 497af84 Drivers: hv: utils: Continue to poll VSS channel after handling requests.
> 13 db886e4 Drivers: hv: utils: Check VSS daemon is listening before a hot backup
> 14 abeda47 Drivers: hv: utils: Rename version definitions to reflect protocol version.
> 15 2e338f7 Drivers: hv: utils: Use TimeSync samples to adjust the clock after boot.
> 16 8e1d260 Drivers: hv: utils: Support TimeSync version 4.0 protocol samples.
> 17 3ba1eb1 Drivers: hv: hv_util: Avoid dynamic allocation in time synch
> 18 3da0401b Drivers: hv: utils: Fix the mapping between host version and protocol to use
> 19 23d2cc0 Drivers: hv: vss: Improve log messages.
> 20 b357fd3 Drivers: hv: vss: Operation timeouts should match host expectation
> 21 1724462 hv_util: switch to using timespec64
> 22 a165645 Drivers: hv: vmbus: Use all supported IC versions to negotiate
> 23 1274a69 Drivers: hv: Log the negotiated IC versions.
> 24 bb6a4db Drivers: hv: util: Fix a typo
> 25 e9c18ae Drivers: hv: util: move waiting for release to hv_utils_transport itself
> 26 bdc1dd4 vmbus: fix spelling errors
> 27 ddce54b Drivers: hv: kvp: Use MAX_ADAPTER_ID_SIZE for translating adapter id
>
> This to to say, we're requesting a backport of 4 patches or 28 patches.
> If 28 patches seem too many, we hope at least the 4 patches can be backported.
28 seems odd, there's lots of things in there that you do not need.
So 4 is good, can you send all 4 as a patch series, properly backported
and tested with this patch as the last one?
> The patches can be applied cleanly to the latest v4.4 branch (currently it's
> v4.4.160).
But, I really want to know why people are still trying to use the 4.4
kernel right now for a "general purpose" system. They should be using
4.9 at the very least by now, 4.4 is not a good idea at all. Why can
you not just move your users to 4.9 instead of a newer 4.4 kernel? It
should be the exact same, right?
thanks,
greg k-h
