On Mon, Nov 26, 2018 at 03:16:14AM -0500, Sasha Levin wrote:
On Mon, Nov 26, 2018 at 08:57:08AM +0100, Greg KH wrote:
On Mon, Nov 26, 2018 at 02:52:25AM -0500, Sasha Levin wrote:
On Mon, Nov 26, 2018 at 08:40:09AM +0100, gregkh@linuxfoundation.org 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@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e670de54c813b5bc3672dd1c67871dc60e9206f4 Mon Sep 17 00:00:00 2001
From: Dexuan Cui decui@microsoft.com 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@microsoft.com Cc: K. Y. Srinivasan kys@microsoft.com Cc: Stephen Hemminger sthemmin@microsoft.com Signed-off-by: Haiyang Zhang haiyangz@microsoft.com Cc: Stable@vger.kernel.org Signed-off-by: K. Y. Srinivasan kys@microsoft.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
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.
Yeah, I saw that this was trying to fix a 4.20-rc patch, but I wanted to let the authors know that this failed and if they had messed up on that tag, they could have resent it.
Fair enough, so maybe a different message here? "No relevant stable trees to apply this patch on"?
Yeah, good point, I'll work on that, thanks.
greg k-h