linux-kernel - RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Nov 2018 08:17:04 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
        "apw@...onical.com" <apw@...onical.com>,
        vkuznets <vkuznets@...hat.com>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        Michael Kelley <mikelley@...rosoft.com>
Subject: RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of
 channels to two workqueues

> From: gregkh@...uxfoundation.org <gregkh@...uxfoundation.org>
> Sent: Wednesday, November 28, 2018 11:45 PM
> >
> > There is no change in this repost. I just rebased this patch to today's
> > char-misc's char-misc-next branch. Previously KY posted the patch with his
> > Signed-off-by (which is kept in this repost), but there was a conflict issue.
> >
> > Note: the patch can't be cleanly applied to char-misc's char-misc-linus branch
> --
> > to do that, we need to cherry-pick the supporting patch first:
> > 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> vmbus_get_outgoing_channel()")
> 
> That is not going to work for the obvious reason that this dependant
> patch is not going to be merged into 4.20-final.

It looks the dependent patch (4d3c5c69191f) is going to miss the v4.20 release. 
This is not a big issue, as the dependent patch isn't really important.
 
> So, what do you expect us to do here?  The only way this can be accepted
> is to have it go into my -next branch, which means it will show up in
> 4.21-rc1, is that ok?

Is there any chance for this patch ("Drivers: hv: vmbus: Offload the handling ...") to
go into v4.20? 

If yes, I can quickly do a rebase to char-misc's char-misc-linus branch,
because actually the conflict can be very easily fixed. And I can help to fix any 
conflict when the dependent patch is backported to v4.20.1.

If no, I think this patch and the dependent patch can both go into v4.21, and 
they can be both backported to v4.20.1 in future.

> But then, if that happens, it will fail to apply to any stable tree for
> 4.20 and older, like you are asking it to be done for.
> 
> So what do you expect me to do here with this?
> 
> totally confused,
> 
> greg k-h

I hope my above reply made me clear. Sorry, I'm not really know how exactly
the releasing procedure works...

Thanks,
-- Dexuan