Re: [GIT PULL] commits for Linux 3.18

[Sasha Levin <Alexander.Levin@microsoft.com>]

On Wed, Jun 06, 2018 at 12:24:32AM +0530, Harsh Shandilya wrote:
>On 6 June 2018 12:16:24 AM IST, Sasha Levin <Alexander.Levin@microsoft.com> wrote:
>>On Tue, Jun 05, 2018 at 02:39:33PM +0530, Harsh Shandilya wrote:
>>>On 5 June 2018 1:00:54 PM IST, Sasha Levin
>><Alexander.Levin@microsoft.com> wrote:
>>>>On Tue, Jun 05, 2018 at 12:12:10PM +0530, Harsh Shandilya wrote:
>>>>>On 5 June 2018 9:30:44 AM IST, Sasha Levin
>>>><Alexander.Levin@microsoft.com> wrote:
>>>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>>>>Hash: SHA512
>>>>>>
>>>>>>Hi Greg,
>>>>>>
>>>>>>Pleae pull commits for Linux 3.18 .
>>>>>>
>>>>>>I've sent a review request for all commits over a week ago and all
>>>>>>comments were addressed.
>>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>Sasha
>>>>>>
>>>>>>=====
>>>>>>
>>>>>>
>>>>>>The following changes since commit
>>>>>>8eb1ef076bab4bd4975922a06bdffa3d40c4197c:
>>>>>>
>>>>>>  Linux 3.18.111 (2018-05-30 07:47:45 +0200)
>>>>>>
>>>>>>are available in the Git repository at:
>>>>>>
>>>>>>git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git
>>>>>>tags/for-greg-3.18-04062018
>>>>>
>>>>>Vanilla arm64 build fails with
>>>>>
>>>>>../arch/arm64/kernel/ptrace.c:27:10: fatal error: linux/nospec.h: No
>>>>such file or directory
>>>>> #include <linux/nospec.h>
>>>>>          ^~~~~~~~~~~~~~~~
>>>>>compilation terminated.
>>>>>make[2]: *** [../scripts/Makefile.build:257:
>>>>arch/arm64/kernel/ptrace.o] Error 1
>>>>>make[1]: *** [/home/msfjarvis/oneplus3/Makefile:947:
>>>>arch/arm64/kernel] Error 2
>>>>>make[1]: *** Waiting for unfinished jobs....
>>>>>
>>>>>Caused by the backport of Upstream commit
>>>>19791a7ca674fb3009bb068260e852a2f05b605c ("arm64: fix possible
>>>>spectre-v1 in ptrace_hbp_get_event()").
>>>>
>>>>Thanks Harsh.
>>>>
>>>>I don't understand why my built bot skipped this.
>>>
>>>On the last PR (or the one before?) there was also a compile time
>>warning introduced on all architectures using the net subsystem so
>>clearly something's very wrong with the buildbot and fixing the issue
>>should probably be prioritised to avoid further incidents like this.
>>
>>Okay, two lessons learned on my end:
>>
>>1. Pushing a branch/tag to git.kernel.org does not make it immediately
>>available for pulling on a different host, so if I have a script that
>>does something like this:
>>
>>	git push -f sasha-stable my-stable-branch
>>	ssh buildbox git fetch sasha-stable
>>
>>then an updated "my-stable-branch" not appear immediately. There's some
>>sort of a delay on git.kernel.org.
>
>I can confirm this in the same scenario, I saw the pull request email and went to run a merge test and kernel.org kept saying there were no updates for a good minute before the tags showed up.

What happened in my case is that it proceeded with building the previous
version, which had no errors :)

>>2. 'git fetch' might not necessarily update tags (I don't quite
>>understand the logic), I should have used 'git fetch --tags' instead.
>
>'git fetch' never updates tags as per design AFAIK, but 'git remote update' does.

But it did for me, which is why I was puzzled. Doing a simple git fetch
earlier I got:

$ git fetch --all
Fetching origin
Fetching stable
Fetching sstable
remote: Counting objects: 1898, done.
remote: Compressing objects: 100% (735/735), done.
remote: Total 1898 (delta 1581), reused 1472 (delta 1160)
Receiving objects: 100% (1898/1898), 331.02 KiB | 10.68 MiB/s, done.
Resolving deltas: 100% (1581/1581), completed with 521 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable
 * [new tag]                   for-greg-4.14-05062018 -> for-greg-4.14-05062018
 * [new tag]                   for-greg-4.16-05062018 -> for-greg-4.16-05062018
 * [new tag]                   for-greg-4.4-05062018  -> for-greg-4.4-05062018
 * [new tag]                   for-greg-4.9-05062018  -> for-greg-4.9-05062018

But then when I added "--tags" it fetch a lot more tags, and actually
updated a tag too:

$ git fetch --tags --all
Fetching origin
Fetching stable
Fetching sstable
remote: Counting objects: 38176, done.
remote: Compressing objects: 100% (9185/9185), done.
remote: Total 38176 (delta 33775), reused 32396 (delta 28948)
Receiving objects: 100% (38176/38176), 7.64 MiB | 22.04 MiB/s, done.
Resolving deltas: 100% (33775/33775), completed with 3782 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable
 * [new tag]                   for-greg-3.18-02122017 -> for-greg-3.18-02122017
 * [new tag]                   for-greg-3.18-04022018 -> for-greg-3.18-04022018
 * [new tag]                   for-greg-3.18-04052018 -> for-greg-3.18-04052018
 * [new tag]                   for-greg-3.18-05062018 -> for-greg-3.18-05062018
 * [new tag]                   for-greg-3.18-11122017 -> for-greg-3.18-11122017
 * [new tag]                   for-greg-3.18-14122017 -> for-greg-3.18-14122017
 * [new tag]                   for-greg-3.18-15042018 -> for-greg-3.18-15042018
 * [new tag]                   for-greg-3.18-20122017 -> for-greg-3.18-20122017
 * [new tag]                   for-greg-3.18-23022018 -> for-greg-3.18-23022018
 * [new tag]                   for-greg-3.18-26042018 -> for-greg-3.18-26042018
 * [new tag]                   for-greg-3.18-28012018 -> for-greg-3.18-28012018
 * [new tag]                   for-greg-4.14-02122017 -> for-greg-4.14-02122017
 * [new tag]                   for-greg-4.14-04022018 -> for-greg-4.14-04022018
 * [new tag]                   for-greg-4.14-04052018 -> for-greg-4.14-04052018
 t [tag update]                for-greg-4.14-04062018 -> for-greg-4.14-04062018
 [...]

So I *thought* that git fetch was working right, but really it wasn't
the case.