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