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:
$ 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.