From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:37622 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932458AbeD3T3I (ORCPT ); Mon, 30 Apr 2018 15:29:08 -0400 Date: Mon, 30 Apr 2018 12:26:59 -0700 From: Greg KH To: Sasha Levin Cc: "stable@vger.kernel.org" Subject: Re: [GIT PULL] commits for Linux 4.14 Message-ID: <20180430192659.GA31528@kroah.com> References: <20180430130219.GA10505@kroah.com> <20180430143928.GA226349@sasha-vm> <20180430150634.GA31520@kroah.com> <20180430175407.GA1544@sasha-vm> <20180430182844.GB21778@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180430182844.GB21778@kroah.com> Sender: stable-owner@vger.kernel.org List-ID: On Mon, Apr 30, 2018 at 11:28:44AM -0700, Greg KH wrote: > On Mon, Apr 30, 2018 at 05:54:08PM +0000, Sasha Levin wrote: > > On Mon, Apr 30, 2018 at 08:06:34AM -0700, Greg KH wrote: > > >On Mon, Apr 30, 2018 at 02:39:29PM +0000, Sasha Levin wrote: > > >> On Mon, Apr 30, 2018 at 06:02:19AM -0700, Greg KH wrote: > > >> >On Fri, Apr 27, 2018 at 02:00:53AM +0000, Sasha Levin wrote: > > >> >> Hi Greg, > > >> >> > > >> >> Pleae pull commits for Linux 4.14 . > > >> >> > > >> >> I've sent a review request for all commits over a week ago and all > > >> >> comments were addressed. > > >> >> > > >> >> > > >> >> Thanks, > > >> >> Sasha > > >> >> > > >> >> ===== > > >> >> > > >> >> > > >> >> The following changes since commit d6949f48093c2d862d9bc39a7a89f2825c55edc4: > > >> >> > > >> >> Linux 4.14.36 (2018-04-24 09:36:40 +0200) > > >> >> > > >> >> are available in the Git repository at: > > >> >> > > >> >> git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-26042018 > > >> > > > >> >Did you really regenerate this tree? It has a load of patches that are > > >> >already upstream. I'm getting a bunch of conflicts when first trying to > > >> >merge, and then rebase it. > > >> > > >> Yes, it was based on 4.14.36 which was released two days before I sent > > >> this pull request. > > >> > > >> >Can you verify this is the correct tag? > > >> > > >> The conflicts seem to happen because you're venturing into the > > >> non-stable-tagged land. Are you now looking at non-stable-tagged patches > > >> as well? > > >> > > >> See for example: > > >> > > >> commit 43de32cdf0f4f73519e2df12fb93adc24f9746cb > > >> Author: Andreas Kemnade > > >> Date: Tue Feb 20 07:30:10 2018 -0600 > > >> > > >> usb: musb: fix enumeration after resume > > >> > > >> If that's the case, we'll need to find a new way to sync up, otherwise > > >> this will keep happening. > > > > > >No, something went wrong here, as the other tags you sent me all look > > >fine. > > > > > >For example, let's look at the first commit in this tree: > > > > > >--------- > > >Date: Fri, 3 Nov 2017 20:28:57 +0900 > > >From: Hector Martin > > >Subject: [PATCH 001/755] firewire-ohci: work around oversized DMA reads on JMicron controllers > > > > > >[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ] > > >--------- > > > > > >It shows up here in this branch as commit > > >62080d9352e274275ccb090af366d339bbad08a7, yet, if you look in my tree, > > >it is really commit 4a5d70332d57bd473ffe76d8777a2e9f847c7863 > > > > > >So now I have duplicates in here, which is what I thought I said was > > >happening last time I pulled :( > > > > > >The other 4 requests were all fine, can you redo this one please? > > > > Oh I see, it looks like more commits from my branch were merged after > > the last time we had this talk, and I ended up with different commit IDs > > because I rebased the whole thing on a newer stable tag. > > > > I've pushed a fixed tag as: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-30042018 > > Much nicer, thanks for that. > > Let me go review these now... I'm going to push out what I have in my trees now for a round of stable updates, and then use these pull requests for the next one later this week. But I will queue them up either later today, or tomorrow, so we get a bit more time for review. thanks, greg k-h