This is the start of the stable review cycle for the 5.1.9 release.
There are 70 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.1.9-rc1
Jiri Slaby <[email protected]>
TTY: serial_core, add ->install
Helen Koike <[email protected]>
drm/amd: fix fb references in async update
Tina Zhang <[email protected]>
drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack
Helen Koike <[email protected]>
drm: don't block fb changes for async plane updates
Jonathan Corbet <[email protected]>
drm/i915: Maintain consistent documentation subsection ordering
Weinan <[email protected]>
drm/i915/gvt: emit init breadcrumb for gvt request
Daniel Drake <[email protected]>
drm/i915/fbc: disable framebuffer compression on GeminiLake
Louis Li <[email protected]>
drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)
Harry Wentland <[email protected]>
drm/amd/display: Add ASICREV_IS_PICASSO
Alex Deucher <[email protected]>
drm/amdgpu/soc15: skip reset on init
Chris Wilson <[email protected]>
drm/i915: Fix I915_EXEC_RING_MASK
Aaron Liu <[email protected]>
drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in
Christian König <[email protected]>
drm/radeon: prefer lower reference dividers
Alex Deucher <[email protected]>
drm/amdgpu/psp: move psp version specific function pointers to early_init
Mario Kleiner <[email protected]>
drm: Fix timestamp docs for variable refresh properties.
Ryan Pavlik <[email protected]>
drm: add non-desktop quirks to Sensics and OSVR headsets.
Dave Airlie <[email protected]>
drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
Andres Rodriguez <[email protected]>
drm: add non-desktop quirk for Valve HMDs
Helen Koike <[email protected]>
drm/msm: fix fb references in async update
Patrik Jakobsson <[email protected]>
drm/gma500/cdv: Check vbt config bits when detecting lvds panels
Helen Koike <[email protected]>
drm/vc4: fix fb references in async update
Helen Koike <[email protected]>
drm/rockchip: fix fb references in async update
Dan Carpenter <[email protected]>
test_firmware: Use correct snprintf() limit
Dan Carpenter <[email protected]>
genwqe: Prevent an integer overflow in the ioctl
Paul Burton <[email protected]>
MIPS: pistachio: Build uImage.gz by default
Paul Burton <[email protected]>
MIPS: Bounds check virt_addr_valid
Roger Pau Monne <[email protected]>
xen-blkfront: switch kcalloc to kvcalloc for large array allocation
Sagi Grimberg <[email protected]>
nvme-rdma: fix queue mapping when queue count is limited
Gerald Schaefer <[email protected]>
s390/mm: fix address space detection in exception handling
Robert Hancock <[email protected]>
i2c: xiic: Add max_read_len quirk
Jann Horn <[email protected]>
x86/insn-eval: Fix use-after-free access to LDT entry
Jiri Kosina <[email protected]>
x86/power: Fix 'nosmt' vs hibernation triple fault during resume
Faiz Abbas <[email protected]>
mmc: sdhci_am654: Fix SLOTTYPE write
Takeshi Saito <[email protected]>
mmc: tmio: fix SCC error handling to avoid false positive CRC error
Dan Carpenter <[email protected]>
memstick: mspro_block: Fix an error code in mspro_block_issue_req()
Masahiro Yamada <[email protected]>
kbuild: use more portable 'command -v' for cc-cross-prefix
Kees Cook <[email protected]>
pstore/ram: Run without kernel crash dump region
Pi-Hsun Shih <[email protected]>
pstore: Set tfm to NULL on free_buf_for_compression
Miklos Szeredi <[email protected]>
fuse: fix copy_file_range() in the writeback case
Miklos Szeredi <[email protected]>
fuse: fallocate: fix return with locked inode
Yihao Wu <[email protected]>
NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled
Yihao Wu <[email protected]>
NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter
Trond Myklebust <[email protected]>
SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential
Olga Kornievskaia <[email protected]>
SUNRPC fix regression in umount of a secure mount
Helge Deller <[email protected]>
parisc: Fix crash due alternative coding for NP iopdir_fdc bit
John David Anglin <[email protected]>
parisc: Use implicit space register selection for loading the coherence index of I/O pdirs
Eugeniy Paltsev <[email protected]>
ARC: mm: SIGSEGV userspace trying to access kernel virtual memory
Jann Horn <[email protected]>
habanalabs: fix debugfs code
Linus Torvalds <[email protected]>
rcu: locking and unlocking need to always be at least barriers
Jakub Kicinski <[email protected]>
net/tls: replace the sleeping lock around RX resync with a bit lock
Erez Alfasi <[email protected]>
net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query
David Ahern <[email protected]>
ipmr_base: Do not reset index in mr_table_dump
Matteo Croce <[email protected]>
cls_matchall: avoid panic when receiving a packet before filter set
David Ahern <[email protected]>
neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit
David Ahern <[email protected]>
neighbor: Reset gc_entries counter if new entry is released before insert
Nikita Danilov <[email protected]>
net: aquantia: fix wol configuration not applied sometimes
Olivier Matz <[email protected]>
ipv6: fix EFAULT on sendto with icmpv6 and hdrincl
Olivier Matz <[email protected]>
ipv6: use READ_ONCE() for inet->hdrincl as in ipv4
Tim Beale <[email protected]>
udp: only choose unbound UDP socket for multicast when not in a VRF
Hangbin Liu <[email protected]>
Revert "fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied"
Paolo Abeni <[email protected]>
pktgen: do not sleep with the thread lock held.
Willem de Bruijn <[email protected]>
packet: unconditionally free po->rollover
Russell King <[email protected]>
net: sfp: read eeprom in maximum 16 byte increments
Zhu Yanjun <[email protected]>
net: rds: fix memory leak in rds_ib_flush_mr_pool
Maxime Chevallier <[email protected]>
net: mvpp2: Use strscpy to handle stat strings
Ivan Khoronzhuk <[email protected]>
net: ethernet: ti: cpsw_ethtool: fix ethtool ring param set
Xin Long <[email protected]>
ipv6: fix the check before getting the cookie in rt6_get_cookie
Xin Long <[email protected]>
ipv4: not do cache for local delivery if bc_forwarding is enabled
Neil Horman <[email protected]>
Fix memory leak in sctp_process_init
Vivien Didelot <[email protected]>
ethtool: fix potential userspace buffer overflow
-------------
Diffstat:
Makefile | 4 +-
arch/arc/mm/fault.c | 9 +-
arch/mips/mm/mmap.c | 5 ++
arch/mips/pistachio/Platform | 1 +
arch/parisc/kernel/alternative.c | 3 +-
arch/s390/mm/fault.c | 5 +-
arch/x86/lib/insn-eval.c | 47 +++++-----
arch/x86/power/cpu.c | 10 +++
arch/x86/power/hibernate.c | 33 ++++++++
drivers/block/xen-blkfront.c | 38 ++++-----
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 19 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 +-
drivers/gpu/drm/amd/amdgpu/soc15.c | 5 ++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-
drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 +-
drivers/gpu/drm/drm_atomic_helper.c | 22 ++---
drivers/gpu/drm/drm_connector.c | 6 --
drivers/gpu/drm/drm_edid.c | 25 ++++++
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +
drivers/gpu/drm/gma500/intel_bios.c | 3 +
drivers/gpu/drm/gma500/psb_drv.h | 1 +
drivers/gpu/drm/i915/gvt/gtt.c | 6 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 19 +++++
drivers/gpu/drm/i915/i915_reg.h | 6 +-
drivers/gpu/drm/i915/intel_fbc.c | 4 +
drivers/gpu/drm/i915/intel_workarounds.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +
drivers/gpu/drm/nouveau/Kconfig | 13 ++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +-
drivers/gpu/drm/radeon/radeon_display.c | 4 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51 +++++------
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 5 ++
drivers/memstick/core/mspro_block.c | 13 ++-
drivers/misc/genwqe/card_dev.c | 2 +
drivers/misc/genwqe/card_utils.c | 4 +
drivers/misc/habanalabs/debugfs.c | 60 ++++---------
drivers/mmc/host/sdhci_am654.c | 2 +-
drivers/mmc/host/tmio_mmc_core.c | 3 +-
.../aquantia/atlantic/hw_atl/hw_atl_utils.c | 14 +--
.../aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/port.c | 5 --
drivers/net/ethernet/ti/cpsw.c | 1 +
drivers/net/phy/sfp.c | 24 +++++-
drivers/nvme/host/rdma.c | 99 +++++++++++++---------
drivers/parisc/ccio-dma.c | 4 +-
drivers/parisc/sba_iommu.c | 3 +-
drivers/tty/serial/serial_core.c | 24 +++---
fs/fuse/file.c | 14 ++-
fs/nfs/nfs4proc.c | 32 +++----
fs/pstore/platform.c | 7 +-
fs/pstore/ram.c | 36 +++++---
include/drm/drm_modeset_helper_vtables.h | 8 ++
include/linux/cpu.h | 4 +
include/linux/rcupdate.h | 6 +-
include/net/ip6_fib.h | 3 +-
include/net/tls.h | 4 +
include/uapi/drm/i915_drm.h | 2 +-
kernel/cpu.c | 4 +-
kernel/power/hibernate.c | 9 ++
lib/test_firmware.c | 14 +--
net/core/ethtool.c | 5 +-
net/core/fib_rules.c | 6 +-
net/core/neighbour.c | 11 ++-
net/core/pktgen.c | 11 +++
net/ipv4/ipmr_base.c | 3 +-
net/ipv4/route.c | 22 ++---
net/ipv4/udp.c | 3 +-
net/ipv6/raw.c | 25 ++++--
net/packet/af_packet.c | 2 +-
net/rds/ib_rdma.c | 10 ++-
net/sched/cls_matchall.c | 3 +
net/sctp/sm_make_chunk.c | 13 +--
net/sctp/sm_sideeffect.c | 5 ++
net/sunrpc/clnt.c | 30 +++----
net/tls/tls_device.c | 27 ++++--
scripts/Kbuild.include | 7 +-
80 files changed, 612 insertions(+), 363 deletions(-)
From: Patrik Jakobsson <[email protected]>
commit 7c420636860a719049fae9403e2c87804f53bdde upstream.
Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Cc: [email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Patrik Jakobsson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
drivers/gpu/drm/gma500/intel_bios.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.h | 1 +
3 files changed, 7 insertions(+)
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_devi
int pipe;
u8 pin;
+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, &pin)) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_pri
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->edp.support = 1;
+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
/* This bit means to use 96Mhz for DPLL_A or not */
if (driver->primary_lfp_id)
dev_priv->dplla_96mhz = true;
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
int lvds_ssc_freq;
bool is_lvds_on;
bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
u32 mipi_ctrl_display;
unsigned int core_freq;
From: Daniel Drake <[email protected]>
commit 396dd8143bdd94bd1c358a228a631c8c895a1126 upstream.
On many (all?) the Gemini Lake systems we work with, there is frequent
momentary graphical corruption at the top of the screen, and it seems
that disabling framebuffer compression can avoid this.
The ticket was reported 6 months ago and has already affected a
multitude of users, without any real progress being made. So, lets
disable framebuffer compression on GeminiLake until a solution is found.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108085
Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too")
Cc: Paulo Zanoni <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: <[email protected]> # v4.11+
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Drake <[email protected]>
Signed-off-by: Jian-Hong Pan <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 1d25724b41fad7eeb2c3058a5c8190d6ece73e08)
Signed-off-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/intel_fbc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1278,6 +1278,10 @@ static int intel_sanitize_fbc_option(str
if (!HAS_FBC(dev_priv))
return 0;
+ /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
+ if (IS_GEMINILAKE(dev_priv))
+ return 0;
+
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
return 1;
From: Tina Zhang <[email protected]>
commit 387a4c2b55291b37e245c840813bd8a8bd06ed49 upstream.
Stack struct intel_gvt_gtt_entry value needs to be initialized before
being used, as the fields may contain garbage values.
W/o this patch, set_ggtt_entry prints:
-------------------------------------
274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900
274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001
274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900
0x9bed8000 is the stack grabage.
W/ this patch, set_ggtt_entry prints:
------------------------------------
274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900
274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001
274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900
v2:
- Initialize during declaration. (Zhenyu)
Fixes: 7598e8700e9a ("drm/i915/gvt: Missed to cancel dma map for ggtt entries")
Cc: [email protected] # v4.20+
Cc: Zhenyu Wang <[email protected]>
Reviewed-by: Zhenyu Wang <[email protected]>
Signed-off-by: Tina Zhang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -2178,7 +2178,8 @@ static int emulate_ggtt_mmio_write(struc
struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
unsigned long g_gtt_index = off >> info->gtt_entry_size_shift;
unsigned long gma, gfn;
- struct intel_gvt_gtt_entry e, m;
+ struct intel_gvt_gtt_entry e = {.val64 = 0, .type = GTT_TYPE_GGTT_PTE};
+ struct intel_gvt_gtt_entry m = {.val64 = 0, .type = GTT_TYPE_GGTT_PTE};
dma_addr_t dma_addr;
int ret;
struct intel_gvt_partial_pte *partial_pte, *pos, *n;
@@ -2245,7 +2246,8 @@ static int emulate_ggtt_mmio_write(struc
if (!partial_update && (ops->test_present(&e))) {
gfn = ops->get_pfn(&e);
- m = e;
+ m.val64 = e.val64;
+ m.type = e.type;
/* one PTE update may be issued in multiple writes and the
* first write may not construct a valid gfn
From: Jiri Kosina <[email protected]>
commit ec527c318036a65a083ef68d8ba95789d2212246 upstream.
As explained in
0cc3cd21657b ("cpu/hotplug: Boot HT siblings at least once")
we always, no matter what, have to bring up x86 HT siblings during boot at
least once in order to avoid first MCE bringing the system to its knees.
That means that whenever 'nosmt' is supplied on the kernel command-line,
all the HT siblings are as a result sitting in mwait or cpudile after
going through the online-offline cycle at least once.
This causes a serious issue though when a kernel, which saw 'nosmt' on its
commandline, is going to perform resume from hibernation: if the resume
from the hibernated image is successful, cr3 is flipped in order to point
to the address space of the kernel that is being resumed, which in turn
means that all the HT siblings are all of a sudden mwaiting on address
which is no longer valid.
That results in triple fault shortly after cr3 is switched, and machine
reboots.
Fix this by always waking up all the SMT siblings before initiating the
'restore from hibernation' process; this guarantees that all the HT
siblings will be properly carried over to the resumed kernel waiting in
resume_play_dead(), and acted upon accordingly afterwards, based on the
target kernel configuration.
Symmetricaly, the resumed kernel has to push the SMT siblings to mwait
again in case it has SMT disabled; this means it has to online all
the siblings when resuming (so that they come out of hlt) and offline
them again to let them reach mwait.
Cc: 4.19+ <[email protected]> # v4.19+
Debugged-by: Thomas Gleixner <[email protected]>
Fixes: 0cc3cd21657b ("cpu/hotplug: Boot HT siblings at least once")
Signed-off-by: Jiri Kosina <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Reviewed-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/power/cpu.c | 10 ++++++++++
arch/x86/power/hibernate.c | 33 +++++++++++++++++++++++++++++++++
include/linux/cpu.h | 4 ++++
kernel/cpu.c | 4 ++--
kernel/power/hibernate.c | 9 +++++++++
5 files changed, 58 insertions(+), 2 deletions(-)
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -299,7 +299,17 @@ int hibernate_resume_nonboot_cpu_disable
* address in its instruction pointer may not be possible to resolve
* any more at that point (the page tables used by it previously may
* have been overwritten by hibernate image data).
+ *
+ * First, make sure that we wake up all the potentially disabled SMT
+ * threads which have been initially brought up and then put into
+ * mwait/cpuidle sleep.
+ * Those will be put to proper (not interfering with hibernation
+ * resume) sleep afterwards, and the resumed kernel will decide itself
+ * what to do with them.
*/
+ ret = cpuhp_smt_enable();
+ if (ret)
+ return ret;
smp_ops.play_dead = resume_play_dead;
ret = disable_nonboot_cpus();
smp_ops.play_dead = play_dead;
--- a/arch/x86/power/hibernate.c
+++ b/arch/x86/power/hibernate.c
@@ -11,6 +11,7 @@
#include <linux/suspend.h>
#include <linux/scatterlist.h>
#include <linux/kdebug.h>
+#include <linux/cpu.h>
#include <crypto/hash.h>
@@ -246,3 +247,35 @@ out:
__flush_tlb_all();
return 0;
}
+
+int arch_resume_nosmt(void)
+{
+ int ret = 0;
+ /*
+ * We reached this while coming out of hibernation. This means
+ * that SMT siblings are sleeping in hlt, as mwait is not safe
+ * against control transition during resume (see comment in
+ * hibernate_resume_nonboot_cpu_disable()).
+ *
+ * If the resumed kernel has SMT disabled, we have to take all the
+ * SMT siblings out of hlt, and offline them again so that they
+ * end up in mwait proper.
+ *
+ * Called with hotplug disabled.
+ */
+ cpu_hotplug_enable();
+ if (cpu_smt_control == CPU_SMT_DISABLED ||
+ cpu_smt_control == CPU_SMT_FORCE_DISABLED) {
+ enum cpuhp_smt_control old = cpu_smt_control;
+
+ ret = cpuhp_smt_enable();
+ if (ret)
+ goto out;
+ ret = cpuhp_smt_disable(old);
+ if (ret)
+ goto out;
+ }
+out:
+ cpu_hotplug_disable();
+ return ret;
+}
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -183,10 +183,14 @@ enum cpuhp_smt_control {
extern enum cpuhp_smt_control cpu_smt_control;
extern void cpu_smt_disable(bool force);
extern void cpu_smt_check_topology(void);
+extern int cpuhp_smt_enable(void);
+extern int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval);
#else
# define cpu_smt_control (CPU_SMT_ENABLED)
static inline void cpu_smt_disable(bool force) { }
static inline void cpu_smt_check_topology(void) { }
+static inline int cpuhp_smt_enable(void) { return 0; }
+static inline int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) { return 0; }
#endif
/*
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2064,7 +2064,7 @@ static void cpuhp_online_cpu_device(unsi
kobject_uevent(&dev->kobj, KOBJ_ONLINE);
}
-static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
+int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
@@ -2096,7 +2096,7 @@ static int cpuhp_smt_disable(enum cpuhp_
return ret;
}
-static int cpuhp_smt_enable(void)
+int cpuhp_smt_enable(void)
{
int cpu, ret = 0;
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -258,6 +258,11 @@ void swsusp_show_speed(ktime_t start, kt
(kps % 1000) / 10);
}
+__weak int arch_resume_nosmt(void)
+{
+ return 0;
+}
+
/**
* create_image - Create a hibernation image.
* @platform_mode: Whether or not to use the platform driver.
@@ -325,6 +330,10 @@ static int create_image(int platform_mod
Enable_cpus:
enable_nonboot_cpus();
+ /* Allow architectures to do nosmt-specific post-resume dances */
+ if (!in_suspend)
+ error = arch_resume_nosmt();
+
Platform_finish:
platform_finish(platform_mode);
From: Jakub Kicinski <[email protected]>
[ Upstream commit e52972c11d6b1262964db96d65934196db621685 ]
Commit 38030d7cb779 ("net/tls: avoid NULL-deref on resync during device removal")
tried to fix a potential NULL-dereference by taking the
context rwsem. Unfortunately the RX resync may get called
from soft IRQ, so we can't use the rwsem to protect from
the device disappearing. Because we are guaranteed there
can be only one resync at a time (it's called from strparser)
use a bit to indicate resync is busy and make device
removal wait for the bit to get cleared.
Note that there is a leftover "flags" field in struct
tls_context already.
Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/tls.h | 4 ++++
net/tls/tls_device.c | 27 +++++++++++++++++++++------
2 files changed, 25 insertions(+), 6 deletions(-)
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -199,6 +199,10 @@ struct tls_offload_context_tx {
(ALIGN(sizeof(struct tls_offload_context_tx), sizeof(void *)) + \
TLS_DRIVER_STATE_SIZE)
+enum tls_context_flags {
+ TLS_RX_SYNC_RUNNING = 0,
+};
+
struct cipher_context {
char *iv;
char *rec_seq;
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -570,10 +570,22 @@ void tls_device_write_space(struct sock
}
}
+static void tls_device_resync_rx(struct tls_context *tls_ctx,
+ struct sock *sk, u32 seq, u64 rcd_sn)
+{
+ struct net_device *netdev;
+
+ if (WARN_ON(test_and_set_bit(TLS_RX_SYNC_RUNNING, &tls_ctx->flags)))
+ return;
+ netdev = READ_ONCE(tls_ctx->netdev);
+ if (netdev)
+ netdev->tlsdev_ops->tls_dev_resync_rx(netdev, sk, seq, rcd_sn);
+ clear_bit_unlock(TLS_RX_SYNC_RUNNING, &tls_ctx->flags);
+}
+
void handle_device_resync(struct sock *sk, u32 seq, u64 rcd_sn)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
- struct net_device *netdev = tls_ctx->netdev;
struct tls_offload_context_rx *rx_ctx;
u32 is_req_pending;
s64 resync_req;
@@ -588,10 +600,10 @@ void handle_device_resync(struct sock *s
is_req_pending = resync_req;
if (unlikely(is_req_pending) && req_seq == seq &&
- atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0))
- netdev->tlsdev_ops->tls_dev_resync_rx(netdev, sk,
- seq + TLS_HEADER_SIZE - 1,
- rcd_sn);
+ atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0)) {
+ seq += TLS_HEADER_SIZE - 1;
+ tls_device_resync_rx(tls_ctx, sk, seq, rcd_sn);
+ }
}
static int tls_device_reencrypt(struct sock *sk, struct sk_buff *skb)
@@ -981,7 +993,10 @@ static int tls_device_down(struct net_de
if (ctx->rx_conf == TLS_HW)
netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
TLS_OFFLOAD_CTX_DIR_RX);
- ctx->netdev = NULL;
+ WRITE_ONCE(ctx->netdev, NULL);
+ smp_mb__before_atomic(); /* pairs with test_and_set_bit() */
+ while (test_bit(TLS_RX_SYNC_RUNNING, &ctx->flags))
+ usleep_range(10, 200);
dev_put(netdev);
list_del_init(&ctx->list);
From: Jann Horn <[email protected]>
commit de9f869616dd95e95c00bdd6b0fcd3421e8a4323 upstream.
get_desc() computes a pointer into the LDT while holding a lock that
protects the LDT from being freed, but then drops the lock and returns the
(now potentially dangling) pointer to its caller.
Fix it by giving the caller a copy of the LDT entry instead.
Fixes: 670f928ba09b ("x86/insn-eval: Add utility function to get segment descriptor")
Cc: [email protected]
Signed-off-by: Jann Horn <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/lib/insn-eval.c | 47 ++++++++++++++++++++++++-----------------------
1 file changed, 24 insertions(+), 23 deletions(-)
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -557,7 +557,8 @@ static int get_reg_offset_16(struct insn
}
/**
- * get_desc() - Obtain pointer to a segment descriptor
+ * get_desc() - Obtain contents of a segment descriptor
+ * @out: Segment descriptor contents on success
* @sel: Segment selector
*
* Given a segment selector, obtain a pointer to the segment descriptor.
@@ -565,18 +566,18 @@ static int get_reg_offset_16(struct insn
*
* Returns:
*
- * Pointer to segment descriptor on success.
+ * True on success, false on failure.
*
* NULL on error.
*/
-static struct desc_struct *get_desc(unsigned short sel)
+static bool get_desc(struct desc_struct *out, unsigned short sel)
{
struct desc_ptr gdt_desc = {0, 0};
unsigned long desc_base;
#ifdef CONFIG_MODIFY_LDT_SYSCALL
if ((sel & SEGMENT_TI_MASK) == SEGMENT_LDT) {
- struct desc_struct *desc = NULL;
+ bool success = false;
struct ldt_struct *ldt;
/* Bits [15:3] contain the index of the desired entry. */
@@ -584,12 +585,14 @@ static struct desc_struct *get_desc(unsi
mutex_lock(¤t->active_mm->context.lock);
ldt = current->active_mm->context.ldt;
- if (ldt && sel < ldt->nr_entries)
- desc = &ldt->entries[sel];
+ if (ldt && sel < ldt->nr_entries) {
+ *out = ldt->entries[sel];
+ success = true;
+ }
mutex_unlock(¤t->active_mm->context.lock);
- return desc;
+ return success;
}
#endif
native_store_gdt(&gdt_desc);
@@ -604,9 +607,10 @@ static struct desc_struct *get_desc(unsi
desc_base = sel & ~(SEGMENT_RPL_MASK | SEGMENT_TI_MASK);
if (desc_base > gdt_desc.size)
- return NULL;
+ return false;
- return (struct desc_struct *)(gdt_desc.address + desc_base);
+ *out = *(struct desc_struct *)(gdt_desc.address + desc_base);
+ return true;
}
/**
@@ -628,7 +632,7 @@ static struct desc_struct *get_desc(unsi
*/
unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx)
{
- struct desc_struct *desc;
+ struct desc_struct desc;
short sel;
sel = get_segment_selector(regs, seg_reg_idx);
@@ -666,11 +670,10 @@ unsigned long insn_get_seg_base(struct p
if (!sel)
return -1L;
- desc = get_desc(sel);
- if (!desc)
+ if (!get_desc(&desc, sel))
return -1L;
- return get_desc_base(desc);
+ return get_desc_base(&desc);
}
/**
@@ -692,7 +695,7 @@ unsigned long insn_get_seg_base(struct p
*/
static unsigned long get_seg_limit(struct pt_regs *regs, int seg_reg_idx)
{
- struct desc_struct *desc;
+ struct desc_struct desc;
unsigned long limit;
short sel;
@@ -706,8 +709,7 @@ static unsigned long get_seg_limit(struc
if (!sel)
return 0;
- desc = get_desc(sel);
- if (!desc)
+ if (!get_desc(&desc, sel))
return 0;
/*
@@ -716,8 +718,8 @@ static unsigned long get_seg_limit(struc
* not tested when checking the segment limits. In practice,
* this means that the segment ends in (limit << 12) + 0xfff.
*/
- limit = get_desc_limit(desc);
- if (desc->g)
+ limit = get_desc_limit(&desc);
+ if (desc.g)
limit = (limit << 12) + 0xfff;
return limit;
@@ -741,7 +743,7 @@ static unsigned long get_seg_limit(struc
*/
int insn_get_code_seg_params(struct pt_regs *regs)
{
- struct desc_struct *desc;
+ struct desc_struct desc;
short sel;
if (v8086_mode(regs))
@@ -752,8 +754,7 @@ int insn_get_code_seg_params(struct pt_r
if (sel < 0)
return sel;
- desc = get_desc(sel);
- if (!desc)
+ if (!get_desc(&desc, sel))
return -EINVAL;
/*
@@ -761,10 +762,10 @@ int insn_get_code_seg_params(struct pt_r
* determines whether a segment contains data or code. If this is a data
* segment, return error.
*/
- if (!(desc->type & BIT(3)))
+ if (!(desc.type & BIT(3)))
return -EINVAL;
- switch ((desc->l << 1) | desc->d) {
+ switch ((desc.l << 1) | desc.d) {
case 0: /*
* Legacy mode. CS.L=0, CS.D=0. Address and operand size are
* both 16-bit.
On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
Compiled and booted. No regressions on x86_64.
THX
On Sun, Jun 09, 2019 at 05:37:37PM -0500, Jiunn Chang wrote:
> On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------
>
> Compiled and booted. No regressions on x86_64.
Thanks for testing and letting me know.
greg k-h
On Sun, 9 Jun 2019 at 22:15, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.1.9-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.1.y
git commit: 5b3d375b3838a28e769a56fdcb67d5422579d53b
git describe: v5.1.7-157-g5b3d375b3838
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.7-157-g5b3d375b3838
No regressions (compared to build v5.1.7)
No fixes (compared to build v5.1.7)
Ran 24361 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-fs-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org
On 09/06/2019 17:41, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.1:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 fail
Linux version: 5.1.9-rc1-g5b3d375b3838
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
On Mon, Jun 10, 2019 at 11:33:43AM +0530, Naresh Kamboju wrote:
> On Sun, 9 Jun 2019 at 22:15, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
Thanks for testing all of these and letting me know.
greg k-h
On Mon, Jun 10, 2019 at 09:52:18AM +0100, Jon Hunter wrote:
>
> On 09/06/2019 17:41, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.1:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 32 tests: 32 pass, 0 fail
>
> Linux version: 5.1.9-rc1-g5b3d375b3838
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04
Thanks for testing all of these and letting me know.
greg k-h
On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 351 pass: 351 fail: 0
Guenter
On Mon, Jun 10, 2019 at 07:45:03AM -0700, Guenter Roeck wrote:
> On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> > Anything received after that time might be too late.
> >
> Build results:
> total: 159 pass: 159 fail: 0
> Qemu test results:
> total: 351 pass: 351 fail: 0
Thanks for testing all of these and letting me know.
greg k-h
On 6/9/19 10:41 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
On Mon, Jun 10, 2019 at 04:01:41PM -0600, shuah wrote:
> On 6/9/19 10:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h