On Mon, Nov 26, 2018 at 02:52:25AM -0500, Sasha Levin wrote:
> 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.
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.
> 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 :)
thanks,
greg k-h
