* Clang backports for 4.9 and 4.4 @ 2018-11-19 18:31 Nick Desaulniers 2018-11-19 18:52 ` Nathan Chancellor 0 siblings, 1 reply; 13+ messages in thread From: Nick Desaulniers @ 2018-11-19 18:31 UTC (permalink / raw) To: Greg KH; +Cc: stable, Sandeep Patil, Matthias Kaehlcke, Nathan Chancellor 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? -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-19 18:31 Clang backports for 4.9 and 4.4 Nick Desaulniers @ 2018-11-19 18:52 ` Nathan Chancellor 2018-11-19 19:17 ` Nick Desaulniers 0 siblings, 1 reply; 13+ messages in thread From: Nathan Chancellor @ 2018-11-19 18:52 UTC (permalink / raw) To: Nick Desaulniers; +Cc: Greg KH, stable, Sandeep Patil, Matthias Kaehlcke 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? I usually add my initials with a small note for anything non-trivial like: https://github.com/nathanchance/continuous-integration/blob/sandbox/patches/4.4/arm64/0015-kbuild-fix-linker-feature-test-macros-when-cross-com.patch I meant to post this on GitHub earlier but was wiped out from work. I did a successful backport for arm64 on top of 4.4.163 a couple of days ago that is based on the work Matthias did with some of the newer fixes that have cropped up. Hopefully it is of some use :) https://github.com/nathanchance/continuous-integration/tree/sandbox/patches/4.4/arm64 https://travis-ci.com/nathanchance/continuous-integration/jobs/159318688 Thanks! Nathan > > -- > Thanks, > ~Nick Desaulniers ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-19 18:52 ` Nathan Chancellor @ 2018-11-19 19:17 ` Nick Desaulniers 2018-11-19 19:20 ` Nathan Chancellor 0 siblings, 1 reply; 13+ messages in thread From: Nick Desaulniers @ 2018-11-19 19:17 UTC (permalink / raw) To: Nathan Chancellor; +Cc: Greg KH, stable, Sandeep Patil, Matthias Kaehlcke 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? > > I usually add my initials with a small note for anything non-trivial > like: https://github.com/nathanchance/continuous-integration/blob/sandbox/patches/4.4/arm64/0015-kbuild-fix-linker-feature-test-macros-when-cross-com.patch Got it, thanks! > > I meant to post this on GitHub earlier but was wiped out from work. I > did a successful backport for arm64 on top of 4.4.163 a couple of days > ago that is based on the work Matthias did with some of the newer fixes > that have cropped up. Hopefully it is of some use :) Great! Let's keep this series, and wait to hear back from GKH how he wants the patches (your set looks like it's easily mailed if Greg does not want a PR). I'll start working on one for 4.9 only then. Also, it would be good to add patches for x86_64. > > https://github.com/nathanchance/continuous-integration/tree/sandbox/patches/4.4/arm64 > https://travis-ci.com/nathanchance/continuous-integration/jobs/159318688 Just a side note: I think this is an awesome side effect of our CI setup. "Here's a hyperlink to a log that shows that this builds AND boots in qemu." -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-19 19:17 ` Nick Desaulniers @ 2018-11-19 19:20 ` Nathan Chancellor 2018-11-19 23:13 ` Nick Desaulniers 0 siblings, 1 reply; 13+ messages in thread From: Nathan Chancellor @ 2018-11-19 19:20 UTC (permalink / raw) To: Nick Desaulniers; +Cc: Greg KH, stable, Sandeep Patil, Matthias Kaehlcke 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? > > > > I usually add my initials with a small note for anything non-trivial > > like: https://github.com/nathanchance/continuous-integration/blob/sandbox/patches/4.4/arm64/0015-kbuild-fix-linker-feature-test-macros-when-cross-com.patch > > Got it, thanks! > > > > > I meant to post this on GitHub earlier but was wiped out from work. I > > did a successful backport for arm64 on top of 4.4.163 a couple of days > > ago that is based on the work Matthias did with some of the newer fixes > > that have cropped up. Hopefully it is of some use :) > > Great! Let's keep this series, and wait to hear back from GKH how he > wants the patches (your set looks like it's easily mailed if Greg does > not want a PR). I'll start working on one for 4.9 only then. Also, > it would be good to add patches for x86_64. > Yes, I will work on x86_64 now. > > > > https://github.com/nathanchance/continuous-integration/tree/sandbox/patches/4.4/arm64 > > https://travis-ci.com/nathanchance/continuous-integration/jobs/159318688 > > Just a side note: I think this is an awesome side effect of our CI > setup. "Here's a hyperlink to a log that shows that this builds AND > boots in qemu." > Very much so! Thanks, Nathan > -- > Thanks, > ~Nick Desaulniers ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-19 19:20 ` Nathan Chancellor @ 2018-11-19 23:13 ` Nick Desaulniers 2018-11-20 7:48 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Nick Desaulniers @ 2018-11-19 23:13 UTC (permalink / raw) To: Greg KH Cc: stable, Sandeep Patil, Matthias Kaehlcke, Nathan Chancellor, Alistair Strachan 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 -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-19 23:13 ` Nick Desaulniers @ 2018-11-20 7:48 ` Greg KH 2018-11-20 11:26 ` Nathan Chancellor 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2018-11-20 7:48 UTC (permalink / raw) To: Nick Desaulniers Cc: stable, Sandeep Patil, Matthias Kaehlcke, Nathan Chancellor, Alistair Strachan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-20 7:48 ` Greg KH @ 2018-11-20 11:26 ` Nathan Chancellor 2018-11-20 12:07 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Nathan Chancellor @ 2018-11-20 11:26 UTC (permalink / raw) To: Greg KH Cc: Nick Desaulniers, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan [-- Attachment #1: Type: text/plain, Size: 4702 bytes --] On Tue, Nov 20, 2018 at 08:48:07AM +0100, Greg KH wrote: > 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 Hi Greg, While the number of commits seems rather high, all together they are a rather small set of changes. It's mostly just shuffling around and extending what is already there. Here is an mbox file with all of the patches properly backported with their respective commit IDs if you would like to do a quick review (and I think I did this right...). We have verified that it allows both an arm64 and an x86_64 kernel to boot in QEMU with Clang. https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683234 https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683235 Thanks! Nathan [-- Attachment #2: clang-patches-4.4.mbox --] [-- Type: application/mbox, Size: 85420 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-20 11:26 ` Nathan Chancellor @ 2018-11-20 12:07 ` Greg KH 2018-11-20 16:46 ` Nathan Chancellor 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2018-11-20 12:07 UTC (permalink / raw) To: Nathan Chancellor Cc: Nick Desaulniers, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan On Tue, Nov 20, 2018 at 04:26:24AM -0700, Nathan Chancellor wrote: > On Tue, Nov 20, 2018 at 08:48:07AM +0100, Greg KH wrote: > > 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 > > Hi Greg, > > While the number of commits seems rather high, all together they are a > rather small set of changes. It's mostly just shuffling around and > extending what is already there. > > Here is an mbox file with all of the patches properly backported with > their respective commit IDs if you would like to do a quick review (and > I think I did this right...). We have verified that it allows both an > arm64 and an x86_64 kernel to boot in QEMU with Clang. > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683234 > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683235 Your git list above says "4.9", but the mbox says "4.4", so I'm confused. Which tree is this mbox for? thanks, greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-20 12:07 ` Greg KH @ 2018-11-20 16:46 ` Nathan Chancellor 2018-11-20 16:52 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Nathan Chancellor @ 2018-11-20 16:46 UTC (permalink / raw) To: Greg KH Cc: Nick Desaulniers, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan On Tue, Nov 20, 2018 at 01:07:25PM +0100, Greg KH wrote: > On Tue, Nov 20, 2018 at 04:26:24AM -0700, Nathan Chancellor wrote: > > On Tue, Nov 20, 2018 at 08:48:07AM +0100, Greg KH wrote: > > > 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 > > > > Hi Greg, > > > > While the number of commits seems rather high, all together they are a > > rather small set of changes. It's mostly just shuffling around and > > extending what is already there. > > > > Here is an mbox file with all of the patches properly backported with > > their respective commit IDs if you would like to do a quick review (and > > I think I did this right...). We have verified that it allows both an > > arm64 and an x86_64 kernel to boot in QEMU with Clang. > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683234 > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683235 > > Your git list above says "4.9", but the mbox says "4.4", so I'm > confused. Which tree is this mbox for? > > thanks, > > greg k-h Sorry, I should have been clearer. Earlier in the thread, I stated that I did the backports for 4.4 and Nick was going to do them for 4.9. The patches are sitting in our continuous integration repo but I don't want to step on his toes so I'll let him send them. I sent mine out since it would be a similar set of changes and wanted to show that even for 4.4, it's not a super intrusive set of changes and the work has already been done. They should apply cleanly on top of 4.4.163. Thanks, Nathan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-20 16:46 ` Nathan Chancellor @ 2018-11-20 16:52 ` Greg KH 2018-11-20 17:30 ` Nick Desaulniers 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2018-11-20 16:52 UTC (permalink / raw) To: Nathan Chancellor Cc: Nick Desaulniers, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan On Tue, Nov 20, 2018 at 09:46:01AM -0700, Nathan Chancellor wrote: > On Tue, Nov 20, 2018 at 01:07:25PM +0100, Greg KH wrote: > > On Tue, Nov 20, 2018 at 04:26:24AM -0700, Nathan Chancellor wrote: > > > On Tue, Nov 20, 2018 at 08:48:07AM +0100, Greg KH wrote: > > > > 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 > > > > > > Hi Greg, > > > > > > While the number of commits seems rather high, all together they are a > > > rather small set of changes. It's mostly just shuffling around and > > > extending what is already there. > > > > > > Here is an mbox file with all of the patches properly backported with > > > their respective commit IDs if you would like to do a quick review (and > > > I think I did this right...). We have verified that it allows both an > > > arm64 and an x86_64 kernel to boot in QEMU with Clang. > > > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683234 > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683235 > > > > Your git list above says "4.9", but the mbox says "4.4", so I'm > > confused. Which tree is this mbox for? > > > > thanks, > > > > greg k-h > > Sorry, I should have been clearer. Earlier in the thread, I stated that > I did the backports for 4.4 and Nick was going to do them for 4.9. The > patches are sitting in our continuous integration repo but I don't want > to step on his toes so I'll let him send them. I sent mine out since it > would be a similar set of changes and wanted to show that even for 4.4, > it's not a super intrusive set of changes and the work has already been > done. They should apply cleanly on top of 4.4.163. Ok, they look sane. But I need the 4.9 patch set "first", as I don't want anyone to move from 4.4 to 4.9 or newer and have breakages. And the patch format all looks great as well, I can consume this directly, thank you so much for this. I'll wait for the 4.9 series before queueing them up. thanks, greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-20 16:52 ` Greg KH @ 2018-11-20 17:30 ` Nick Desaulniers 2018-11-21 18:19 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Nick Desaulniers @ 2018-11-20 17:30 UTC (permalink / raw) To: Greg KH Cc: Nathan Chancellor, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan [-- Attachment #1: Type: text/plain, Size: 6879 bytes --] 4.9 mbox series attached. Thanks Greg! On Tue, Nov 20, 2018 at 8:52 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Nov 20, 2018 at 09:46:01AM -0700, Nathan Chancellor wrote: > > On Tue, Nov 20, 2018 at 01:07:25PM +0100, Greg KH wrote: > > > On Tue, Nov 20, 2018 at 04:26:24AM -0700, Nathan Chancellor wrote: > > > > On Tue, Nov 20, 2018 at 08:48:07AM +0100, Greg KH wrote: > > > > > 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 > > > > > > > > Hi Greg, > > > > > > > > While the number of commits seems rather high, all together they are a > > > > rather small set of changes. It's mostly just shuffling around and > > > > extending what is already there. > > > > > > > > Here is an mbox file with all of the patches properly backported with > > > > their respective commit IDs if you would like to do a quick review (and > > > > I think I did this right...). We have verified that it allows both an > > > > arm64 and an x86_64 kernel to boot in QEMU with Clang. > > > > > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683234 > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/159683235 > > > > > > Your git list above says "4.9", but the mbox says "4.4", so I'm > > > confused. Which tree is this mbox for? > > > > > > thanks, > > > > > > greg k-h > > > > Sorry, I should have been clearer. Earlier in the thread, I stated that > > I did the backports for 4.4 and Nick was going to do them for 4.9. The > > patches are sitting in our continuous integration repo but I don't want > > to step on his toes so I'll let him send them. I sent mine out since it > > would be a similar set of changes and wanted to show that even for 4.4, > > it's not a super intrusive set of changes and the work has already been > > done. They should apply cleanly on top of 4.4.163. > > Ok, they look sane. But I need the 4.9 patch set "first", as I don't > want anyone to move from 4.4 to 4.9 or newer and have breakages. > > And the patch format all looks great as well, I can consume this > directly, thank you so much for this. I'll wait for the 4.9 series > before queueing them up. > > thanks, > > greg k-h -- Thanks, ~Nick Desaulniers [-- Attachment #2: clang-patches-4.9.mbox --] [-- Type: application/mbox, Size: 71535 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-20 17:30 ` Nick Desaulniers @ 2018-11-21 18:19 ` Greg KH 2018-11-21 18:38 ` Nick Desaulniers 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2018-11-21 18:19 UTC (permalink / raw) To: Nick Desaulniers Cc: Nathan Chancellor, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan On Tue, Nov 20, 2018 at 09:30:45AM -0800, Nick Desaulniers wrote: > 4.9 mbox series attached. Thanks Greg! All 4.4 and 4.9 patches now queued up, thanks! greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Clang backports for 4.9 and 4.4 2018-11-21 18:19 ` Greg KH @ 2018-11-21 18:38 ` Nick Desaulniers 0 siblings, 0 replies; 13+ messages in thread From: Nick Desaulniers @ 2018-11-21 18:38 UTC (permalink / raw) To: Greg KH Cc: Nathan Chancellor, stable, Sandeep Patil, Matthias Kaehlcke, Alistair Strachan On Wed, Nov 21, 2018 at 10:19 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Nov 20, 2018 at 09:30:45AM -0800, Nick Desaulniers wrote: > > 4.9 mbox series attached. Thanks Greg! > > All 4.4 and 4.9 patches now queued up, thanks! Thank you Greg and Nathan (and the many folks that wrote these patches). There should be a few more; things we manually backport, arm32 support, and probably a bunch of warning fixes, but these can wait until after the (US) holidays (Thanksgiving). I plan to triple check that Nathan and my patch sets are equivalent. -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-11-22 5:14 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-19 18:31 Clang backports for 4.9 and 4.4 Nick Desaulniers 2018-11-19 18:52 ` Nathan Chancellor 2018-11-19 19:17 ` Nick Desaulniers 2018-11-19 19:20 ` Nathan Chancellor 2018-11-19 23:13 ` Nick Desaulniers 2018-11-20 7:48 ` Greg KH 2018-11-20 11:26 ` Nathan Chancellor 2018-11-20 12:07 ` Greg KH 2018-11-20 16:46 ` Nathan Chancellor 2018-11-20 16:52 ` Greg KH 2018-11-20 17:30 ` Nick Desaulniers 2018-11-21 18:19 ` Greg KH 2018-11-21 18:38 ` Nick Desaulniers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).