linux-kernel - Re: [PATCH v3 0/5] Backport of patch series for stable 4.4 branch

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:   Tue, 5 Jan 2021 11:43:42 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     SeongJae Park <sjpark@...zon.com>
Cc:     stable@...r.kernel.org, SeongJae Park <sjpark@...zon.de>,
        doebel@...zon.de, aams@...zon.de, mku@...zon.de, jgross@...e.com,
        julien@....org, wipawel@...zon.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/5] Backport of patch series for stable 4.4 branch

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@...uxfoundation.org> wrote:
> 
> > On Thu, Dec 17, 2020 at 05:03:57PM +0100, SeongJae Park wrote:
> > > From: SeongJae Park <sjpark@...zon.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?

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

thanks,

greg k-h