On Mon, Nov 26, 2018 at 08:40:09AM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@xxxxxxxxxxxxxxx>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e670de54c813b5bc3672dd1c67871dc60e9206f4 Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui@xxxxxxxxxxxxx>
Date: Thu, 18 Oct 2018 05:09:30 +0000
Subject: [PATCH] Drivers: hv: kvp: Fix the recent regression caused by
incorrect clean-up
In kvp_send_key(), we do need call process_ib_ipinfo() if
message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
the userland hv_kvp_daemon needs the info of operation, adapter_id and
addr_family. With the incorrect fc62c3b1977d, the host can't get the
VM's IP via KVP.
And, fc62c3b1977d added a "break;", but actually forgot to initialize
the key_size/value in the case of KVP_OP_SET, so the default key_size of
0 is passed to the kvp daemon, and the pool files
/var/lib/hyperv/.kvp_pool_* can't be updated.
This patch effectively rolls back the previous fc62c3b1977d, and
correctly fixes the "this statement may fall through" warnings.
This patch is tested on WS 2012 R2 and 2016.
Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall through" warnings")
Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
Cc: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
Cc: Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>
Signed-off-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
Cc: <Stable@xxxxxxxxxxxxxxx>
Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Hi Greg,
I think that your scripts need a little tweak to ignore stable tagged
commits where the commit they fix isn't in any of the stable trees. For
example, this commit fixes a bug that was introduced in 4.20 so it
doesn't actually apply to any of the stable trees even though it was
tagged for stable.
You can argue that it shouldn't have been tagged for stable to begin
with, but I think that we should encourage stable tags with
corresponding "Fixes:" tags since that since authors and maintainers
don't necessarily know when a patch will be merged, and it's possible
that this patch would have been merged in the next release, thus making
it stable material.
--
Thanks,
Sasha
