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] [day] [month] [year] [list]
Message-ID: <20190225175645.GA30288@kroah.com>
Date:   Mon, 25 Feb 2019 18:56:45 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Sasha Levin <sashal@...nel.org>, stable@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Nathan Chancellor <natechancellor@...il.com>
Subject: Re: Clang patches for 4.9

On Mon, Feb 25, 2019 at 09:46:56AM -0800, Nick Desaulniers wrote:
> On Mon, Feb 25, 2019 at 9:35 AM Nathan Chancellor
> <natechancellor@...il.com> wrote:
> >
> > On Mon, Feb 25, 2019 at 03:47:19PM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Feb 25, 2019 at 03:45:13PM +0100, Greg Kroah-Hartman wrote:
> > > > On Sun, Feb 24, 2019 at 11:13:01PM -0700, Nathan Chancellor wrote:
> > > > > Hi Greg and Sasha,
> > > > >
> > > > > Attached are three mbox files containing patches that bring the Clang
> > > > > backports that Nick did in 4.9.139 up to date with what is currently in
> > > > > 4.14 and mainline, as well as fix warnings that are present in the arm64
> > > > > and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of
> > > > > these warnings are fixed in 4.14 so there will be no regressions from
> > > > > upgrading.
> > > >
> > > > Really?  I see a number of these only showing up in much newer kernels.
> >
> > Sigh that's what I get for not double checking my email after adding
> > patches :(
> >
> > > > Specifically these patches:
> > > >   1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values")
> > > >   a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'")
> > > >   a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")
> > > >
> > > > from the "arm" mbox you provided.  Why shouldn't the above patches go
> > > > into 4.14.y and in some cases, also 4.19.y and 4.20.y?
> >
> > They should. All three pick cleanly to 4.14.y. Only the first one needs
> > to be taken into 4.19.y and 4.20.y.
> 
> I feel like I need a script that given a sha, tells me what LTS
> branches the patch is in or not.  I have this to tell me "when (what's
> the first tag that contains this commit)" a patch first landed:
> 
> function first_tag () {
>   tag=$1
>   git describe --contains "$tag" | sed 's/~.*//'
> }
> 
> So say a patch landed in 4.15-rc1; and I want to backport to 4.9 and
> 4.14 (but it's already been backported to 4.14).  Does anyone have a
> script to check this quickly?  The process for seeing which LTS
> contains a commit or not still is very manual.  I guess backports that
> require modification probably complicate the search further.  Just
> asking, in case this is already a solved problem.

Here's the script that I use that does just that:
	https://github.com/gregkh/gregkh-linux/blob/master/scripts/fix_in_what_release

It requires 3 things:
	- a directory of all kernel logs to search quickly to avoid 'git
	  log'.  I use the ones I keep at: https://github.com/gregkh/kernel-history/tree/master/logs
	- the stable queue git repo, to be able to search the stable
	  kernel trees quickly.
	- the latest git tree from Linus, to fall back to if the commit
	  isn't in any of the above places.

Hope that helps.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ