2018-01-28 22:20:03

by Linus Torvalds

[permalink] [raw]
Subject: Linux 4.15

After a release cycle that was unusual in so many (bad) ways, this
last week was really pleasant. Quiet and small, and no last-minute
panics, just small fixes for various issues. I never got a feeling
that I'd need to extend things by yet another week, and 4.15 looks
fine to me.

Half the changes in the last week were misc driver stuff (gpu, input,
networking) with the other half being a mix of networking, core kernel
and arch updates (mainly x86). But all of it is tiny.

So at least we had one good week. This obviously was not a pleasant
release cycle, with the whole meltdown/spectre thing coming in in the
middle of the cycle and not really gelling with our normal release
cycle. The extra two weeks were obviously mainly due to that whole
timing issue.

Also, it is worth pointing out that it's not like we're "done" with
spectre/meltdown. There is more work pending (arm, spectre-v1, misc
details), and perhaps equally importantly, to actually get the biggest
fix for the indirect branch mitigations, you need not just the kernel
updates, you need to have a compiler with support for the "retpoline"
indirect branch model.

You can do

cat /sys/devices/system/cpu/vulnerabilities/spectre_v2

and if you don't have a compiler that supports the retpoline
mitigations, you'll get:

Vulnerable: Minimal generic ASM retpoline

because only the assembly code (not the C code) will have the
retpoline mitigation. So keep that in mind.

Anyway, while spectre/meltdown has obviously been the big news this
release cycle, it's worth noting that we obviously had all the
*normal* updates going on too, and the work everywhere else didn't
just magically stop, even if some developers have been distracted by
CPU issues. In the *big* picture, 4.15 looks perfectly normal, with
two thirds of the full 4.15 patch being about drivers, and even the
arch updates are dominated by the arm DTS diffs, not by CPU bug
mitigation.

So the news cycle notwithstanding, the bulk of the 4.15 work is all
the regular plodding "boring" stuff. And I mean that in the best
possible way. It may not be glamorous and get the headlines, but it's
the bread and butter of kernel development, and is in many ways the
really important stuff.

Go forth and play with it, things actually look pretty good despite everything.

And obviously this also means that the merge window for 4.16 is open.
I already have a number of pull requests pending that I will start
merging tomorrow. Hopefully we'll have a _normal_ and entirely boring
release cycle for 4.16. Because boring really is good.

Linus

---

Aaron Ma (1):
Input: trackpoint - force 3 buttons if 0 button is reported

Alexey Kodanev (1):
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state

Andi Shyti (1):
Input: stmfts,s6sy671 - add SPDX identifier

Andy Lutomirski (2):
x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems
x86/mm/64: Tighten up vmalloc_fault() sanity checks on 5-level kernels

Aviad Yehezkel (1):
xfrm: fix error flow in case of add state fails

Ben Hutchings (2):
nfsd: auth: Fix gid sorting when rootsquash enabled
ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL

Boris Brezillon (1):
drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

Borislav Petkov (1):
x86/microcode: Fix again accessing initrd after having been freed

Christian Borntraeger (1):
KVM: s390: add proper locking for CMMA migration bitmap

Christian König (1):
x86/PCI: Enable AMD 64-bit window on resume

Corentin Labbe (1):
sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 =>
CONFIG_CRYPTO_CAMELLIA_SPARC64

Dan Streetman (1):
net: tcp: close sock if net namespace is exiting

Dave Watson (1):
tls: Correct length of scatterlist in tls_sw_sendpage

David Ahern (1):
net: vrf: Add support for sends to local broadcast address

Dmitry Torokhov (1):
Input: trackpoint - only expose supported controls for Elan, ALPS and NXP

Eric Anholt (1):
drm/vc4: Flush the caches before the bin jobs, as well.

Eric Dumazet (1):
net: qdisc_pkt_len_init() should be more robust

Felix Fietkau (1):
net: igmp: fix source address check for IGMPv3 reports

Francois Romieu (1):
r8169: fix memory corruption on retrieval of hardware statistics.

Greg Kroah-Hartman (1):
Revert "module: Add retpoline tag to VERMAGIC"

Guillaume Nault (1):
pppoe: take ->needed_headroom of lower device into account on xmit

Gustavo A. R. Silva (1):
xfrm: fix boolean assignment in xfrm_get_type_offload

H. Peter Anvin (1):
x86: Mark hpa as a "Designated Reviewer" for the time being

Ivan Mikhaylov (2):
net/ibm/emac: add 8192 rx/tx fifo size
net/ibm/emac: wrong bit is used for STA control register write

Ivan Vecera (1):
be2net: restore properly promisc mode after queues reconfiguration

Jakub Kicinski (1):
i40e: flower: check if TC offload is enabled on a netdev

James Morris (1):
MAINTAINERS: update email address for James Morris

Jason Wang (2):
vhost: use mutex_lock_nested() in vhost_dev_lock_vqs()
vhost: do not try to access device IOTLB when not initialized

Jia Zhang (1):
x86/microcode/intel: Extend BDW late-loading further with LLC size check

John Allen (3):
ibmvnic: Modify buffer size and number of queues on failover
ibmvnic: Revert to previous mtu when unsupported value requested
ibmvnic: Allocate and request vpd in init_resources

Josef Bacik (1):
Btrfs: fix stale entries in readdir

Josh Poimboeuf (2):
x86/ftrace: Fix ORC unwinding from ftrace handlers
x86/ftrace: Add one more ENDPROC annotation

Kirill A. Shutemov (2):
mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
mm, page_vma_mapped: Introduce pfn_in_hpage()

Kumar Sanghvi (2):
cxgb4: set filter type to 1 for ETH_P_IPV6
cxgb4: fix endianness for vlan value in cxgb4_tc_flower

Linus Torvalds (1):
Linux 4.15

Lyude Paul (1):
drm/nouveau: Move irq setup/teardown to pci ctor/dtor

Mark Furneaux (1):
Input: xpad - add support for PDP Xbox One controllers

Martin Brandenburg (3):
orangefs: use list_for_each_entry_safe in purge_waiting_ops
orangefs: initialize op on loop restart in orangefs_devreq_read
orangefs: fix deadlock; do not write i_size in read_iter

Michal Kalderon (2):
qed: Remove reserveration of dpi for kernel
qed: Free reserved MR tid

Neil Horman (1):
vmxnet3: repair memory leak

Nick Dyer (1):
Revert "Input: synaptics_rmi4 - use devm_device_add_group() for
attributes in F01"

Nicolas Dichtel (1):
net: don't call update_pmtu unconditionally

Oliver Neukum (1):
usbnet: silence an unnecessary warning

Palmer Dabbelt (1):
Update the RISC-V MAINTAINERS file

Peter Zijlstra (6):
futex: Fix OWNER_DEAD fixup
sched/core: Fix cpu.max vs. cpuhotplug deadlock
perf/core: Fix lock inversion between perf,trace,cpuhp
perf/core: Fix another perf,trace,cpuhp lock inversion
perf/core: Fix ctx::mutex deadlock
perf/x86: Fix perf,x86,cpuhp deadlock

Sowmini Varadhan (1):
rds: tcp: compute m_ack_seq as offset from ->write_seq

Stefan Hajnoczi (1):
VSOCK: set POLLOUT | POLLWRNORM for TCP_CLOSING

Steven Rostedt (VMware) (2):
ftrace, orc, x86: Handle ftrace dynamically allocated trampolines
tracing: Update stack trace skipping for ORC unwinder

Talat Batheesh (1):
net/mlx5e: Fix fixpoint divide exception in mlx5e_am_stats_compare

Tejun Heo (1):
locking/lockdep: Avoid triggering hardlockup from debug_show_all_locks()

Thomas Gleixner (1):
hrtimer: Reset hrtimer cpu base proper on CPU hotplug

Tom Herbert (2):
kcm: Only allow TCP sockets to be attached to a KCM mux
kcm: Check if sk_user_data already set in kcm_attach

Waiman Long (1):
x86/retpoline: Remove the esp/rsp thunk

Willem de Bruijn (1):
gso: validate gso_type in GSO handlers

Willy Tarreau (1):
MAINTAINERS: clarify that only verified bugs should be submitted
to security@

Wolfgang Bumiller (2):
net: sched: em_nbyte: don't add the data offset twice
net: sched: fix TCF_LAYER_LINK case in tcf_get_base_ptr

Xiao Liang (1):
perf/x86/amd/power: Do not load AMD power module on !AMD platforms

Yossi Kuperman (2):
xfrm: Add SA to hardware at the end of xfrm_state_construct()
xfrm: Fix eth_hdr(skb)->h_proto to reflect inner IP version

Yuval Mintz (1):
mlxsw: spectrum_router: Don't log an error on missing neighbor


2018-01-29 09:48:53

by Martin Steigerwald

[permalink] [raw]
Subject: Requirements for retpoline in Linux 4.15 (was: Re: Linux 4.15)

Hi Linus, hi everyone,

Linus Torvalds - 28.01.18, 22:52:
> details), and perhaps equally importantly, to actually get the biggest
> fix for the indirect branch mitigations, you need not just the kernel
> updates, you need to have a compiler with support for the "retpoline"
> indirect branch model.
>
> You can do
>
> cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
>
> and if you don't have a compiler that supports the retpoline
> mitigations, you'll get:
>
> Vulnerable: Minimal generic ASM retpoline
>
> because only the assembly code (not the C code) will have the
> retpoline mitigation. So keep that in mind.

I have:

% cat /proc/version
Linux version 4.15.0-tp520-btrfstrim+ ([…]) (gcc version 7.3.0 (Debian
7.3.0-1)) #38 SMP PREEMPT Mon Jan 29 09:38:44 CET 2018

% grep RETPO /boot/config-4.15.0-tp520-btrfstrim+
CONFIG_RETPOLINE=y

% gcc --version | head -1
gcc (Debian 7.3.0-1) 7.3.0

% apt changelog gcc-7
gcc-7 (7.3.0-1) unstable; urgency=medium

* GCC 7.3.0 release.
* Ignore bootstrap comparison failures in gcc/d on alpha. Addresses:
#888394.

-- Matthias Klose […] Thu, 25 Jan 2018 12:07:10 +0100


Yet:

% grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic
ASM retpoline


From what I read gcc 7.3 was supposed to include back ported retpoline
patches. What am I missing here?

Thanks,
--
Martin

2018-01-29 09:54:43

by David Woodhouse

[permalink] [raw]
Subject: Re: Requirements for retpoline in Linux 4.15 (was: Re: Linux 4.15)

On Mon, 2018-01-29 at 10:41 +0100, Martin Steigerwald wrote:
> From what I read gcc 7.3 was supposed to include back ported retpoline 
> patches. What am I missing here?

Which did you update first? Kernel source or GCC?

Try removing .cache.mk which has 'remembered' that your GCC doesn't
support retpoline.


Attachments:
smime.p7s (5.09 kB)

2018-01-29 10:43:34

by Martin Steigerwald

[permalink] [raw]
Subject: Re: Requirements for retpoline in Linux 4.15 (was: Re: Linux 4.15)

David Woodhouse - 29.01.18, 10:53:
> On Mon, 2018-01-29 at 10:41 +0100, Martin Steigerwald wrote:
> > From what I read gcc 7.3 was supposed to include back ported retpoline
> > patches. What am I missing here?
>
> Which did you update first? Kernel source or GCC?

Kernel source is existing git repo I just "git pull" from and I did not do any
"make clean" or "make-kpkg clean" on it before. And as it builds inside that
repo…

> Try removing .cache.mk which has 'remembered' that your GCC doesn't
> support retpoline.

I bet there have been "*.cache.mk" files around from previous pre gcc-7.3
compiles.

Trying again after

% find -name ".cache.mk" -delete

on kernel source tree.

Will report back.

Thanks,
--
Martin

2018-01-29 11:20:47

by Martin Steigerwald

[permalink] [raw]
Subject: Re: Requirements for retpoline in Linux 4.15 (was: Re: Linux 4.15)

Martin Steigerwald - 29.01.18, 11:42:
> > Try removing .cache.mk which has 'remembered' that your GCC doesn't
> > support retpoline.
>
> I bet there have been "*.cache.mk" files around from previous pre gcc-7.3
> compiles.
>
> Trying again after
>
> % find -name ".cache.mk" -delete
>
> on kernel source tree.
>
> Will report back.

The whole thing works:

% grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic
retpoline

I bet the virtualbox modules compiled by virtualbox-dkms will taint the
support, but I bet sooner or later they will support retpoline as well.
(Another reason to switch to KVM one day.)

Thank you.
--
Martin

2018-01-29 11:36:46

by David Woodhouse

[permalink] [raw]
Subject: Re: Requirements for retpoline in Linux 4.15 (was: Re: Linux 4.15)

On Mon, 2018-01-29 at 12:19 +0100, Martin Steigerwald wrote:
>
> The whole thing works:
>
> % grep . /sys/devices/system/cpu/vulnerabilities/*                                                       
> /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
> /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
> /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic 
> retpoline
>
> I bet the virtualbox modules compiled by virtualbox-dkms will taint the 
> support, but I bet sooner or later they will support retpoline as well. 
> (Another reason to switch to KVM one day.)

As long as those are actually compiled, it should be fine. Any C code
will be built with the correct CFLAGS.

If they have explicit asm which has indirect jumps, that would still be
a problem. We just need to port objtool into the kernel and do it at
module load time, to check for that... :)


Attachments:
smime.p7s (5.09 kB)

2018-01-30 03:44:10

by Josh Poimboeuf

[permalink] [raw]
Subject: Re: Requirements for retpoline in Linux 4.15 (was: Re: Linux 4.15)

On Mon, Jan 29, 2018 at 11:35:25AM +0000, David Woodhouse wrote:
> If they have explicit asm which has indirect jumps, that would still be
> a problem. We just need to port objtool into the kernel and do it at
> module load time, to check for that... :)

Darnit, you sniffed out my April Fool's plan.

--
Josh