2018-07-06 05:49:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 00/46] 4.17.5-stable review

This is the start of the stable review cycle for the 4.17.5 release.
There are 46 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 Sun Jul 8 05:45:10 UTC 2018.
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/v4.x/stable-review/patch-4.17.5-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-4.17.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.17.5-rc1

Sean Nyekjaer <[email protected]>
ARM: dts: imx6q: Use correct SDMA script for SPI5 core

Andrey Ryabinin <[email protected]>
x86/mm: Don't free P4D table when it is folded at runtime

Neil Armstrong <[email protected]>
ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0

Taehee Yoo <[email protected]>
netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()

Florian Westphal <[email protected]>
netfilter: xt_connmark: fix list corruption on rmmod

Vincent Bernat <[email protected]>
netfilter: ip6t_rpfilter: provide input interface for route lookup

Kenneth Graunke <[email protected]>
drm/i915: Enable provoking vertex fix on Gen9 systems.

Ville Syrjälä <[email protected]>
drm/i915: Turn off g4x DP port in .post_disable()

Ville Syrjälä <[email protected]>
drm/i915: Disallow interlaced modes on g4x DP outputs

Ville Syrjälä <[email protected]>
drm/i915: Fix PIPESTAT irq ack on i965/g4x

Ville Syrjälä <[email protected]>
drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI

Shirish S <[email protected]>
drm/amd/display: release spinlock before committing updates to stream

Lyude Paul <[email protected]>
drm/amdgpu: Count disabled CRTCs in commit tail earlier

Michel Dänzer <[email protected]>
drm/amdgpu: GPU vs CPU page size fixes in amdgpu_vm_bo_split_mapping

Michel Dänzer <[email protected]>
drm/amdgpu: Update pin_size values before unpinning BO

Michel Dänzer <[email protected]>
drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurate

Michel Dänzer <[email protected]>
drm/amdgpu: Refactor amdgpu_vram_mgr_bo_invisible_size helper

Michel Dänzer <[email protected]>
drm/amdgpu: Use kvmalloc_array for allocating VRAM manager nodes array

Harry Wentland <[email protected]>
drm/amdgpu: Don't default to DC support for Kaveri and older

Paul Kocialkowski <[email protected]>
Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"

Stefan Agner <[email protected]>
drm/atmel-hlcdc: check stride values in the first plane

Jeremy Cline <[email protected]>
drm/qxl: Call qxl_bo_unref outside atomic context

Lyude Paul <[email protected]>
drm/i915/dp: Send DPCD ON for MST before phy_up

Mikita Lipski <[email protected]>
drm/amd/display: Clear connector's edid pointer

Oliver O'Halloran <[email protected]>
drm/sti: Depend on OF rather than selecting it

Junwei Zhang <[email protected]>
drm/amdgpu: fix clear_all and replace handling in the VM (v2)

Lyude Paul <[email protected]>
drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()

Huang Rui <[email protected]>
drm/amdgpu: fix the missed vcn fw version report

Rex Zhu <[email protected]>
drm/amdgpu: Add APU support in vi_set_vce_clocks

Rex Zhu <[email protected]>
drm/amdgpu: Add APU support in vi_set_uvd_clocks

Alexander Potapenko <[email protected]>
vt: prevent leaking uninitialized data to userspace via /dev/vcs*

Johan Hovold <[email protected]>
serdev: fix memleak on module unload

Andy Shevchenko <[email protected]>
serial: 8250_pci: Remove stalled entries in blacklist

Leonard Crestez <[email protected]>
iio: mma8452: Fix ignoring MMA8452_INT_DRDY

Laura Abbott <[email protected]>
staging: android: ion: Return an ERR_PTR in ion_map_kernel

Tetsuo Handa <[email protected]>
n_tty: Access echo_* variables carefully.

Tetsuo Handa <[email protected]>
n_tty: Fix stall at n_tty_receive_char_special().

Zhengjun Xing <[email protected]>
xhci: Fix kernel oops in trace_xhci_free_virt_device

Heikki Krogerus <[email protected]>
usb: typec: ucsi: Fix for incorrect status data issue

Heikki Krogerus <[email protected]>
usb: typec: ucsi: acpi: Workaround for cache mode issue

Heikki Krogerus <[email protected]>
acpi: Add helper for deactivating memory region

Peter Chen <[email protected]>
usb: typec: tcpm: fix logbuffer index is wrong if _tcpm_log is re-entered

William Wu <[email protected]>
usb: dwc2: fix the incorrect bitmaps for the ports of multi_tt hub

Karoly Pados <[email protected]>
USB: serial: cp210x: add Silicon Labs IDs for Windows Update

Johan Hovold <[email protected]>
USB: serial: cp210x: add CESINEL device ids

Houston Yaroschoff <[email protected]>
usb: cdc_acm: Add quirk for Uniden UBC125 scanner


-------------

Diffstat:

Makefile | 4 +-
arch/arm/boot/dts/imx6q.dtsi | 2 +-
.../boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 ++
arch/x86/include/asm/pgalloc.h | 3 +
drivers/acpi/osl.c | 72 ++++++++++++++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 24 +++----
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 39 ++++++++++-
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 4 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 77 +++++++++++++++++-----
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 +++++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 12 +++-
drivers/gpu/drm/i915/i915_reg.h | 5 ++
drivers/gpu/drm/i915/intel_crt.c | 20 ++++++
drivers/gpu/drm/i915/intel_ddi.c | 8 ++-
drivers/gpu/drm/i915/intel_display.c | 16 ++++-
drivers/gpu/drm/i915/intel_dp.c | 34 +++++-----
drivers/gpu/drm/i915/intel_dp_mst.c | 14 +++-
drivers/gpu/drm/i915/intel_dsi.c | 6 ++
drivers/gpu/drm/i915/intel_dvo.c | 6 ++
drivers/gpu/drm/i915/intel_hdmi.c | 6 ++
drivers/gpu/drm/i915/intel_lrc.c | 12 +++-
drivers/gpu/drm/i915/intel_lvds.c | 5 ++
drivers/gpu/drm/i915/intel_sdvo.c | 6 ++
drivers/gpu/drm/i915/intel_tv.c | 12 +++-
drivers/gpu/drm/qxl/qxl_display.c | 7 +-
drivers/gpu/drm/sti/Kconfig | 3 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -------
drivers/iio/accel/mma8452.c | 2 +-
drivers/staging/android/ion/ion_heap.c | 2 +-
drivers/tty/n_tty.c | 55 +++++++++-------
drivers/tty/serdev/core.c | 1 +
drivers/tty/serial/8250/8250_pci.c | 2 -
drivers/tty/vt/vt.c | 4 +-
drivers/usb/class/cdc-acm.c | 3 +
drivers/usb/dwc2/hcd_queue.c | 2 +-
drivers/usb/host/xhci-mem.c | 4 +-
drivers/usb/host/xhci-trace.h | 36 ++++++++--
drivers/usb/serial/cp210x.c | 14 ++++
drivers/usb/typec/tcpm.c | 7 +-
drivers/usb/typec/ucsi/ucsi.c | 13 ++++
drivers/usb/typec/ucsi/ucsi_acpi.c | 5 ++
include/linux/acpi.h | 3 +
net/ipv6/netfilter/ip6t_rpfilter.c | 2 +
net/netfilter/nf_tables_core.c | 3 +-
net/netfilter/xt_connmark.c | 2 +-
50 files changed, 489 insertions(+), 150 deletions(-)




2018-07-06 05:48:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 10/46] n_tty: Fix stall at n_tty_receive_char_special().

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tetsuo Handa <[email protected]>

commit 3d63b7e4ae0dc5e02d28ddd2fa1f945defc68d81 upstream.

syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is
because comparison is not working as expected since ldata->read_head can
change at any moment. Mitigate this by explicitly masking with buffer size
when checking condition for "while" loops.

[1] https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8

Signed-off-by: Tetsuo Handa <[email protected]>
Reported-by: syzbot <[email protected]>
Fixes: bc5a5e3f45d04784 ("n_tty: Don't wrap input buffer indices at buffer size")
Cc: stable <[email protected]>
Cc: Peter Hurley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/n_tty.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -124,6 +124,8 @@ struct n_tty_data {
struct mutex output_lock;
};

+#define MASK(x) ((x) & (N_TTY_BUF_SIZE - 1))
+
static inline size_t read_cnt(struct n_tty_data *ldata)
{
return ldata->read_head - ldata->read_tail;
@@ -978,14 +980,15 @@ static void eraser(unsigned char c, stru
}

seen_alnums = 0;
- while (ldata->read_head != ldata->canon_head) {
+ while (MASK(ldata->read_head) != MASK(ldata->canon_head)) {
head = ldata->read_head;

/* erase a single possibly multibyte character */
do {
head--;
c = read_buf(ldata, head);
- } while (is_continuation(c, tty) && head != ldata->canon_head);
+ } while (is_continuation(c, tty) &&
+ MASK(head) != MASK(ldata->canon_head));

/* do not partially erase */
if (is_continuation(c, tty))
@@ -1027,7 +1030,7 @@ static void eraser(unsigned char c, stru
* This info is used to go back the correct
* number of columns.
*/
- while (tail != ldata->canon_head) {
+ while (MASK(tail) != MASK(ldata->canon_head)) {
tail--;
c = read_buf(ldata, tail);
if (c == '\t') {
@@ -1302,7 +1305,7 @@ n_tty_receive_char_special(struct tty_st
finish_erasing(ldata);
echo_char(c, tty);
echo_char_raw('\n', ldata);
- while (tail != ldata->read_head) {
+ while (MASK(tail) != MASK(ldata->read_head)) {
echo_char(read_buf(ldata, tail), tty);
tail++;
}
@@ -2411,7 +2414,7 @@ static unsigned long inq_canon(struct n_
tail = ldata->read_tail;
nr = head - tail;
/* Skip EOF-chars.. */
- while (head != tail) {
+ while (MASK(head) != MASK(tail)) {
if (test_bit(tail & (N_TTY_BUF_SIZE - 1), ldata->read_flags) &&
read_buf(ldata, tail) == __DISABLED_CHAR)
nr--;



2018-07-06 05:49:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 28/46] drm/amdgpu: Dont default to DC support for Kaveri and older

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Harry Wentland <[email protected]>

commit d9fda248046ac035f18a6e663f2f9245b4bf9470 upstream.

We've had a number of users report failures to detect and light up
display with DC with LVDS and VGA. These connector types are not
currently supported with DC. I'd like to add support but unfortunately
don't have a system with LVDS or VGA available.

In order not to cause regressions we should probably fallback to the
non-DC driver for ASICs that support VGA and LVDS.

These ASICs are:
* Bonaire
* Kabini
* Kaveri
* Mullins

ASIC support can always be force enabled with amdgpu.dc=1

v2: Keep Hawaii on DC
v3: Added Mullins to the list

Cc: [email protected]
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2080,10 +2080,18 @@ bool amdgpu_device_asic_has_dc_support(e
switch (asic_type) {
#if defined(CONFIG_DRM_AMD_DC)
case CHIP_BONAIRE:
- case CHIP_HAWAII:
case CHIP_KAVERI:
case CHIP_KABINI:
case CHIP_MULLINS:
+ /*
+ * We have systems in the wild with these ASICs that require
+ * LVDS and VGA support which is not supported with DC.
+ *
+ * Fallback to the non-DC driver here by default so as not to
+ * cause regressions.
+ */
+ return amdgpu_dc > 0;
+ case CHIP_HAWAII:
case CHIP_CARRIZO:
case CHIP_STONEY:
case CHIP_POLARIS11:



2018-07-06 05:49:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 11/46] n_tty: Access echo_* variables carefully.

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tetsuo Handa <[email protected]>

commit ebec3f8f5271139df618ebdf8427e24ba102ba94 upstream.

syzbot is reporting stalls at __process_echoes() [1]. This is because
since ldata->echo_commit < ldata->echo_tail becomes true for some reason,
the discard loop is serving as almost infinite loop. This patch tries to
avoid falling into ldata->echo_commit < ldata->echo_tail situation by
making access to echo_* variables more carefully.

Since reset_buffer_flags() is called without output_lock held, it should
not touch echo_* variables. And omit a call to reset_buffer_flags() from
n_tty_open() by using vzalloc().

Since add_echo_byte() is called without output_lock held, it needs memory
barrier between storing into echo_buf[] and incrementing echo_head counter.
echo_buf() needs corresponding memory barrier before reading echo_buf[].
Lack of handling the possibility of not-yet-stored multi-byte operation
might be the reason of falling into ldata->echo_commit < ldata->echo_tail
situation, for if I do WARN_ON(ldata->echo_commit == tail + 1) prior to
echo_buf(ldata, tail + 1), the WARN_ON() fires.

Also, explicitly masking with buffer for the former "while" loop, and
use ldata->echo_commit > tail for the latter "while" loop.

[1] https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40

Signed-off-by: Tetsuo Handa <[email protected]>
Reported-by: syzbot <[email protected]>
Cc: Peter Hurley <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index b279f8730e04..431742201709 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -143,6 +143,7 @@ static inline unsigned char *read_buf_addr(struct n_tty_data *ldata, size_t i)

static inline unsigned char echo_buf(struct n_tty_data *ldata, size_t i)
{
+ smp_rmb(); /* Matches smp_wmb() in add_echo_byte(). */
return ldata->echo_buf[i & (N_TTY_BUF_SIZE - 1)];
}

@@ -318,9 +319,7 @@ static inline void put_tty_queue(unsigned char c, struct n_tty_data *ldata)
static void reset_buffer_flags(struct n_tty_data *ldata)
{
ldata->read_head = ldata->canon_head = ldata->read_tail = 0;
- ldata->echo_head = ldata->echo_tail = ldata->echo_commit = 0;
ldata->commit_head = 0;
- ldata->echo_mark = 0;
ldata->line_start = 0;

ldata->erasing = 0;
@@ -619,12 +618,19 @@ static size_t __process_echoes(struct tty_struct *tty)
old_space = space = tty_write_room(tty);

tail = ldata->echo_tail;
- while (ldata->echo_commit != tail) {
+ while (MASK(ldata->echo_commit) != MASK(tail)) {
c = echo_buf(ldata, tail);
if (c == ECHO_OP_START) {
unsigned char op;
int no_space_left = 0;

+ /*
+ * Since add_echo_byte() is called without holding
+ * output_lock, we might see only portion of multi-byte
+ * operation.
+ */
+ if (MASK(ldata->echo_commit) == MASK(tail + 1))
+ goto not_yet_stored;
/*
* If the buffer byte is the start of a multi-byte
* operation, get the next byte, which is either the
@@ -636,6 +642,8 @@ static size_t __process_echoes(struct tty_struct *tty)
unsigned int num_chars, num_bs;

case ECHO_OP_ERASE_TAB:
+ if (MASK(ldata->echo_commit) == MASK(tail + 2))
+ goto not_yet_stored;
num_chars = echo_buf(ldata, tail + 2);

/*
@@ -730,7 +738,8 @@ static size_t __process_echoes(struct tty_struct *tty)
/* If the echo buffer is nearly full (so that the possibility exists
* of echo overrun before the next commit), then discard enough
* data at the tail to prevent a subsequent overrun */
- while (ldata->echo_commit - tail >= ECHO_DISCARD_WATERMARK) {
+ while (ldata->echo_commit > tail &&
+ ldata->echo_commit - tail >= ECHO_DISCARD_WATERMARK) {
if (echo_buf(ldata, tail) == ECHO_OP_START) {
if (echo_buf(ldata, tail + 1) == ECHO_OP_ERASE_TAB)
tail += 3;
@@ -740,6 +749,7 @@ static size_t __process_echoes(struct tty_struct *tty)
tail++;
}

+ not_yet_stored:
ldata->echo_tail = tail;
return old_space - space;
}
@@ -750,6 +760,7 @@ static void commit_echoes(struct tty_struct *tty)
size_t nr, old, echoed;
size_t head;

+ mutex_lock(&ldata->output_lock);
head = ldata->echo_head;
ldata->echo_mark = head;
old = ldata->echo_commit - ldata->echo_tail;
@@ -758,10 +769,12 @@ static void commit_echoes(struct tty_struct *tty)
* is over the threshold (and try again each time another
* block is accumulated) */
nr = head - ldata->echo_tail;
- if (nr < ECHO_COMMIT_WATERMARK || (nr % ECHO_BLOCK > old % ECHO_BLOCK))
+ if (nr < ECHO_COMMIT_WATERMARK ||
+ (nr % ECHO_BLOCK > old % ECHO_BLOCK)) {
+ mutex_unlock(&ldata->output_lock);
return;
+ }

- mutex_lock(&ldata->output_lock);
ldata->echo_commit = head;
echoed = __process_echoes(tty);
mutex_unlock(&ldata->output_lock);
@@ -812,7 +825,9 @@ static void flush_echoes(struct tty_struct *tty)

static inline void add_echo_byte(unsigned char c, struct n_tty_data *ldata)
{
- *echo_buf_addr(ldata, ldata->echo_head++) = c;
+ *echo_buf_addr(ldata, ldata->echo_head) = c;
+ smp_wmb(); /* Matches smp_rmb() in echo_buf(). */
+ ldata->echo_head++;
}

/**
@@ -1881,30 +1896,21 @@ static int n_tty_open(struct tty_struct *tty)
struct n_tty_data *ldata;

/* Currently a malloc failure here can panic */
- ldata = vmalloc(sizeof(*ldata));
+ ldata = vzalloc(sizeof(*ldata));
if (!ldata)
- goto err;
+ return -ENOMEM;

ldata->overrun_time = jiffies;
mutex_init(&ldata->atomic_read_lock);
mutex_init(&ldata->output_lock);

tty->disc_data = ldata;
- reset_buffer_flags(tty->disc_data);
- ldata->column = 0;
- ldata->canon_column = 0;
- ldata->num_overrun = 0;
- ldata->no_room = 0;
- ldata->lnext = 0;
tty->closing = 0;
/* indicate buffer work may resume */
clear_bit(TTY_LDISC_HALTED, &tty->flags);
n_tty_set_termios(tty, NULL);
tty_unthrottle(tty);
-
return 0;
-err:
- return -ENOMEM;
}

static inline int input_available_p(struct tty_struct *tty, int poll)



2018-07-06 05:50:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 40/46] drm/i915: Enable provoking vertex fix on Gen9 systems.

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kenneth Graunke <[email protected]>

commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb upstream.

The SF and clipper units mishandle the provoking vertex in some cases,
which can cause misrendering with shaders that use flat shaded inputs.

There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
(for the clipper) that work around the issue. These registers are
unfortunately not part of the logical context (even the power context),
and so we must reload them every time we start executing in a context.

Bugzilla: https://bugs.freedesktop.org/103047
Signed-off-by: Kenneth Graunke <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
Cc: [email protected]
(cherry picked from commit b77422f80337d363eed60c8c48db9cb6e33085c9)
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/i915_reg.h | 5 +++++
drivers/gpu/drm/i915/intel_lrc.c | 12 +++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2565,12 +2565,17 @@ enum i915_power_well_id {
#define _3D_CHICKEN _MMIO(0x2084)
#define _3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB (1 << 10)
#define _3D_CHICKEN2 _MMIO(0x208c)
+
+#define FF_SLICE_CHICKEN _MMIO(0x2088)
+#define FF_SLICE_CHICKEN_CL_PROVOKING_VERTEX_FIX (1 << 1)
+
/* Disables pipelining of read flushes past the SF-WIZ interface.
* Required on all Ironlake steppings according to the B-Spec, but the
* particular danger of not doing so is not specified.
*/
# define _3D_CHICKEN2_WM_READ_PIPELINED (1 << 14)
#define _3D_CHICKEN3 _MMIO(0x2090)
+#define _3D_CHICKEN_SF_PROVOKING_VERTEX_FIX (1 << 12)
#define _3D_CHICKEN_SF_DISABLE_OBJEND_CULL (1 << 10)
#define _3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE (1 << 5)
#define _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL (1 << 5)
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1386,11 +1386,21 @@ static u32 *gen9_init_indirectctx_bb(str
/* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt,glk */
batch = gen8_emit_flush_coherentl3_wa(engine, batch);

+ *batch++ = MI_LOAD_REGISTER_IMM(3);
+
/* WaDisableGatherAtSetShaderCommonSlice:skl,bxt,kbl,glk */
- *batch++ = MI_LOAD_REGISTER_IMM(1);
*batch++ = i915_mmio_reg_offset(COMMON_SLICE_CHICKEN2);
*batch++ = _MASKED_BIT_DISABLE(
GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE);
+
+ /* BSpec: 11391 */
+ *batch++ = i915_mmio_reg_offset(FF_SLICE_CHICKEN);
+ *batch++ = _MASKED_BIT_ENABLE(FF_SLICE_CHICKEN_CL_PROVOKING_VERTEX_FIX);
+
+ /* BSpec: 11299 */
+ *batch++ = i915_mmio_reg_offset(_3D_CHICKEN3);
+ *batch++ = _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_PROVOKING_VERTEX_FIX);
+
*batch++ = MI_NOOP;

/* WaClearSlmSpaceAtContextSwitch:kbl */



2018-07-06 05:50:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 14/46] serial: 8250_pci: Remove stalled entries in blacklist

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Shevchenko <[email protected]>

commit 20dcff436e9fcd2e106b0ccc48a52206bc176d70 upstream.

After the commit

7d8905d06405 ("serial: 8250_pci: Enable device after we check black list")

pure serial multi-port cards, such as CH355, got blacklisted and thus
not being enumerated anymore. Previously, it seems, blacklisting them
was on purpose to shut up pciserial_init_one() about record duplication.

So, remove the entries from blacklist in order to get cards enumerated.

Fixes: 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list")
Reported-by: Matt Turner <[email protected]>
Cc: Sergej Pupykin <[email protected]>
Cc: Alexandr Petrenko <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-and-Tested-by: Matt Turner <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/8250/8250_pci.c | 2 --
1 file changed, 2 deletions(-)

--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3339,9 +3339,7 @@ static const struct pci_device_id blackl
/* multi-io cards handled by parport_serial */
{ PCI_DEVICE(0x4348, 0x7053), }, /* WCH CH353 2S1P */
{ PCI_DEVICE(0x4348, 0x5053), }, /* WCH CH353 1S1P */
- { PCI_DEVICE(0x4348, 0x7173), }, /* WCH CH355 4S */
{ PCI_DEVICE(0x1c00, 0x3250), }, /* WCH CH382 2S1P */
- { PCI_DEVICE(0x1c00, 0x3470), }, /* WCH CH384 4S */

/* Moxa Smartio MUE boards handled by 8250_moxa */
{ PCI_VDEVICE(MOXA, 0x1024), },



2018-07-06 05:51:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 27/46] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Kocialkowski <[email protected]>

commit 58b3d02f066e5b1480d80bd308c545526eea3250 upstream.

This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.

The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.

It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.

This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.

Cc: [email protected]
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -------------------------
1 file changed, 25 deletions(-)

--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,7 +17,6 @@
#include <drm/drm_encoder.h>
#include <drm/drm_modes.h>
#include <drm/drm_of.h>
-#include <drm/drm_panel.h>

#include <uapi/drm/drm_mode.h>

@@ -350,9 +349,6 @@ static void sun4i_tcon0_mode_set_lvds(st
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
- struct drm_panel *panel = tcon->panel;
- struct drm_connector *connector = panel->connector;
- struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -410,27 +406,6 @@ static void sun4i_tcon0_mode_set_rgb(str
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

- /*
- * On A20 and similar SoCs, the only way to achieve Positive Edge
- * (Rising Edge), is setting dclk clock phase to 2/3(240°).
- * By default TCON works in Negative Edge(Falling Edge),
- * this is why phase is set to 0 in that case.
- * Unfortunately there's no way to logically invert dclk through
- * IO_POL register.
- * The only acceptable way to work, triple checked with scope,
- * is using clock phase set to 0° for Negative Edge and set to 240°
- * for Positive Edge.
- * On A33 and similar SoCs there would be a 90° phase option,
- * but it divides also dclk by 2.
- * Following code is a way to avoid quirks all around TCON
- * and DOTCLOCK drivers.
- */
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
-
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);



2018-07-06 05:51:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 16/46] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Potapenko <[email protected]>

commit 21eff69aaaa0e766ca0ce445b477698dc6a9f55a upstream.

KMSAN reported an infoleak when reading from /dev/vcs*:

BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0
Call Trace:
...
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
copy_to_user ./include/linux/uaccess.h:184
vcs_read+0x18ba/0x1cc0 drivers/tty/vt/vc_screen.c:352
__vfs_read+0x1b2/0x9d0 fs/read_write.c:416
vfs_read+0x36c/0x6b0 fs/read_write.c:452
...
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
__kmalloc+0x13a/0x350 mm/slub.c:3818
kmalloc ./include/linux/slab.h:517
vc_allocate+0x438/0x800 drivers/tty/vt/vt.c:787
con_install+0x8c/0x640 drivers/tty/vt/vt.c:2880
tty_driver_install_tty drivers/tty/tty_io.c:1224
tty_init_dev+0x1b5/0x1020 drivers/tty/tty_io.c:1324
tty_open_by_driver drivers/tty/tty_io.c:1959
tty_open+0x17b4/0x2ed0 drivers/tty/tty_io.c:2007
chrdev_open+0xc25/0xd90 fs/char_dev.c:417
do_dentry_open+0xccc/0x1440 fs/open.c:794
vfs_open+0x1b6/0x2f0 fs/open.c:908
...
Bytes 0-79 of 240 are uninitialized

Consistently allocating |vc_screenbuf| with kzalloc() fixes the problem

Reported-by: [email protected]
Signed-off-by: Alexander Potapenko <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/vt/vt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -784,7 +784,7 @@ int vc_allocate(unsigned int currcons) /
if (!*vc->vc_uni_pagedir_loc)
con_set_default_unimap(vc);

- vc->vc_screenbuf = kmalloc(vc->vc_screenbuf_size, GFP_KERNEL);
+ vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
if (!vc->vc_screenbuf)
goto err_free;

@@ -871,7 +871,7 @@ static int vc_do_resize(struct tty_struc

if (new_screen_size > (4 << 20))
return -EINVAL;
- newscreen = kmalloc(new_screen_size, GFP_USER);
+ newscreen = kzalloc(new_screen_size, GFP_USER);
if (!newscreen)
return -ENOMEM;




2018-07-06 05:51:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 12/46] staging: android: ion: Return an ERR_PTR in ion_map_kernel

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Laura Abbott <[email protected]>

commit 0a2bc00341dcfcc793c0dbf4f8d43adf60458b05 upstream.

The expected return value from ion_map_kernel is an ERR_PTR. The error
path for a vmalloc failure currently just returns NULL, triggering
a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR.

Reported-by: [email protected]
Signed-off-by: Laura Abbott <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/android/ion/ion_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -29,7 +29,7 @@ void *ion_heap_map_kernel(struct ion_hea
struct page **tmp = pages;

if (!pages)
- return NULL;
+ return ERR_PTR(-ENOMEM);

if (buffer->flags & ION_FLAG_CACHED)
pgprot = PAGE_KERNEL;



2018-07-06 06:05:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 46/46] ARM: dts: imx6q: Use correct SDMA script for SPI5 core

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sean Nyekjaer <[email protected]>

commit df07101e1c4a29e820df02f9989a066988b160e6 upstream.

According to the reference manual the shp_2_mcu / mcu_2_shp
scripts must be used for devices connected through the SPBA.

This fixes an issue we saw with DMA transfers.
Sometimes the SPI controller RX FIFO was not empty after a DMA
transfer and the driver got stuck in the next PIO transfer when
it read one word more than expected.

commit dd4b487b32a35 ("ARM: dts: imx6: Use correct SDMA script
for SPI cores") is fixing the same issue but only for SPI1 - 4.

Fixes: 677940258dd8e ("ARM: dts: imx6q: enable dma for ecspi5")
Signed-off-by: Sean Nyekjaer <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/imx6q.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -96,7 +96,7 @@
clocks = <&clks IMX6Q_CLK_ECSPI5>,
<&clks IMX6Q_CLK_ECSPI5>;
clock-names = "ipg", "per";
- dmas = <&sdma 11 7 1>, <&sdma 12 7 2>;
+ dmas = <&sdma 11 8 1>, <&sdma 12 8 2>;
dma-names = "rx", "tx";
status = "disabled";
};



2018-07-06 06:05:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 43/46] netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Taehee Yoo <[email protected]>

commit adc972c5b88829d38ede08b1069718661c7330ae upstream.

When depth of chain is bigger than NFT_JUMP_STACK_SIZE, the nft_do_chain
crashes. But there is no need to crash hard here.

Suggested-by: Florian Westphal <[email protected]>
Signed-off-by: Taehee Yoo <[email protected]>
Acked-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/netfilter/nf_tables_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/netfilter/nf_tables_core.c
+++ b/net/netfilter/nf_tables_core.c
@@ -208,7 +208,8 @@ next_rule:

switch (regs.verdict.code) {
case NFT_JUMP:
- BUG_ON(stackptr >= NFT_JUMP_STACK_SIZE);
+ if (WARN_ON_ONCE(stackptr >= NFT_JUMP_STACK_SIZE))
+ return NF_DROP;
jumpstack[stackptr].chain = chain;
jumpstack[stackptr].rule = rule;
jumpstack[stackptr].rulenum = rulenum;



2018-07-06 06:08:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 44/46] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Neil Armstrong <[email protected]>

commit d511b3e4087eedbe11c7496c396432b8b7c2d7d9 upstream.

Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
devices on the P212 Reference Design based boards.

Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller")
Signed-off-by: Neil Armstrong <[email protected]>
Acked-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++++++
1 file changed, 7 insertions(+)

--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
@@ -189,3 +189,10 @@
&usb0 {
status = "okay";
};
+
+&usb2_phy0 {
+ /*
+ * HDMI_5V is also used as supply for the USB VBUS.
+ */
+ phy-supply = <&hdmi_5v>;
+};



2018-07-06 06:08:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 09/46] xhci: Fix kernel oops in trace_xhci_free_virt_device

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhengjun Xing <[email protected]>

commit d850c1658328e757635a46763783c6fd56390dcb upstream.

commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
set dev->udev pointer to NULL in xhci_free_dev(), it will cause kernel
panic in trace_xhci_free_virt_device. This patch reimplement the trace
function trace_xhci_free_virt_device, remove dev->udev dereference and
added more useful parameters to show in the trace function,it also makes
sure dev->udev is not NULL before calling trace_xhci_free_virt_device.
This issue happened when xhci-hcd trace is enabled and USB devices hot
plug test. Original use-after-free patch went to stable so this needs so
be applied there as well.

[ 1092.022457] usb 2-4: USB disconnect, device number 6
[ 1092.092772] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 1092.101694] PGD 0 P4D 0
[ 1092.104601] Oops: 0000 [#1] SMP
[ 1092.207734] Workqueue: usb_hub_wq hub_event
[ 1092.212507] RIP: 0010:trace_event_raw_event_xhci_log_virt_dev+0x6c/0xf0
[ 1092.220050] RSP: 0018:ffff8c252e883d28 EFLAGS: 00010086
[ 1092.226024] RAX: ffff8c24af86fa84 RBX: 0000000000000003 RCX: ffff8c25255c2a01
[ 1092.234130] RDX: 0000000000000000 RSI: 00000000aef55009 RDI: ffff8c252e883d28
[ 1092.242242] RBP: ffff8c252550e2c0 R08: ffff8c24af86fa84 R09: 0000000000000a70
[ 1092.250364] R10: 0000000000000a70 R11: 0000000000000000 R12: ffff8c251f21a000
[ 1092.258468] R13: 000000000000000c R14: ffff8c251f21a000 R15: ffff8c251f432f60
[ 1092.266572] FS: 0000000000000000(0000) GS:ffff8c252e880000(0000) knlGS:0000000000000000
[ 1092.275757] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1092.282281] CR2: 0000000000000000 CR3: 0000000154209001 CR4: 00000000003606e0
[ 1092.290384] Call Trace:
[ 1092.293156] <IRQ>
[ 1092.295439] xhci_free_virt_device.part.34+0x182/0x1a0
[ 1092.301288] handle_cmd_completion+0x7ac/0xfa0
[ 1092.306336] ? trace_event_raw_event_xhci_log_trb+0x6e/0xa0
[ 1092.312661] xhci_irq+0x3e8/0x1f60
[ 1092.316524] __handle_irq_event_percpu+0x75/0x180
[ 1092.321876] handle_irq_event_percpu+0x20/0x50
[ 1092.326922] handle_irq_event+0x36/0x60
[ 1092.331273] handle_edge_irq+0x6d/0x180
[ 1092.335644] handle_irq+0x16/0x20
[ 1092.339417] do_IRQ+0x41/0xc0
[ 1092.342782] common_interrupt+0xf/0xf
[ 1092.346955] </IRQ>

Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
Cc: <[email protected]>
Signed-off-by: Zhengjun Xing <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-mem.c | 4 ++--
drivers/usb/host/xhci-trace.h | 36 +++++++++++++++++++++++++++++++-----
2 files changed, 33 insertions(+), 7 deletions(-)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -878,12 +878,12 @@ void xhci_free_virt_device(struct xhci_h

dev = xhci->devs[slot_id];

- trace_xhci_free_virt_device(dev);
-
xhci->dcbaa->dev_context_ptrs[slot_id] = 0;
if (!dev)
return;

+ trace_xhci_free_virt_device(dev);
+
if (dev->tt_info)
old_active_eps = dev->tt_info->active_eps;

--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -171,6 +171,37 @@ DEFINE_EVENT(xhci_log_trb, xhci_dbc_gadg
TP_ARGS(ring, trb)
);

+DECLARE_EVENT_CLASS(xhci_log_free_virt_dev,
+ TP_PROTO(struct xhci_virt_device *vdev),
+ TP_ARGS(vdev),
+ TP_STRUCT__entry(
+ __field(void *, vdev)
+ __field(unsigned long long, out_ctx)
+ __field(unsigned long long, in_ctx)
+ __field(u8, fake_port)
+ __field(u8, real_port)
+ __field(u16, current_mel)
+
+ ),
+ TP_fast_assign(
+ __entry->vdev = vdev;
+ __entry->in_ctx = (unsigned long long) vdev->in_ctx->dma;
+ __entry->out_ctx = (unsigned long long) vdev->out_ctx->dma;
+ __entry->fake_port = (u8) vdev->fake_port;
+ __entry->real_port = (u8) vdev->real_port;
+ __entry->current_mel = (u16) vdev->current_mel;
+ ),
+ TP_printk("vdev %p ctx %llx | %llx fake_port %d real_port %d current_mel %d",
+ __entry->vdev, __entry->in_ctx, __entry->out_ctx,
+ __entry->fake_port, __entry->real_port, __entry->current_mel
+ )
+);
+
+DEFINE_EVENT(xhci_log_free_virt_dev, xhci_free_virt_device,
+ TP_PROTO(struct xhci_virt_device *vdev),
+ TP_ARGS(vdev)
+);
+
DECLARE_EVENT_CLASS(xhci_log_virt_dev,
TP_PROTO(struct xhci_virt_device *vdev),
TP_ARGS(vdev),
@@ -207,11 +238,6 @@ DEFINE_EVENT(xhci_log_virt_dev, xhci_all
TP_PROTO(struct xhci_virt_device *vdev),
TP_ARGS(vdev)
);
-
-DEFINE_EVENT(xhci_log_virt_dev, xhci_free_virt_device,
- TP_PROTO(struct xhci_virt_device *vdev),
- TP_ARGS(vdev)
-);

DEFINE_EVENT(xhci_log_virt_dev, xhci_setup_device,
TP_PROTO(struct xhci_virt_device *vdev),



2018-07-06 06:08:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 45/46] x86/mm: Dont free P4D table when it is folded at runtime

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andrey Ryabinin <[email protected]>

commit 0e311d237d7f3022b7dafb639b42541bfb42fe94 upstream.

When the P4D page table layer is folded at runtime, the p4d_free()
should do nothing, the same as in <asm-generic/pgtable-nop4d.h>.

It seems this bug should cause double-free in efi_call_phys_epilog(),
but I don't know how to trigger that code path, so I can't confirm that
by testing.

Signed-off-by: Andrey Ryabinin <[email protected]>
Reviewed-by: Kirill A. Shutemov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected] # 4.17
Fixes: 98219dda2ab5 ("x86/mm: Fold p4d page table layer at runtime")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Andrey Ryabinin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/asm/pgalloc.h | 3 +++
1 file changed, 3 insertions(+)

--- a/arch/x86/include/asm/pgalloc.h
+++ b/arch/x86/include/asm/pgalloc.h
@@ -184,6 +184,9 @@ static inline p4d_t *p4d_alloc_one(struc

static inline void p4d_free(struct mm_struct *mm, p4d_t *p4d)
{
+ if (!pgtable_l5_enabled)
+ return;
+
BUG_ON((unsigned long)p4d & (PAGE_SIZE-1));
free_page((unsigned long)p4d);
}



2018-07-06 06:09:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 15/46] serdev: fix memleak on module unload

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit bc6cf3669d22371f573ab0305b3abf13887c0786 upstream.

Make sure to free all resources associated with the ida on module
exit.

Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Cc: stable <[email protected]> # 4.11
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serdev/core.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -617,6 +617,7 @@ EXPORT_SYMBOL_GPL(__serdev_device_driver
static void __exit serdev_exit(void)
{
bus_unregister(&serdev_bus_type);
+ ida_destroy(&ctrl_ida);
}
module_exit(serdev_exit);




2018-07-06 06:10:00

by syzbot

[permalink] [raw]
Subject: Re: [PATCH 4.17 16/46] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

> 4.17-stable review patch. If anyone has any objections, please let me
> know.

> ------------------

> From: Alexander Potapenko <[email protected]>

> commit 21eff69aaaa0e766ca0ce445b477698dc6a9f55a upstream.

> KMSAN reported an infoleak when reading from /dev/vcs*:

> BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0
> Call Trace:
> ...
> kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
> copy_to_user ./include/linux/uaccess.h:184
> vcs_read+0x18ba/0x1cc0 drivers/tty/vt/vc_screen.c:352
> __vfs_read+0x1b2/0x9d0 fs/read_write.c:416
> vfs_read+0x36c/0x6b0 fs/read_write.c:452
> ...
> Uninit was created at:
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279
> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
> __kmalloc+0x13a/0x350 mm/slub.c:3818
> kmalloc ./include/linux/slab.h:517
> vc_allocate+0x438/0x800 drivers/tty/vt/vt.c:787
> con_install+0x8c/0x640 drivers/tty/vt/vt.c:2880
> tty_driver_install_tty drivers/tty/tty_io.c:1224
> tty_init_dev+0x1b5/0x1020 drivers/tty/tty_io.c:1324
> tty_open_by_driver drivers/tty/tty_io.c:1959
> tty_open+0x17b4/0x2ed0 drivers/tty/tty_io.c:2007
> chrdev_open+0xc25/0xd90 fs/char_dev.c:417
> do_dentry_open+0xccc/0x1440 fs/open.c:794
> vfs_open+0x1b6/0x2f0 fs/open.c:908
> ...
> Bytes 0-79 of 240 are uninitialized

> Consistently allocating |vc_screenbuf| with kzalloc() fixes the problem

> Reported-by: [email protected]
> Signed-off-by: Alexander Potapenko <[email protected]>
> Cc: stable <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

> ---
> drivers/tty/vt/vt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)

> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -784,7 +784,7 @@ int vc_allocate(unsigned int currcons) /
> if (!*vc->vc_uni_pagedir_loc)
> con_set_default_unimap(vc);

> - vc->vc_screenbuf = kmalloc(vc->vc_screenbuf_size, GFP_KERNEL);
> + vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
> if (!vc->vc_screenbuf)
> goto err_free;

> @@ -871,7 +871,7 @@ static int vc_do_resize(struct tty_struc

> if (new_screen_size > (4 << 20))
> return -EINVAL;
> - newscreen = kmalloc(new_screen_size, GFP_USER);
> + newscreen = kzalloc(new_screen_size, GFP_USER);
> if (!newscreen)
> return -ENOMEM;




Can't find the corresponding bug.


2018-07-06 06:11:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 42/46] netfilter: xt_connmark: fix list corruption on rmmod

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Florian Westphal <[email protected]>

commit fc6ddbecce440df74fb4491c17c372b52cf5be83 upstream.

This needs to use xt_unregister_targets, else new revision is left
on the list which then causes list to point to a target struct that has been free'd.

Fixes: 472a73e00757 ("netfilter: xt_conntrack: Support bit-shifting for CONNMARK & MARK targets.")
Signed-off-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/netfilter/xt_connmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/netfilter/xt_connmark.c
+++ b/net/netfilter/xt_connmark.c
@@ -211,7 +211,7 @@ static int __init connmark_mt_init(void)
static void __exit connmark_mt_exit(void)
{
xt_unregister_match(&connmark_mt_reg);
- xt_unregister_target(connmark_tg_reg);
+ xt_unregister_targets(connmark_tg_reg, ARRAY_SIZE(connmark_tg_reg));
}

module_init(connmark_mt_init);



2018-07-06 06:11:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 13/46] iio: mma8452: Fix ignoring MMA8452_INT_DRDY

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Leonard Crestez <[email protected]>

commit b02ec67a8e38875cdc5f9214be885022f11c0017 upstream.

Interrupts are ignored if no event bit is set in the status status
register and this breaks the buffer interface. No data is shown when
running "iio_generic_buffer -n mma8451 -a" and interrupt counts go
crazy.

Fix by not returning IRQ_NONE if DRDY is set.

Fixes: 605f72de137a ("iio: accel: mma8452: improvements to handle
multiple events")

Signed-off-by: Leonard Crestez <[email protected]>
cc: <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iio/accel/mma8452.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1034,7 +1034,7 @@ static irqreturn_t mma8452_interrupt(int
if (src < 0)
return IRQ_NONE;

- if (!(src & data->chip_info->enabled_events))
+ if (!(src & (data->chip_info->enabled_events | MMA8452_INT_DRDY)))
return IRQ_NONE;

if (src & MMA8452_INT_DRDY) {



2018-07-06 06:11:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 41/46] netfilter: ip6t_rpfilter: provide input interface for route lookup

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vincent Bernat <[email protected]>

commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 upstream.

In commit 47b7e7f82802, this bit was removed at the same time the
RT6_LOOKUP_F_IFACE flag was removed. However, it is needed when
link-local addresses are used, which is a very common case: when
packets are routed, neighbor solicitations are done using link-local
addresses. For example, the following neighbor solicitation is not
matched by "-m rpfilter":

IP6 fe80::5254:33ff:fe00:1 > ff02::1:ff00:3: ICMP6, neighbor
solicitation, who has 2001:db8::5254:33ff:fe00:3, length 32

Commit 47b7e7f82802 doesn't quite explain why we shouldn't use
RT6_LOOKUP_F_IFACE in the rpfilter case. I suppose the interface check
later in the function would make it redundant. However, the remaining
of the routing code is using RT6_LOOKUP_F_IFACE when there is no
source address (which matches rpfilter's case with a non-unicast
destination, like with neighbor solicitation).

Signed-off-by: Vincent Bernat <[email protected]>
Fixes: 47b7e7f82802 ("netfilter: don't set F_IFACE on ipv6 fib lookups")
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/ipv6/netfilter/ip6t_rpfilter.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/ipv6/netfilter/ip6t_rpfilter.c
+++ b/net/ipv6/netfilter/ip6t_rpfilter.c
@@ -48,6 +48,8 @@ static bool rpfilter_lookup_reverse6(str
}

fl6.flowi6_mark = flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
+ if ((flags & XT_RPFILTER_LOOSE) == 0)
+ fl6.flowi6_oif = dev->ifindex;

rt = (void *)ip6_route_lookup(net, &fl6, skb, lookup_flags);
if (rt->dst.error)



2018-07-06 06:12:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 26/46] drm/atmel-hlcdc: check stride values in the first plane

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Agner <[email protected]>

commit 9fcf2b3c1c0276650fea537c71b513d27d929b05 upstream.

The statement always evaluates to true since the struct fields
are arrays. This has shown up as a warning when compiling with
clang:
warning: address of array 'desc->layout.xstride' will always
evaluate to 'true' [-Wpointer-bool-conversion]

Check for values in the first plane instead.

Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
Cc: <[email protected]>
Signed-off-by: Stefan Agner <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -875,7 +875,7 @@ static int atmel_hlcdc_plane_init_proper
drm_object_attach_property(&plane->base.base,
props->alpha, 255);

- if (desc->layout.xstride && desc->layout.pstride) {
+ if (desc->layout.xstride[0] && desc->layout.pstride[0]) {
int ret;

ret = drm_plane_create_rotation_property(&plane->base,



2018-07-06 06:12:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 25/46] drm/qxl: Call qxl_bo_unref outside atomic context

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeremy Cline <[email protected]>

commit 889ad63d41eea20184b0483e7e585e5b20fb6cfe upstream.

"qxl_bo_unref" may sleep, but calling "qxl_release_map" causes
"preempt_disable()" to be called and "preempt_enable()" isn't called
until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out
from in between the two to avoid sleeping from an atomic context.

This issue can be demonstrated on a kernel with CONFIG_LOCKDEP=y by
creating a VM using QXL, using a desktop environment using Xorg, then
moving the cursor on or off a window.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1571128
Fixes: 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
Cc: [email protected]
Signed-off-by: Jeremy Cline <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/qxl/qxl_display.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -630,7 +630,7 @@ static void qxl_cursor_atomic_update(str
struct qxl_cursor_cmd *cmd;
struct qxl_cursor *cursor;
struct drm_gem_object *obj;
- struct qxl_bo *cursor_bo = NULL, *user_bo = NULL;
+ struct qxl_bo *cursor_bo = NULL, *user_bo = NULL, *old_cursor_bo = NULL;
int ret;
void *user_ptr;
int size = 64*64*4;
@@ -684,7 +684,7 @@ static void qxl_cursor_atomic_update(str
cursor_bo, 0);
cmd->type = QXL_CURSOR_SET;

- qxl_bo_unref(&qcrtc->cursor_bo);
+ old_cursor_bo = qcrtc->cursor_bo;
qcrtc->cursor_bo = cursor_bo;
cursor_bo = NULL;
} else {
@@ -704,6 +704,9 @@ static void qxl_cursor_atomic_update(str
qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);

+ if (old_cursor_bo)
+ qxl_bo_unref(&old_cursor_bo);
+
qxl_bo_unref(&cursor_bo);

return;



2018-07-06 06:12:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 23/46] drm/amd/display: Clear connectors edid pointer

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mikita Lipski <[email protected]>

commit 5326c4525d1b2d5f1519268dd305e19c9bd4ef56 upstream.

Clear connector's edid pointer on coonnector update, when unplugging
the display.

Fix poison EDID when hotplugging on previously used connector.

Signed-off-by: Mikita Lipski <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -928,6 +928,7 @@ amdgpu_dm_update_connector_after_detect(
drm_mode_connector_update_edid_property(connector, NULL);
aconnector->num_modes = 0;
aconnector->dc_sink = NULL;
+ aconnector->edid = NULL;
}

mutex_unlock(&dev->mode_config.mutex);



2018-07-06 06:13:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 22/46] drm/sti: Depend on OF rather than selecting it

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oliver O'Halloran <[email protected]>

commit c9fea6f4379c72b7c59e1efceab09a35bc7eac43 upstream.

Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg
structure") reworked some code inside of this driver and made it select
CONFIG_OF. This results in the entire OF layer being enabled when
building an allmodconfig on ia64. OF on ia64 is completely unsupported
so this isn't a great state of affairs.

The 0day robot noticed a link-time failure on ia64 caused by
using of_node_to_nid() in an otherwise unrelated driver. The
generic fallback for of_node_to_nid() only exists when:

defined(CONFIG_OF) && defined(CONFIG_NUMA) == false

Since CONFIG_NUMA is usually selected for IA64 we get the link failure.
Fix this by making the driver depend on OF rather than selecting it,
odds are that was the original intent.

Link: https://lists.01.org/pipermail/kbuild-all/2018-March/045172.html
Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure")
Cc: Benjamin Gaignard <[email protected]>
Cc: Vincent Abriou <[email protected]>
Cc: David Airlie <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Oliver O'Halloran <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Philippe Cornu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/sti/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,6 @@
config DRM_STI
tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
- depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
+ depends on OF && DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
@@ -8,6 +8,5 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
- select OF
help
Choose this option to enable DRM on STM stiH4xx chipset



2018-07-06 06:14:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 06/46] acpi: Add helper for deactivating memory region

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heikki Krogerus <[email protected]>

commit d2d2e3c46be5d6dd8001d0eebdf7cafb9bc7006b upstream.

Sometimes memory resource may be overlapping with
SystemMemory Operation Region by design, for example if the
memory region is used as a mailbox for communication with a
firmware in the system. One occasion of such mailboxes is
USB Type-C Connector System Software Interface (UCSI).

With regions like that, it is important that the driver is
able to map the memory with the requirements it has. For
example, the driver should be allowed to map the memory as
non-cached memory. However, if the operation region has been
accessed before the driver has mapped the memory, the memory
has been marked as write-back by the time the driver is
loaded. That means the driver will fail to map the memory
if it expects non-cached memory.

To work around the problem, introducing helper that the
drivers can use to temporarily deactivate (unmap)
SystemMemory Operation Regions that overlap with their
IO memory.

Fixes: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver")
Cc: [email protected]
Reviewed-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Heikki Krogerus <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/osl.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 3 ++
2 files changed, 75 insertions(+)

--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -45,6 +45,8 @@
#include <linux/uaccess.h>
#include <linux/io-64-nonatomic-lo-hi.h>

+#include "acpica/accommon.h"
+#include "acpica/acnamesp.h"
#include "internal.h"

#define _COMPONENT ACPI_OS_SERVICES
@@ -1490,6 +1492,76 @@ int acpi_check_region(resource_size_t st
}
EXPORT_SYMBOL(acpi_check_region);

+static acpi_status acpi_deactivate_mem_region(acpi_handle handle, u32 level,
+ void *_res, void **return_value)
+{
+ struct acpi_mem_space_context **mem_ctx;
+ union acpi_operand_object *handler_obj;
+ union acpi_operand_object *region_obj2;
+ union acpi_operand_object *region_obj;
+ struct resource *res = _res;
+ acpi_status status;
+
+ region_obj = acpi_ns_get_attached_object(handle);
+ if (!region_obj)
+ return AE_OK;
+
+ handler_obj = region_obj->region.handler;
+ if (!handler_obj)
+ return AE_OK;
+
+ if (region_obj->region.space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY)
+ return AE_OK;
+
+ if (!(region_obj->region.flags & AOPOBJ_SETUP_COMPLETE))
+ return AE_OK;
+
+ region_obj2 = acpi_ns_get_secondary_object(region_obj);
+ if (!region_obj2)
+ return AE_OK;
+
+ mem_ctx = (void *)&region_obj2->extra.region_context;
+
+ if (!(mem_ctx[0]->address >= res->start &&
+ mem_ctx[0]->address < res->end))
+ return AE_OK;
+
+ status = handler_obj->address_space.setup(region_obj,
+ ACPI_REGION_DEACTIVATE,
+ NULL, (void **)mem_ctx);
+ if (ACPI_SUCCESS(status))
+ region_obj->region.flags &= ~(AOPOBJ_SETUP_COMPLETE);
+
+ return status;
+}
+
+/**
+ * acpi_release_memory - Release any mappings done to a memory region
+ * @handle: Handle to namespace node
+ * @res: Memory resource
+ * @level: A level that terminates the search
+ *
+ * Walks through @handle and unmaps all SystemMemory Operation Regions that
+ * overlap with @res and that have already been activated (mapped).
+ *
+ * This is a helper that allows drivers to place special requirements on memory
+ * region that may overlap with operation regions, primarily allowing them to
+ * safely map the region as non-cached memory.
+ *
+ * The unmapped Operation Regions will be automatically remapped next time they
+ * are called, so the drivers do not need to do anything else.
+ */
+acpi_status acpi_release_memory(acpi_handle handle, struct resource *res,
+ u32 level)
+{
+ if (!(res->flags & IORESOURCE_MEM))
+ return AE_TYPE;
+
+ return acpi_walk_namespace(ACPI_TYPE_REGION, handle, level,
+ acpi_deactivate_mem_region, NULL, res, NULL);
+}
+EXPORT_SYMBOL_GPL(acpi_release_memory);
+
/*
* Let drivers know whether the resource checks are effective
*/
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -443,6 +443,9 @@ int acpi_check_resource_conflict(const s
int acpi_check_region(resource_size_t start, resource_size_t n,
const char *name);

+acpi_status acpi_release_memory(acpi_handle handle, struct resource *res,
+ u32 level);
+
int acpi_resources_are_enforced(void);

#ifdef CONFIG_HIBERNATION



2018-07-06 06:14:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 07/46] usb: typec: ucsi: acpi: Workaround for cache mode issue

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heikki Krogerus <[email protected]>

commit 1f9f9d168ce619608572b01771c47a41b15429e6 upstream.

This fixes an issue where the driver fails with an error:

ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got 0x0

On some platforms the UCSI ACPI mailbox SystemMemory
Operation Region may be setup before the driver has been
loaded. That will lead into the driver failing to map the
mailbox region, as it has been already marked as write-back
memory. acpi_os_ioremap() for x86 uses ioremap_cache()
unconditionally.

When the issue happens, the embedded controller has a
pending query event for the UCSI notification right after
boot-up which causes the operation region to be setup before
UCSI driver has been loaded.

The fix is to notify acpi core that the driver is about to
access memory region which potentially overlaps with an
operation region right before mapping it.
acpi_release_memory() will check if the memory has already
been setup (mapped) by acpi core, and deactivate it (unmap)
if it has. The driver is then able to map the memory with
ioremap_nocache() and set the memtype to uncached for the
region.

Reported-by: Paul Menzel <[email protected]>
Fixes: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver")
Cc: [email protected]
Signed-off-by: Heikki Krogerus <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/typec/ucsi/ucsi_acpi.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -79,6 +79,11 @@ static int ucsi_acpi_probe(struct platfo
return -ENODEV;
}

+ /* This will make sure we can use ioremap_nocache() */
+ status = acpi_release_memory(ACPI_HANDLE(&pdev->dev), res, 1);
+ if (ACPI_FAILURE(status))
+ return -ENOMEM;
+
/*
* NOTE: The memory region for the data structures is used also in an
* operation region, which means ACPI has already reserved it. Therefore



2018-07-06 06:14:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 05/46] usb: typec: tcpm: fix logbuffer index is wrong if _tcpm_log is re-entered

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Chen <[email protected]>

commit d5a4f93511b7000183c0d528739b824752139f79 upstream.

The port->logbuffer_head may be wrong if the two processes enters
_tcpm_log at the mostly same time. The 2nd process enters _tcpm_log
before the 1st process update the index, then the 2nd process will
not allocate logbuffer, when the 2nd process tries to use log buffer,
the index has already updated by the 1st process, so it will get
NULL pointer for updated logbuffer, the error message like below:

tcpci 0-0050: Log buffer index 6 is NULL

Cc: Heikki Krogerus <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jun Li <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
Cc: stable <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/typec/tcpm.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -388,17 +388,18 @@ static void _tcpm_log(struct tcpm_port *
u64 ts_nsec = local_clock();
unsigned long rem_nsec;

+ mutex_lock(&port->logbuffer_lock);
if (!port->logbuffer[port->logbuffer_head]) {
port->logbuffer[port->logbuffer_head] =
kzalloc(LOG_BUFFER_ENTRY_SIZE, GFP_KERNEL);
- if (!port->logbuffer[port->logbuffer_head])
+ if (!port->logbuffer[port->logbuffer_head]) {
+ mutex_unlock(&port->logbuffer_lock);
return;
+ }
}

vsnprintf(tmpbuffer, sizeof(tmpbuffer), fmt, args);

- mutex_lock(&port->logbuffer_lock);
-
if (tcpm_log_full(port)) {
port->logbuffer_head = max(port->logbuffer_head - 1, 0);
strcpy(tmpbuffer, "overflow");



2018-07-06 06:14:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 08/46] usb: typec: ucsi: Fix for incorrect status data issue

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heikki Krogerus <[email protected]>

commit 68816e16b4789f2d05e77b6dcb77564cf5d6a8d8 upstream.

According to UCSI Specification, Connector Change Event only
means a change in the Connector Status and Operation Mode
fields of the STATUS data structure. So any other change
should create another event.

Unfortunately on some platforms the firmware acting as PPM
(platform policy manager - usually embedded controller
firmware) still does not report any other status changes if
there is a connector change event. So if the connector power
or data role was changed when a device was plugged to the
connector, the driver does not get any indication about
that. The port will show wrong roles if that happens.

To fix the issue, always checking the data and power role
together with a connector change event.

Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Signed-off-by: Heikki Krogerus <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/typec/ucsi/ucsi.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -350,6 +350,19 @@ static void ucsi_connector_change(struct
}

if (con->status.change & UCSI_CONSTAT_CONNECT_CHANGE) {
+ typec_set_pwr_role(con->port, con->status.pwr_dir);
+
+ switch (con->status.partner_type) {
+ case UCSI_CONSTAT_PARTNER_TYPE_UFP:
+ typec_set_data_role(con->port, TYPEC_HOST);
+ break;
+ case UCSI_CONSTAT_PARTNER_TYPE_DFP:
+ typec_set_data_role(con->port, TYPEC_DEVICE);
+ break;
+ default:
+ break;
+ }
+
if (con->status.connected)
ucsi_register_partner(con);
else



2018-07-06 06:14:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 04/46] usb: dwc2: fix the incorrect bitmaps for the ports of multi_tt hub

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: William Wu <[email protected]>

commit 8760675932ddb614e83702117d36ea644050c609 upstream.

The dwc2_get_ls_map() use ttport to reference into the
bitmap if we're on a multi_tt hub. But the bitmaps index
from 0 to (hub->maxchild - 1), while the ttport index from
1 to hub->maxchild. This will cause invalid memory access
when the number of ttport is hub->maxchild.

Without this patch, I can easily meet a Kernel panic issue
if connect a low-speed USB mouse with the max port of FE2.1
multi-tt hub (1a40:0201) on rk3288 platform.

Fixes: 9f9f09b048f5 ("usb: dwc2: host: Totally redo the microframe scheduler")
Cc: <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Acked-by: Minas Harutyunyan [email protected]>
Signed-off-by: William Wu <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/dwc2/hcd_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -383,7 +383,7 @@ static unsigned long *dwc2_get_ls_map(st
/* Get the map and adjust if this is a multi_tt hub */
map = qh->dwc_tt->periodic_bitmaps;
if (qh->dwc_tt->usb_tt->multi)
- map += DWC2_ELEMENTS_PER_LS_BITMAP * qh->ttport;
+ map += DWC2_ELEMENTS_PER_LS_BITMAP * (qh->ttport - 1);

return map;
}



2018-07-06 06:14:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 02/46] USB: serial: cp210x: add CESINEL device ids

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit 24160628a34af962ac99f2f58e547ac3c4cbd26f upstream.

Add device ids for CESINEL products.

Reported-by: Carlos Barcala Lara <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/cp210x.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -95,6 +95,9 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8156) }, /* B&G H3000 link cable */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
{ USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
+ { USB_DEVICE(0x10C4, 0x817C) }, /* CESINEL MEDCAL N Power Quality Monitor */
+ { USB_DEVICE(0x10C4, 0x817D) }, /* CESINEL MEDCAL NT Power Quality Monitor */
+ { USB_DEVICE(0x10C4, 0x817E) }, /* CESINEL MEDCAL S Power Quality Monitor */
{ USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */
{ USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */
{ USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */
@@ -112,6 +115,9 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x826B) }, /* Cygnal Integrated Products, Inc., Fasttrax GPS demonstration module */
{ USB_DEVICE(0x10C4, 0x8281) }, /* Nanotec Plug & Drive */
{ USB_DEVICE(0x10C4, 0x8293) }, /* Telegesis ETRX2USB */
+ { USB_DEVICE(0x10C4, 0x82EF) }, /* CESINEL FALCO 6105 AC Power Supply */
+ { USB_DEVICE(0x10C4, 0x82F1) }, /* CESINEL MEDCAL EFD Earth Fault Detector */
+ { USB_DEVICE(0x10C4, 0x82F2) }, /* CESINEL MEDCAL ST Network Analyzer */
{ USB_DEVICE(0x10C4, 0x82F4) }, /* Starizona MicroTouch */
{ USB_DEVICE(0x10C4, 0x82F9) }, /* Procyon AVS */
{ USB_DEVICE(0x10C4, 0x8341) }, /* Siemens MC35PU GPRS Modem */
@@ -124,7 +130,9 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System Console */
{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
{ USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */
+ { USB_DEVICE(0x10C4, 0x851E) }, /* CESINEL MEDCAL PT Network Analyzer */
{ USB_DEVICE(0x10C4, 0x85A7) }, /* LifeScan OneTouch Verio IQ */
+ { USB_DEVICE(0x10C4, 0x85B8) }, /* CESINEL ReCon T Energy Logger */
{ USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
{ USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
@@ -134,10 +142,13 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8857) }, /* CEL EM357 ZigBee USB Stick */
{ USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
{ USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB Device */
+ { USB_DEVICE(0x10C4, 0x88FB) }, /* CESINEL MEDCAL STII Network Analyzer */
+ { USB_DEVICE(0x10C4, 0x8938) }, /* CESINEL MEDCAL S II Network Analyzer */
{ USB_DEVICE(0x10C4, 0x8946) }, /* Ketra N1 Wireless Interface */
{ USB_DEVICE(0x10C4, 0x8962) }, /* Brim Brothers charging dock */
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
+ { USB_DEVICE(0x10C4, 0x89A4) }, /* CESINEL FTBC Flexible Thyristor Bridge Controller */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
{ USB_DEVICE(0x10C4, 0x8A5E) }, /* CEL EM3588 ZigBee USB Stick Long Range */
{ USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick */



2018-07-06 06:16:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 01/46] usb: cdc_acm: Add quirk for Uniden UBC125 scanner

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Houston Yaroschoff <[email protected]>

commit 4a762569a2722b8a48066c7bacf0e1dc67d17fa1 upstream.

Uniden UBC125 radio scanner has USB interface which fails to work
with cdc_acm driver:
usb 1-1.5: new full-speed USB device number 4 using xhci_hcd
cdc_acm 1-1.5:1.0: Zero length descriptor references
cdc_acm: probe of 1-1.5:1.0 failed with error -22

Adding the NO_UNION_NORMAL quirk for the device fixes the issue:
usb 1-4: new full-speed USB device number 15 using xhci_hcd
usb 1-4: New USB device found, idVendor=1965, idProduct=0018
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: UBC125XLT
usb 1-4: Manufacturer: Uniden Corp.
usb 1-4: SerialNumber: 0001
cdc_acm 1-4:1.0: ttyACM0: USB ACM device

`lsusb -v` of the device:

Bus 001 Device 015: ID 1965:0018 Uniden Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1965 Uniden Corporation
idProduct 0x0018
bcdDevice 0.01
iManufacturer 1 Uniden Corp.
iProduct 2 UBC125XLT
iSerial 3 0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 48
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

Signed-off-by: Houston Yaroschoff <[email protected]>
Cc: stable <[email protected]>
Acked-by: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/class/cdc-acm.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1758,6 +1758,9 @@ static const struct usb_device_id acm_id
{ USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */
.driver_info = SINGLE_RX_URB,
},
+ { USB_DEVICE(0x1965, 0x0018), /* Uniden UBC125XLT */
+ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+ },
{ USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},



2018-07-06 06:16:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.17 03/46] USB: serial: cp210x: add Silicon Labs IDs for Windows Update

4.17-stable review patch. If anyone has any objections, please let me know.

------------------

From: Karoly Pados <[email protected]>

commit 2f839823382748664b643daa73f41ee0cc01ced6 upstream.

Silicon Labs defines alternative VID/PID pairs for some chips that when
used will automatically install drivers for Windows users without manual
intervention. Unfortunately, these IDs are not recognized by the Linux
module, so using these IDs improves user experience on one platform but
degrades it on Linux. This patch addresses this problem.

Signed-off-by: Karoly Pados <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/cp210x.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -154,8 +154,11 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
+ { USB_DEVICE(0x10C4, 0xEA63) }, /* Silicon Labs Windows Update (CP2101-4/CP2102N) */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA71) }, /* Infinity GPS-MIC-1 Radio Monophone */
+ { USB_DEVICE(0x10C4, 0xEA7A) }, /* Silicon Labs Windows Update (CP2105) */
+ { USB_DEVICE(0x10C4, 0xEA7B) }, /* Silicon Labs Windows Update (CP2108) */
{ USB_DEVICE(0x10C4, 0xF001) }, /* Elan Digital Systems USBscope50 */
{ USB_DEVICE(0x10C4, 0xF002) }, /* Elan Digital Systems USBwave12 */
{ USB_DEVICE(0x10C4, 0xF003) }, /* Elan Digital Systems USBpulse100 */



2018-07-06 17:52:24

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.17 00/46] 4.17.5-stable review

On Fri, Jul 06, 2018 at 07:46:21AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.5 release.
> There are 46 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.

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary
------------------------------------------------------------------------

kernel: 4.17.5-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.17.y
git commit: 211fe6663749212887c5d36f2e483acfb831377b
git describe: v4.17.4-47-g211fe6663749
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.4-47-g211fe6663749

No regressions (compared to build v4.17.4-47-gd0d428d64248)

Ran 16369 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-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-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* kselftest
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

2018-07-06 18:10:33

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.17 00/46] 4.17.5-stable review

On Fri, Jul 06, 2018 at 11:51:24AM -0600, Dan Rue wrote:
> On Fri, Jul 06, 2018 at 07:46:21AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.5 release.
> > There are 46 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.
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
>
> Summary
> ------------------------------------------------------------------------
>
> kernel: 4.17.5-rc1
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> git branch: linux-4.17.y
> git commit: 211fe6663749212887c5d36f2e483acfb831377b
> git describe: v4.17.4-47-g211fe6663749
> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.4-47-g211fe6663749
>
> No regressions (compared to build v4.17.4-47-gd0d428d64248)
>
> Ran 16369 total tests in the following environments and test suites.

Forgot to mention - you may (or may not) notice the test count is about
5000 higher. LTP Open Posix test suite was added this week, which adds
about 1700 tests per environment. We are running it on one environment
per architecture (arm32, arm64, x86_64), because its runtime is a little
long on some boards.

>
> Environments
> --------------
> - dragonboard-410c - arm64
> - hi6220-hikey - arm64
> - juno-r2 - arm64
> - qemu_arm
> - qemu_arm64
> - qemu_x86_64
> - x15 - arm
> - x86_64
>
> Test Suites
> -----------
> * boot
> * libhugetlbfs
> * ltp-cap_bounds-tests
> * ltp-containers-tests
> * ltp-cve-tests
> * ltp-fcntl-locktests-tests
> * ltp-filecaps-tests
> * ltp-fs-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-nptl-tests
> * ltp-pty-tests
> * ltp-sched-tests
> * ltp-securebits-tests
> * ltp-syscalls-tests
> * ltp-timers-tests
> * kselftest
> * ltp-open-posix-tests
> * kselftest-vsyscall-mode-native
> * kselftest-vsyscall-mode-none
>
> --
> Linaro LKFT
> https://lkft.linaro.org

2018-07-07 14:54:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.17 00/46] 4.17.5-stable review

On Fri, Jul 06, 2018 at 11:51:24AM -0600, Dan Rue wrote:
> On Fri, Jul 06, 2018 at 07:46:21AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.5 release.
> > There are 46 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.
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Wonderful, thanks for testing both of these.

greg k-h

2018-07-07 21:42:15

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.17 00/46] 4.17.5-stable review

On Fri, Jul 06, 2018 at 07:46:21AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.5 release.
> There are 46 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 Sun Jul 8 05:45:10 UTC 2018.
> Anything received after that time might be too late.
>

Build results:
total: 134 pass: 134 fail: 0
Qemu test results:
total: 158 pass: 158 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter