Re: Clang backports for 4.9 and 4.4

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Nov 19, 2018 at 03:13:47PM -0800, Nick Desaulniers wrote:
> On Mon, Nov 19, 2018 at 11:21 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Mon, Nov 19, 2018 at 11:17:15AM -0800, Nick Desaulniers wrote:
> > > On Mon, Nov 19, 2018 at 10:52 AM Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > On Mon, Nov 19, 2018 at 10:31:35AM -0800, Nick Desaulniers wrote:
> > > > > Greg,
> > > > > I'm in the process of preparing backports for building 4.9 and 4.4
> > > > > kernels with Clang.  Going off of mka's very helpful:
> > > > > https://lkml.org/lkml/2017/11/22/943, I've prepared the list of SHA's
> > > > > that were marked UPSTREAM (internal convention used to denote patch
> > > > > applies cleanly):
> > > > > https://gist.github.com/nickdesaulniers/fe995f4b7c52af8de1a283c0a53562d9.
> > > > > But it seems that some of these shas no longer apply cleanly.  I was
> > > > > thus curious:
> > > > >
> > > > > 1. May I send you a pull request with the patches properly backported?
> > > > > I'm happy to do the work, just want a green light before backporting
> > > > > all of these patches.
> > > > > 2. Should I denote in any way if I had to modify any patch to get it
> > > > > to apply cleanly?  This helps in code review, IMO.  If so, what
> > > > > convention should I use?
> 
> Greg,
> Would you please cherry pick the following 26 patches from mainline to
> 4.9.y stable branch? (applied top to bottom)
> 
> I verified that they cherry-pick cleanly, and boot on x86_64 and
> arm64.  I will follow up with more patches cleaning up the warnings,
> adding arm 32b support, and the backport patches themselves when they
> do not cherry pick cleanly.
> https://travis-ci.com/nickdesaulniers/continuous-integration/builds/91934518
> 
> 785f11aa595bc3d4e74096cbd598ada54ecc0d81
> a37c45cd82e62a361706b9688a984a3a63957321
> ebf003f0cfb3705e60d40dedc3ec949176c741af
> 7dd47b95b0f54f2057d40af6e66d477e3fe95d13
> cf0c3e68aa81f992b0301f62e341b710d385bf68
> 
> a0ae981eba8f07dbc74bce38fd3a462b69a5bc8e
> c3f0d0bc5b01ad90c45276952802455750444b4f
> 6748cb3c299de1ffbe56733647b01dbcc398c419
> 433db3e260bc8134d4a46ddf20b3668937e12556
> 1f318a8bafcfba9f0d623f4870c4e890fd22e659
> 
> 2c4fd1ac3ff167c91272dc43c7bfd2269ef61557
> fdb2726f4e61c5e3abc052f547d5a5f6c0dc5504
> 9f3f1fd299768782465cb32cdf0dd4528d11f26b
> 032a2c4f65a2f81c93e161a11197ba19bc14a909
> d77698df39a512911586834d303275ea5fda74d0
> 
> bfb38988c51e440fd7062ddf3157f7d8b1dd5d70
> f4857f4c2ee9aa4e2aacac1a845352b00197fb57
> 18d5e6c34a8eda438d5ad8b3b15f42dab01bf05d
> 760b61d76da6d6a99eb245ab61abf71ca5415cea
> 0426a4e68f18d75515414361de9e3e1445d2644e
> 
> 696204faa6e8a318320ebb49d9fa69bc8275644d
> 91ee5b21ee026c49e4e7483de69b55b8b47042be
> 8f91869766c00622b2eaa8ee567db4f333b78c1a
> 9e8730b178a2472fca3123e909d6e69cc8127778
> 8c97023cf0518f172b8cb7a9fffc28b89401abbf
> 
> d135b8b5060ea91dd751ff172d179eb4eab1e966

Ok, while I did say having a list of git commit ids was ok, I didn't
realize it was going to be this long :)

If you do have a tested set of patches like this already in your tree, I
would be more than willing to take a git pull request or a mbox of them
all, and apply them that way.

As for the format of them, look at how David Miller sends networking
mbox files, with the "upstream commit" line as the first line of the
patch, so that we know where the patch came from.

Also, it gives me a better way to review them and see if these really
are sane enough for the stable tree.

For 4.9 I can sort of understand the request, but for 4.4, that is
really old now, and no one should be making new devices with that kernel
release (same for 4.9, but yeah, I know...)  So I doubt anyone cares
about clang backports for 4.4 which is why I only accepted a few tiny
patches for that in the past into that tree.

thanks,

greg k-h