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.
- '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.
Let's hope the lessons learnt here actually prove useful.