Re: FAILED: patch "[PATCH] Drivers: hv: kvp: Fix the recent regression caused by" failed to apply to 4.19-stable tree

[Sasha Levin <sashal@kernel.org>]

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"?

>> 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.
>
>True, but given when this patch was sent to me, the maintainer should
>have known better :)

Fair enough, I just want to encourage people "over-tagging" for stable
in the general case.

--
Thanks,
Sasha