On 6 June 2018 12:29:58 AM IST, Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx> wrote:
>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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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:
If you pay attention, the only tags fetched above were ones attached to a branch. Adding --tags pulls every tag despite the git hash for it not existing on any branch.
>$ 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.
It _was_ working fine, but the design is too weird to risk things like this by not being explicit with your options.
--
Harsh Shandilya, PRJKT Development LLC
