On 6 June 2018 12:29:58 AM IST, Sasha Levin Alexander.Levin@microsoft.com 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@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:
- 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 :)
- '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.