Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   SeongJae Park <sjpark@amazon.com>
To:     Greg KH <gregkh@linuxfoundation.org>
CC:     SeongJae Park <sjpark@amazon.com>, <stable@vger.kernel.org>,
        SeongJae Park <sjpark@amazon.de>, <doebel@amazon.de>,
        <aams@amazon.de>, <mku@amazon.de>, <jgross@suse.com>,
        <julien@xen.org>, <wipawel@amazon.de>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/5] Backport of patch series for stable 4.4 branch
Date:   Tue, 5 Jan 2021 11:51:07 +0100
Message-ID: <20210105105107.3564-1-sjpark@amazon.com>
In-Reply-To: <X/RC3ghc7u4uPIjT@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Tue, 5 Jan 2021 11:43:42 +0100 Greg KH <gregkh@linuxfoundation.org> wrote:

> On Tue, Jan 05, 2021 at 11:37:02AM +0100, SeongJae Park wrote:
> > Hi Greg,
> > 
> > On Mon, 28 Dec 2020 12:29:11 +0100 Greg KH <gregkh@linuxfoundation.org> wrote:
> > 
> > > On Thu, Dec 17, 2020 at 05:03:57PM +0100, SeongJae Park wrote:
> > > > From: SeongJae Park <sjpark@amazon.de>
> > > > 
> > > > Changes from v2
> > > > (https://lore.kernel.org/stable/20201217130501.12702-1-sjpark@amazon.com/)
> > > > - Move 'nr_pending' increase from 5th patch to 4th patch
> > > > 
> > > > Changes from v1
> > > > (https://lore.kernel.org/stable/20201217081727.8253-1-sjpark@amazon.com/)
> > > > - Remove wrong 'Signed-off-by' lines for 'Author Redacted'
> > > 
> > > All now queued up, but you also need a series of this for the 4.9.y tree
> > > as well.
> > 
> > Thank you for your efforts!
> > 
> > However, I was able to cherry-pick this series, which is already merged in
> > 4.4.y, to 4.9.y without conflicts.
> > 
> >     $ git checkout stable/linux-4.9.y -b xsa349_4.9
> >     $ git cherry-pick d8b0d52e408ca..3c71d2f637c8
> >     warning: inexact rename detection was skipped due to too many files.
> >     warning: you may want to set your merge.renamelimit variable to at least 6130 and retry the command.
> >     [xsa349_4.9 51b4cb3db28a] xen/xenbus: Allow watches discard events before queueing
> >      Date: Mon Dec 14 10:02:45 2020 +0100
> >      4 files changed, 16 insertions(+), 1 deletion(-)
> >     warning: inexact rename detection was skipped due to too many files.
> >     warning: you may want to set your merge.renamelimit variable to at least 6130 and retry the command.
> >     [xsa349_4.9 3242225d9645] xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path()
> >      Date: Mon Dec 14 10:04:18 2020 +0100
> >      6 files changed, 17 insertions(+), 7 deletions(-)
> >     warning: inexact rename detection was skipped due to too many files.
> >     warning: you may want to set your merge.renamelimit variable to at least 6130 and retry the command.
> >     [xsa349_4.9 10d6c1301412] xen/xenbus/xen_bus_type: Support will_handle watch callback
> >      Date: Mon Dec 14 10:05:47 2020 +0100
> >      2 files changed, 4 insertions(+), 1 deletion(-)
> >     warning: inexact rename detection was skipped due to too many files.
> >     warning: you may want to set your merge.renamelimit variable to at least 6130 and retry the command.
> >     [xsa349_4.9 3875703f1e6b] xen/xenbus: Count pending messages for each watch
> >      Date: Mon Dec 14 10:07:13 2020 +0100
> >      2 files changed, 21 insertions(+), 12 deletions(-)
> >     warning: inexact rename detection was skipped due to too many files.
> >     warning: you may want to set your merge.renamelimit variable to at least 6130 and retry the command.
> >     [xsa349_4.9 40e3b315cd18] xenbus/xenbus_backend: Disallow pending watch messages
> >      Date: Mon Dec 14 10:08:40 2020 +0100
> >      1 file changed, 7 insertions(+)
> > 
> > Seems you tried to merge the series for upstream in 4.9.y:
> > 
> >     https://lore.kernel.org/stable/1609154834239118@kroah.com/
> > 
> > This must because I didn't test this series with v4.9 and mention it.  Sorry
> > for making a confusion.  Could you please check this again?
> 
> I can't do anything with a set of git cherry-picks like above, can you
> please send the patches as a series so that I can apply them cleanly?

Sure, I will post it soon.

> 
> And I don't remember what happened with that failure, sorry, dealing
> with hundreds of patches a week makes them all blur together...

I understand.  No problem at all.


Thanks,
SeongJae Park