On Thu, Mar 12, 2015 at 02:16:23PM +0000, KY Srinivasan wrote: > > > > -----Original Message----- > > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > > Sent: Thursday, March 12, 2015 6:29 AM > > To: KY Srinivasan > > Cc: apw@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; > > linux-kernel@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the > > per-channel work element > > > > On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote: > > > > > > > > > > -----Original Message----- > > > > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > > > > Sent: Thursday, March 12, 2015 2:03 AM > > > > To: KY Srinivasan > > > > Cc: linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; > > > > olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; vkuznets@xxxxxxxxxx > > > > 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > > > > > > --- > > > > > > 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? > > commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7 > > introduced the bug (committed on Feb 28th). This patch cleaned up > the rescind handling code. > > The patches I sent a few days later: > > Drivers: hv: vmbus: Perform device register in the > per-channel work element fixed it. > > Drivers: hv: vmbus: Fix a bug in rescind processing in > vmbus_close_internal() > > Fixed the bugs. Ok, commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7 is on my char-misc-next branch, and has nothing to do with 4.0-final. So why do you think anything needs to be done for 4.0? Please take a look at my tree, at Linus's tree, and figure out exactly what needs to be fixed where, and resend me patches that explicitly says which branch for me to apply them to (char-linus for patches that need to go for 4.0-final, char-next for patches that need to go into 4.1-rc1.) I'm again dropping all of your pending patches in my to-apply queue, as it's all just too confusing here and no one seems to know what is going on (myself included.) thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
