From: Greg KH <gregkh@linuxfoundation.org>
To: KY Srinivasan <kys@microsoft.com>
Cc: "apw@canonical.com" <apw@canonical.com>,
"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"olaf@aepfle.de" <olaf@aepfle.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element
Date: Thu, 12 Mar 2015 14:28:37 +0100 [thread overview]
Message-ID: <20150312132837.GA31417@kroah.com> (raw)
In-Reply-To: <BY2PR0301MB07112E8E14999AA2EA2784A9A0060@BY2PR0301MB0711.namprd03.prod.outlook.com>
On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Thursday, March 12, 2015 2:03 AM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > per-channel work element
> >
> > On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > > This patch is a continuation of the rescind handling cleanup work.
> > > > We cannot block in the global message handling work context
> > > > especially if we are blocking waiting for the host to wake us up. I
> > > > would like to thank Dexuan Cui <decui@microsoft.com> for observing
> > this problem.
> > > >
> > > > The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > ---
> > > > drivers/hv/channel_mgmt.c | 143
> > +++++++++++++++++++++++++++++++-------------
> > > > drivers/hv/connection.c | 6 ++-
> > > > drivers/hv/hyperv_vmbus.h | 2 +-
> > > > 3 files changed, 107 insertions(+), 44 deletions(-)
> > >
> > > This is a very big patch so late in the -rc cycle. Is there some
> > > patch that got merged in 4.0-rc1 that I should be reverting instead to
> > > fix things up?
> >
> > Make that, "this is a very large patch set", not just one patch. I can't take all
> > of these this late, sorry. Please just tell me what to revert.
>
> Greg,
>
> Would it be possible to pick up two patches. I could prune this down to two. The two I want you to
> pick up are (in the order of importance):
>
> [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element
> [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure
>
> If you could pickup an additional patch that would be:
>
> [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal()
>
> The first one is the most important one and if you can only pickup one, the first one is the one I want you to pick up.
You aren't answering my question, what happened that caused these to
become an error and break the 4.0-rc tree? Shouldn't I just revert a
recent change here? Or has things always been broken and no one has
noticed it before?
I need a lot more information here please.
Oh, and also, please wrap your email lines :)
> The third one fixes a memory leak issue that occurs only under
> certain conditions.
You need to describe those "certian conditions" better.
> We may have to revert more patches than applying the two patches that
> would fix the most important issues.
I can easly revert everything recently applied, which is much safer than
adding more patches on top of things. In fact, I prefer to do that, so
what git commit ids should I revert?
thanks,
greg k-h
next prev parent reply other threads:[~2015-03-12 13:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 1:55 [PATCH 0/6] drivers: hv: vmbus: Some miscellaneous fixes for Linux 4.0 K. Y. Srinivasan
2015-03-12 1:56 ` [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element K. Y. Srinivasan
2015-03-12 1:56 ` [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure K. Y. Srinivasan
2015-03-12 10:45 ` Olaf Hering
2015-03-12 10:53 ` Vitaly Kuznetsov
2015-03-12 11:14 ` Olaf Hering
2015-03-12 11:41 ` Dan Carpenter
2015-03-12 12:44 ` KY Srinivasan
2015-03-12 1:56 ` [PATCH 3/6] Drivers: hv: hv_balloon: don't lose memory when onlining order is not natural K. Y. Srinivasan
2015-03-12 1:56 ` [PATCH 4/6] Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY K. Y. Srinivasan
2015-03-12 1:56 ` [PATCH 5/6] tools: hv: fcopy_daemon: support >2GB files for x86_32 guest K. Y. Srinivasan
2015-03-12 1:56 ` [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal() K. Y. Srinivasan
2015-03-12 9:02 ` [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element Greg KH
2015-03-12 9:03 ` Greg KH
2015-03-12 13:12 ` KY Srinivasan
2015-03-12 13:28 ` Greg KH [this message]
2015-03-12 14:16 ` KY Srinivasan
2015-03-16 20:22 ` Greg KH
2015-03-16 21:09 ` KY Srinivasan
2015-03-17 4:50 ` KY Srinivasan
2015-03-12 10:44 ` Olaf Hering
2015-03-12 14:28 ` KY Srinivasan
2015-03-12 16:09 ` KY Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150312132837.GA31417@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=apw@canonical.com \
--cc=devel@linuxdriverproject.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf@aepfle.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.