[PATCH 4.4 00/40] 4.4.97-stable review

[PATCH 4.4 00/40] 4.4.97-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.4.97 release.
There are 40 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 Wed Nov  8 09:44:42 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.97-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.4.97-rc1

Larry Finger <Larry.Finger@lwfinger.net>
    staging: r8712u: Fix Sparse warning in rtl871x_xmit.c

Juergen Gross <jgross@suse.com>
    xen: don't print error message in case of missing Xenstore entry

Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    bt8xx: fix memory leak

Stefan Haberland <sth@linux.vnet.ibm.com>
    s390/dasd: check for device error pointer within state change interrupts

Alexander Usyskin <alexander.usyskin@intel.com>
    mei: return error on notification request to a disconnected client

Arvind Yadav <arvind.yadav.cs@gmail.com>
    exynos4-is: fimc-is: Unmap region obtained by of_iomap()

Alexander Boyko <alexander.boyko@seagate.com>
    staging: lustre: ptlrpc: skip lock if export failed

frank zago <fzago@cray.com>
    staging: lustre: hsm: stack overrun in hai_dump_data_field

Yang Sheng <yang.sheng@intel.com>
    staging: lustre: llite: don't invoke direct_IO for the EOF case

Javier Martinez Canillas <javier@osg.samsung.com>
    platform/x86: intel_mid_thermal: Fix module autoload

Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
    scsi: aacraid: Process Error for response I/O

Jan Beulich <JBeulich@suse.com>
    xen/manage: correct return value check on xenbus_scanf()

Archit Taneja <architt@codeaurora.org>
    drm/msm/dsi: Set msm_dsi->encoders before initializing bridge

Oleh Kravchenko <oleg@kaa.org.ua>
    cx231xx: Fix I2C on Internal Master 3 Bus

Taeung Song <treeze.taeung@gmail.com>
    perf tools: Only increase index if perf_evsel__new_idx() succeeds

Rex Zhu <Rex.Zhu@amd.com>
    drm/amdgpu: when dpm disabled, also need to stop/start vce.

Chris Brandt <chris.brandt@renesas.com>
    i2c: riic: correctly finish transfers

Jan Kara <jack@suse.cz>
    ext4: do not use stripe_width if it is not set

Jan Kara <jack@suse.cz>
    ext4: fix stripe-unaligned allocations

Larry Finger <Larry.Finger@lwfinger.net>
    staging: rtl8712u: Fix endian settings for structs describing network packets

Hans de Goede <hdegoede@redhat.com>
    mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped

Linus Walleij <linus.walleij@linaro.org>
    mfd: ab8500-sysctrl: Handle probe deferral

Ulf Hansson <ulf.hansson@linaro.org>
    ARM: pxa: Don't rely on public mmc header to include leds.h

Arnd Bergmann <arnd@arndb.de>
    mmc: s3cmci: include linux/interrupt.h for tasklet_struct

Grygorii Strashko <grygorii.strashko@ti.com>
    PM / wakeirq: report a wakeup_event on dedicated wekup irq

Linus Torvalds <torvalds@linux-foundation.org>
    Fix tracing sample code warning.

Steven Rostedt (VMware) <rostedt@goodmis.org>
    tracing/samples: Fix creation and deletion of simple_thread_fn creation

Dan Carpenter <dan.carpenter@oracle.com>
    drm/msm: fix an integer overflow test

Kasin Li <donglil@codeaurora.org>
    drm/msm: Fix potential buffer overflow issue

Namhyung Kim <namhyung@kernel.org>
    perf tools: Fix build failure on perl script context

Ashish Samant <ashish.samant@oracle.com>
    ocfs2: fstrim: Fix start offset of first cluster group during fstrim

Arnd Bergmann <arnd@arndb.de>
    ARM: 8715/1: add a private asm/unaligned.h

Yan Markman <ymarkman@marvell.com>
    ARM: dts: mvebu: pl310-cache disable double-linefill

Mark Rutland <mark.rutland@arm.com>
    arm64: ensure __dump_instr() checks addr_limit

Ricard Wanderlof <ricard.wanderlof@axis.com>
    ASoC: adau17x1: Workaround for noise bug in ADC

Eric Biggers <ebiggers@google.com>
    KEYS: fix out-of-bounds read during ASN.1 parsing

Eric Biggers <ebiggers@google.com>
    KEYS: return full count in keyring_read() if buffer is too small

Ronnie Sahlberg <lsahlber@redhat.com>
    cifs: check MaxPathNameComponentLength != 0 before using it

Takashi Iwai <tiwai@suse.de>
    ALSA: seq: Fix nested rwsem annotation for lockdep splat

Takashi Iwai <tiwai@suse.de>
    ALSA: timer: Add missing mutex lock for compat ioctls


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

Diffstat:

 Makefile                                           |   4 +-
 arch/arm/boot/dts/armada-375.dtsi                  |   4 +-
 arch/arm/boot/dts/armada-38x.dtsi                  |   4 +-
 arch/arm/boot/dts/armada-39x.dtsi                  |   4 +-
 arch/arm/include/asm/Kbuild                        |   1 -
 arch/arm/include/asm/unaligned.h                   |  27 ++
 arch/arm/mach-pxa/balloon3.c                       |   1 +
 arch/arm/mach-pxa/colibri-pxa270-income.c          |   1 +
 arch/arm/mach-pxa/corgi.c                          |   1 +
 arch/arm/mach-pxa/trizeps4.c                       |   1 +
 arch/arm/mach-pxa/vpac270.c                        |   1 +
 arch/arm/mach-pxa/zeus.c                           |   1 +
 arch/arm/mach-pxa/zylonite.c                       |   1 +
 arch/arm64/kernel/traps.c                          |   2 +-
 drivers/base/power/wakeirq.c                       |   7 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c            |   9 +
 drivers/gpu/drm/msm/dsi/dsi.c                      |   8 +-
 drivers/gpu/drm/msm/msm_gem_submit.c               |   7 +-
 drivers/i2c/busses/i2c-riic.c                      |  30 ++-
 drivers/media/pci/bt8xx/dvb-bt8xx.c                |   1 +
 drivers/media/platform/exynos4-is/fimc-is.c        |   8 +-
 drivers/media/usb/cx231xx/cx231xx-core.c           |   7 +-
 drivers/mfd/ab8500-sysctrl.c                       |  14 +-
 drivers/mfd/axp20x.c                               |   8 +-
 drivers/misc/mei/client.c                          |   3 +
 drivers/mmc/host/s3cmci.c                          |   1 +
 drivers/platform/x86/intel_mid_thermal.c           |   1 +
 drivers/s390/block/dasd.c                          |   7 +-
 drivers/scsi/aacraid/aachba.c                      | 289 +++++++++++----------
 .../lustre/lustre/include/lustre/lustre_user.h     |  18 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lock.c     |   7 +
 drivers/staging/lustre/lustre/llite/rw26.c         |   4 +
 drivers/staging/lustre/lustre/ptlrpc/service.c     |  21 +-
 drivers/staging/rtl8712/ieee80211.h                |  84 +++---
 drivers/staging/rtl8712/rtl871x_xmit.c             |   7 +-
 drivers/xen/manage.c                               |  12 +-
 fs/cifs/dir.c                                      |   5 +-
 fs/ext4/mballoc.c                                  |   6 +-
 fs/ext4/super.c                                    |   4 +-
 fs/ocfs2/alloc.c                                   |  24 +-
 lib/asn1_decoder.c                                 |   3 +
 samples/trace_events/trace-events-sample.c         |  14 +-
 security/keys/keyring.c                            |  39 ++-
 sound/core/seq/seq_clientmgr.c                     |   2 +-
 sound/core/timer_compat.c                          |  17 +-
 sound/soc/codecs/adau17x1.c                        |  24 +-
 sound/soc/codecs/adau17x1.h                        |   2 +
 tools/perf/scripts/perl/Perf-Trace-Util/Build      |   4 +-
 tools/perf/util/parse-events.c                     |   3 +-
 49 files changed, 468 insertions(+), 285 deletions(-)

[PATCH 4.4 01/40] ALSA: timer: Add missing mutex lock for compat ioctls

[Greg Kroah-Hartman]

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream.

The races among ioctl and other operations were protected by the
commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and
later fixes, but one code path was forgotten in the scenario: the
32bit compat ioctl.  As syzkaller recently spotted, a very similar
use-after-free may happen with the combination of compat ioctls.

The fix is simply to apply the same ioctl_lock to the compat_ioctl
callback, too.

Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls")
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/core/timer_compat.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -106,7 +106,8 @@ enum {
 #endif /* CONFIG_X86_X32 */
 };
 
-static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg)
+static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+					  unsigned long arg)
 {
 	void __user *argp = compat_ptr(arg);
 
@@ -127,7 +128,7 @@ static long snd_timer_user_ioctl_compat(
 	case SNDRV_TIMER_IOCTL_PAUSE:
 	case SNDRV_TIMER_IOCTL_PAUSE_OLD:
 	case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
-		return snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
+		return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
 	case SNDRV_TIMER_IOCTL_INFO32:
 		return snd_timer_user_info_compat(file, argp);
 	case SNDRV_TIMER_IOCTL_STATUS32:
@@ -139,3 +140,15 @@ static long snd_timer_user_ioctl_compat(
 	}
 	return -ENOIOCTLCMD;
 }
+
+static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+					unsigned long arg)
+{
+	struct snd_timer_user *tu = file->private_data;
+	long ret;
+
+	mutex_lock(&tu->ioctl_lock);
+	ret = __snd_timer_user_ioctl_compat(file, cmd, arg);
+	mutex_unlock(&tu->ioctl_lock);
+	return ret;
+}

[PATCH 4.4 01/40] ALSA: timer: Add missing mutex lock for compat ioctls

[Greg Kroah-Hartman]

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream.

The races among ioctl and other operations were protected by the
commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and
later fixes, but one code path was forgotten in the scenario: the
32bit compat ioctl.  As syzkaller recently spotted, a very similar
use-after-free may happen with the combination of compat ioctls.

The fix is simply to apply the same ioctl_lock to the compat_ioctl
callback, too.

Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls")
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/core/timer_compat.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -106,7 +106,8 @@ enum {
 #endif /* CONFIG_X86_X32 */
 };
 
-static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg)
+static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+					  unsigned long arg)
 {
 	void __user *argp = compat_ptr(arg);
 
@@ -127,7 +128,7 @@ static long snd_timer_user_ioctl_compat(
 	case SNDRV_TIMER_IOCTL_PAUSE:
 	case SNDRV_TIMER_IOCTL_PAUSE_OLD:
 	case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
-		return snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
+		return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
 	case SNDRV_TIMER_IOCTL_INFO32:
 		return snd_timer_user_info_compat(file, argp);
 	case SNDRV_TIMER_IOCTL_STATUS32:
@@ -139,3 +140,15 @@ static long snd_timer_user_ioctl_compat(
 	}
 	return -ENOIOCTLCMD;
 }
+
+static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+					unsigned long arg)
+{
+	struct snd_timer_user *tu = file->private_data;
+	long ret;
+
+	mutex_lock(&tu->ioctl_lock);
+	ret = __snd_timer_user_ioctl_compat(file, cmd, arg);
+	mutex_unlock(&tu->ioctl_lock);
+	return ret;
+}

[PATCH 4.4 02/40] ALSA: seq: Fix nested rwsem annotation for lockdep splat

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream.

syzkaller reported the lockdep splat due to the possible deadlock of
grp->list_mutex of each sequencer client object.  Actually this is
rather a false-positive report due to the missing nested lock
annotations.  The sequencer client may deliver the event directly to
another client which takes another own lock.

For addressing this issue, this patch replaces the simple down_read()
with down_read_nested().  As a lock subclass, the already existing
"hop" can be re-used, which indicates the depth of the call.

Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/core/seq/seq_clientmgr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -676,7 +676,7 @@ static int deliver_to_subscribers(struct
 	if (atomic)
 		read_lock(&grp->list_lock);
 	else
-		down_read(&grp->list_mutex);
+		down_read_nested(&grp->list_mutex, hop);
 	list_for_each_entry(subs, &grp->list_head, src_list) {
 		/* both ports ready? */
 		if (atomic_read(&subs->ref_count) != 2)

[PATCH 4.4 02/40] ALSA: seq: Fix nested rwsem annotation for lockdep splat

[Greg Kroah-Hartman]

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream.

syzkaller reported the lockdep splat due to the possible deadlock of
grp->list_mutex of each sequencer client object.  Actually this is
rather a false-positive report due to the missing nested lock
annotations.  The sequencer client may deliver the event directly to
another client which takes another own lock.

For addressing this issue, this patch replaces the simple down_read()
with down_read_nested().  As a lock subclass, the already existing
"hop" can be re-used, which indicates the depth of the call.

Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/core/seq/seq_clientmgr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -676,7 +676,7 @@ static int deliver_to_subscribers(struct
 	if (atomic)
 		read_lock(&grp->list_lock);
 	else
-		down_read(&grp->list_mutex);
+		down_read_nested(&grp->list_mutex, hop);
 	list_for_each_entry(subs, &grp->list_head, src_list) {
 		/* both ports ready? */
 		if (atomic_read(&subs->ref_count) != 2)

[PATCH 4.4 03/40] cifs: check MaxPathNameComponentLength != 0 before using it

[Greg Kroah-Hartman]

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

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

From: Ronnie Sahlberg <lsahlber@redhat.com>

commit f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 upstream.

And fix tcon leak in error path.

Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/cifs/dir.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -193,7 +193,8 @@ check_name(struct dentry *direntry, stru
 	struct cifs_sb_info *cifs_sb = CIFS_SB(direntry->d_sb);
 	int i;
 
-	if (unlikely(direntry->d_name.len >
+	if (unlikely(tcon->fsAttrInfo.MaxPathNameComponentLength &&
+		     direntry->d_name.len >
 		     le32_to_cpu(tcon->fsAttrInfo.MaxPathNameComponentLength)))
 		return -ENAMETOOLONG;
 
@@ -509,7 +510,7 @@ cifs_atomic_open(struct inode *inode, st
 
 	rc = check_name(direntry, tcon);
 	if (rc)
-		goto out_free_xid;
+		goto out;
 
 	server = tcon->ses->server;
 

[PATCH 4.4 04/40] KEYS: return full count in keyring_read() if buffer is too small

[Greg Kroah-Hartman]

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

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

From: Eric Biggers <ebiggers@google.com>

commit 3239b6f29bdfb4b0a2ba59df995fc9e6f4df7f1f upstream.

Commit e645016abc80 ("KEYS: fix writing past end of user-supplied buffer
in keyring_read()") made keyring_read() stop corrupting userspace memory
when the user-supplied buffer is too small.  However it also made the
return value in that case be the short buffer size rather than the size
required, yet keyctl_read() is actually documented to return the size
required.  Therefore, switch it over to the documented behavior.

Note that for now we continue to have it fill the short buffer, since it
did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably
relies on it.

Fixes: e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()")
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 security/keys/keyring.c |   39 +++++++++++++++++++--------------------
 1 file changed, 19 insertions(+), 20 deletions(-)

--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -452,34 +452,33 @@ static long keyring_read(const struct ke
 			 char __user *buffer, size_t buflen)
 {
 	struct keyring_read_iterator_context ctx;
-	unsigned long nr_keys;
-	int ret;
+	long ret;
 
 	kenter("{%d},,%zu", key_serial(keyring), buflen);
 
 	if (buflen & (sizeof(key_serial_t) - 1))
 		return -EINVAL;
 
-	nr_keys = keyring->keys.nr_leaves_on_tree;
-	if (nr_keys == 0)
-		return 0;
-
-	/* Calculate how much data we could return */
-	if (!buffer || !buflen)
-		return nr_keys * sizeof(key_serial_t);
-
-	/* Copy the IDs of the subscribed keys into the buffer */
-	ctx.buffer = (key_serial_t __user *)buffer;
-	ctx.buflen = buflen;
-	ctx.count = 0;
-	ret = assoc_array_iterate(&keyring->keys, keyring_read_iterator, &ctx);
-	if (ret < 0) {
-		kleave(" = %d [iterate]", ret);
-		return ret;
+	/* Copy as many key IDs as fit into the buffer */
+	if (buffer && buflen) {
+		ctx.buffer = (key_serial_t __user *)buffer;
+		ctx.buflen = buflen;
+		ctx.count = 0;
+		ret = assoc_array_iterate(&keyring->keys,
+					  keyring_read_iterator, &ctx);
+		if (ret < 0) {
+			kleave(" = %ld [iterate]", ret);
+			return ret;
+		}
 	}
 
-	kleave(" = %zu [ok]", ctx.count);
-	return ctx.count;
+	/* Return the size of the buffer needed */
+	ret = keyring->keys.nr_leaves_on_tree * sizeof(key_serial_t);
+	if (ret <= buflen)
+		kleave("= %ld [ok]", ret);
+	else
+		kleave("= %ld [buffer too small]", ret);
+	return ret;
 }
 
 /*

[PATCH 4.4 05/40] KEYS: fix out-of-bounds read during ASN.1 parsing

[Greg Kroah-Hartman]

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

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

From: Eric Biggers <ebiggers@google.com>

commit 2eb9eabf1e868fda15808954fb29b0f105ed65f1 upstream.

syzkaller with KASAN reported an out-of-bounds read in
asn1_ber_decoder().  It can be reproduced by the following command,
assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y:

    keyctl add asymmetric desc $'\x30\x30' @s

The bug is that the length of an ASN.1 data value isn't validated in the
case where it is encoded using the short form, causing the decoder to
read past the end of the input buffer.  Fix it by validating the length.

The bug report was:

    BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
    Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818

    CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447d983 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:16 [inline]
     dump_stack+0xb3/0x10b lib/dump_stack.c:52
     print_address_description+0x79/0x2a0 mm/kasan/report.c:252
     kasan_report_error mm/kasan/report.c:351 [inline]
     kasan_report+0x236/0x340 mm/kasan/report.c:409
     __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
     asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
     x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89
     x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174
     asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388
     key_create_or_update+0x347/0xb20 security/keys/key.c:855
     SYSC_add_key security/keys/keyctl.c:122 [inline]
     SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62
     entry_SYSCALL_64_fastpath+0x1f/0xbe
    RIP: 0033:0x447c89
    RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
    RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89
    RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5
    RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000
    R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000
    R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700

Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 lib/asn1_decoder.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/lib/asn1_decoder.c
+++ b/lib/asn1_decoder.c
@@ -283,6 +283,9 @@ next_op:
 				if (unlikely(len > datalen - dp))
 					goto data_overrun_error;
 			}
+		} else {
+			if (unlikely(len > datalen - dp))
+				goto data_overrun_error;
 		}
 
 		if (flags & FLAG_CONS) {

[PATCH 4.4 06/40] ASoC: adau17x1: Workaround for noise bug in ADC

[Greg Kroah-Hartman]

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

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

From: Ricard Wanderlof <ricard.wanderlof@axis.com>

commit 1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 upstream.

The ADC in the ADAU1361 (and possibly other Analog Devices codecs)
exhibits a cyclic variation in the noise floor (in our test setup between
-87 and -93 dB), a new value being attained within this range whenever a
new capture stream is started. The cycle repeats after about 10 or 11
restarts.

The workaround recommended by the manufacturer is to toggle the ADOSR bit
in the Converter Control 0 register each time a new capture stream is
started.

I have verified that the patch fixes this problem on the ADAU1361, and
according to the manufacturer toggling the bit in question in this manner
will at least have no detrimental effect on other chips served by this
driver.

Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/codecs/adau17x1.c |   24 +++++++++++++++++++++++-
 sound/soc/codecs/adau17x1.h |    2 ++
 2 files changed, 25 insertions(+), 1 deletion(-)

--- a/sound/soc/codecs/adau17x1.c
+++ b/sound/soc/codecs/adau17x1.c
@@ -89,6 +89,27 @@ static int adau17x1_pll_event(struct snd
 	return 0;
 }
 
+static int adau17x1_adc_fixup(struct snd_soc_dapm_widget *w,
+	struct snd_kcontrol *kcontrol, int event)
+{
+	struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
+	struct adau *adau = snd_soc_codec_get_drvdata(codec);
+
+	/*
+	 * If we are capturing, toggle the ADOSR bit in Converter Control 0 to
+	 * avoid losing SNR (workaround from ADI). This must be done after
+	 * the ADC(s) have been enabled. According to the data sheet, it is
+	 * normally illegal to set this bit when the sampling rate is 96 kHz,
+	 * but according to ADI it is acceptable for this workaround.
+	 */
+	regmap_update_bits(adau->regmap, ADAU17X1_CONVERTER0,
+		ADAU17X1_CONVERTER0_ADOSR, ADAU17X1_CONVERTER0_ADOSR);
+	regmap_update_bits(adau->regmap, ADAU17X1_CONVERTER0,
+		ADAU17X1_CONVERTER0_ADOSR, 0);
+
+	return 0;
+}
+
 static const char * const adau17x1_mono_stereo_text[] = {
 	"Stereo",
 	"Mono Left Channel (L+R)",
@@ -120,7 +141,8 @@ static const struct snd_soc_dapm_widget
 	SND_SOC_DAPM_MUX("Right DAC Mode Mux", SND_SOC_NOPM, 0, 0,
 		&adau17x1_dac_mode_mux),
 
-	SND_SOC_DAPM_ADC("Left Decimator", NULL, ADAU17X1_ADC_CONTROL, 0, 0),
+	SND_SOC_DAPM_ADC_E("Left Decimator", NULL, ADAU17X1_ADC_CONTROL, 0, 0,
+			   adau17x1_adc_fixup, SND_SOC_DAPM_POST_PMU),
 	SND_SOC_DAPM_ADC("Right Decimator", NULL, ADAU17X1_ADC_CONTROL, 1, 0),
 	SND_SOC_DAPM_DAC("Left DAC", NULL, ADAU17X1_DAC_CONTROL0, 0, 0),
 	SND_SOC_DAPM_DAC("Right DAC", NULL, ADAU17X1_DAC_CONTROL0, 1, 0),
--- a/sound/soc/codecs/adau17x1.h
+++ b/sound/soc/codecs/adau17x1.h
@@ -123,5 +123,7 @@ bool adau17x1_has_dsp(struct adau *adau)
 
 #define ADAU17X1_CONVERTER0_CONVSR_MASK		0x7
 
+#define ADAU17X1_CONVERTER0_ADOSR		BIT(3)
+
 
 #endif

[PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Greg Kroah-Hartman]

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

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

From: Mark Rutland <mark.rutland@arm.com>

commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.

It's possible for a user to deliberately trigger __dump_instr with a
chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

Where we use __dump_instr() on kernel text, we already switch to
KERNEL_DS, so this shouldn't adversely affect those cases.

Fixes: 60ffc30d5652810d ("arm64: Exception handling")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/kernel/traps.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -129,7 +129,7 @@ static void dump_instr(const char *lvl,
 	for (i = -4; i < 1; i++) {
 		unsigned int val, bad;
 
-		bad = __get_user(val, &((u32 *)addr)[i]);
+		bad = get_user(val, &((u32 *)addr)[i]);
 
 		if (!bad)
 			p += sprintf(p, i == 0 ? "(%08x) " : "%08x ", val);

[PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill

[Greg Kroah-Hartman]

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

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

From: Yan Markman <ymarkman@marvell.com>

commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.

Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.

The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.

Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.

Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
Signed-off-by: Yan Markman <ymarkman@marvell.com>
Signed-off-by: Igal Liberman <igall@marvell.com>
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
[gregory.clement@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/boot/dts/armada-375.dtsi |    4 ++--
 arch/arm/boot/dts/armada-38x.dtsi |    4 ++--
 arch/arm/boot/dts/armada-39x.dtsi |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -176,9 +176,9 @@
 				reg = <0x8000 0x1000>;
 				cache-unified;
 				cache-level = <2>;
-				arm,double-linefill-incr = <1>;
+				arm,double-linefill-incr = <0>;
 				arm,double-linefill-wrap = <0>;
-				arm,double-linefill = <1>;
+				arm,double-linefill = <0>;
 				prefetch-data = <1>;
 			};
 
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -143,9 +143,9 @@
 				reg = <0x8000 0x1000>;
 				cache-unified;
 				cache-level = <2>;
-				arm,double-linefill-incr = <1>;
+				arm,double-linefill-incr = <0>;
 				arm,double-linefill-wrap = <0>;
-				arm,double-linefill = <1>;
+				arm,double-linefill = <0>;
 				prefetch-data = <1>;
 			};
 
--- a/arch/arm/boot/dts/armada-39x.dtsi
+++ b/arch/arm/boot/dts/armada-39x.dtsi
@@ -104,9 +104,9 @@
 				reg = <0x8000 0x1000>;
 				cache-unified;
 				cache-level = <2>;
-				arm,double-linefill-incr = <1>;
+				arm,double-linefill-incr = <0>;
 				arm,double-linefill-wrap = <0>;
-				arm,double-linefill = <1>;
+				arm,double-linefill = <0>;
 				prefetch-data = <1>;
 			};
 

[PATCH 4.4 09/40] ARM: 8715/1: add a private asm/unaligned.h

[Greg Kroah-Hartman]

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

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

From: Arnd Bergmann <arnd@arndb.de>

commit 1cce91dfc8f7990ca3aea896bfb148f240b12860 upstream.

The asm-generic/unaligned.h header provides two different implementations
for accessing unaligned variables: the access_ok.h version used when
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers
are in fact aligned, while the le_struct.h version convinces gcc that the
alignment of a pointer is '1', to make it issue the correct load/store
instructions depending on the architecture flags.

On ARMv5 and older, we always use the second version, to let the compiler
use byte accesses. On ARMv6 and newer, we currently use the access_ok.h
version, so the compiler can use any instruction including stm/ldm and
ldrd/strd that will cause an alignment trap. This trap can significantly
impact performance when we have to do a lot of fixups and, worse, has
led to crashes in the LZ4 decompressor code that does not have a trap
handler.

This adds an ARM specific version of asm/unaligned.h that uses the
le_struct.h/be_struct.h implementation unconditionally. This should lead
to essentially the same code on ARMv6+ as before, with the exception of
using regular load/store instructions instead of the trapping instructions
multi-register variants.

The crash in the LZ4 decompressor code was probably introduced by the
patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update
LZ4 compressor module"), so linux-4.11 and higher would be affected most.
However, we probably want to have this backported to all older stable
kernels as well, to help with the performance issues.

There are two follow-ups that I think we should also work on, but not
backport to stable kernels, first to change the asm-generic version of
the header to remove the ARM special case, and second to review all
other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they
might be affected by the same problem on ARM.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/include/asm/Kbuild      |    1 -
 arch/arm/include/asm/unaligned.h |   27 +++++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -36,4 +36,3 @@ generic-y += termbits.h
 generic-y += termios.h
 generic-y += timex.h
 generic-y += trace_clock.h
-generic-y += unaligned.h
--- /dev/null
+++ b/arch/arm/include/asm/unaligned.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_ARM_UNALIGNED_H
+#define __ASM_ARM_UNALIGNED_H
+
+/*
+ * We generally want to set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS on ARMv6+,
+ * but we don't want to use linux/unaligned/access_ok.h since that can lead
+ * to traps on unaligned stm/ldm or strd/ldrd.
+ */
+#include <asm/byteorder.h>
+
+#if defined(__LITTLE_ENDIAN)
+# include <linux/unaligned/le_struct.h>
+# include <linux/unaligned/be_byteshift.h>
+# include <linux/unaligned/generic.h>
+# define get_unaligned	__get_unaligned_le
+# define put_unaligned	__put_unaligned_le
+#elif defined(__BIG_ENDIAN)
+# include <linux/unaligned/be_struct.h>
+# include <linux/unaligned/le_byteshift.h>
+# include <linux/unaligned/generic.h>
+# define get_unaligned	__get_unaligned_be
+# define put_unaligned	__put_unaligned_be
+#else
+# error need to define endianess
+#endif
+
+#endif /* __ASM_ARM_UNALIGNED_H */

[PATCH 4.4 10/40] ocfs2: fstrim: Fix start offset of first cluster group during fstrim

[Greg Kroah-Hartman]

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

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

From: Ashish Samant <ashish.samant@oracle.com>

commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream.

The first cluster group descriptor is not stored at the start of the
group but at an offset from the start.  We need to take this into
account while doing fstrim on the first cluster group.  Otherwise we
will wrongly start fstrim a few blocks after the desired start block and
the range can cross over into the next cluster group and zero out the
group descriptor there.  This can cause filesytem corruption that cannot
be fixed by fsck.

Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com
Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/ocfs2/alloc.c |   24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -7270,13 +7270,24 @@ out:
 
 static int ocfs2_trim_extent(struct super_block *sb,
 			     struct ocfs2_group_desc *gd,
-			     u32 start, u32 count)
+			     u64 group, u32 start, u32 count)
 {
 	u64 discard, bcount;
+	struct ocfs2_super *osb = OCFS2_SB(sb);
 
 	bcount = ocfs2_clusters_to_blocks(sb, count);
-	discard = le64_to_cpu(gd->bg_blkno) +
-			ocfs2_clusters_to_blocks(sb, start);
+	discard = ocfs2_clusters_to_blocks(sb, start);
+
+	/*
+	 * For the first cluster group, the gd->bg_blkno is not at the start
+	 * of the group, but at an offset from the start. If we add it while
+	 * calculating discard for first group, we will wrongly start fstrim a
+	 * few blocks after the desried start block and the range can cross
+	 * over into the next cluster group. So, add it only if this is not
+	 * the first cluster group.
+	 */
+	if (group != osb->first_cluster_group_blkno)
+		discard += le64_to_cpu(gd->bg_blkno);
 
 	trace_ocfs2_trim_extent(sb, (unsigned long long)discard, bcount);
 
@@ -7284,7 +7295,7 @@ static int ocfs2_trim_extent(struct supe
 }
 
 static int ocfs2_trim_group(struct super_block *sb,
-			    struct ocfs2_group_desc *gd,
+			    struct ocfs2_group_desc *gd, u64 group,
 			    u32 start, u32 max, u32 minbits)
 {
 	int ret = 0, count = 0, next;
@@ -7303,7 +7314,7 @@ static int ocfs2_trim_group(struct super
 		next = ocfs2_find_next_bit(bitmap, max, start);
 
 		if ((next - start) >= minbits) {
-			ret = ocfs2_trim_extent(sb, gd,
+			ret = ocfs2_trim_extent(sb, gd, group,
 						start, next - start);
 			if (ret < 0) {
 				mlog_errno(ret);
@@ -7401,7 +7412,8 @@ int ocfs2_trim_fs(struct super_block *sb
 		}
 
 		gd = (struct ocfs2_group_desc *)gd_bh->b_data;
-		cnt = ocfs2_trim_group(sb, gd, first_bit, last_bit, minlen);
+		cnt = ocfs2_trim_group(sb, gd, group,
+				       first_bit, last_bit, minlen);
 		brelse(gd_bh);
 		gd_bh = NULL;
 		if (cnt < 0) {

[PATCH 4.4 11/40] perf tools: Fix build failure on perl script context

[Greg Kroah-Hartman]

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

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

From: Namhyung Kim <namhyung@kernel.org>

commit b581c01fff646b5075d65359c8667de9c667da9e upstream.

On my Archlinux machine, perf faild to build like below:

    CC       scripts/perl/Perf-Trace-Util/Context.o
  In file included from /usr/lib/perl5/core/perl/CORE/perl.h:3905:0,
                   from Context.xs:23:
  /usr/lib/perl5/core/perl/CORE/inline.h: In function :
  /usr/lib/perl5/core/perl/CORE/cop.h:612:13: warning: declaration of 'av'
                                  shadows a previous local [-Werror-shadow]
             AV *av =3D GvAV(PL_defgv);
                 ^
  /usr/lib/perl5/core/perl/CORE/inline.h:526:5: note: in expansion of
                                  macro 'CX_POP_SAVEARRAY'
         CX_POP_SAVEARRAY(cx);
         ^~~~~~~~~~~~~~~~
  In file included from /usr/lib/perl5/core/perl/CORE/perl.h:5853:0,
                   from Context.xs:23:
  /usr/lib/perl5/core/perl/CORE/inline.h:518:9: note:
                                  shadowed declaration is here
         AV *av;
             ^~

What I did to fix is adding '-Wno-shadow' as the error message said it's
the cause of the failure.  Since it's from the perl (not perf) code
base, we don't have the control so I just wanted to ignore the warning
when compiling perl scripting code.

Committer note:

This also fixes the build on Fedora Rawhide.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160802024317.31725-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/perf/scripts/perl/Perf-Trace-Util/Build |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/tools/perf/scripts/perl/Perf-Trace-Util/Build
+++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build
@@ -1,3 +1,5 @@
 libperf-y += Context.o
 
-CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs -Wno-undef -Wno-switch-default
+CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes
+CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef
+CFLAGS_Context.o += -Wno-switch-default -Wno-shadow

[PATCH 4.4 12/40] drm/msm: Fix potential buffer overflow issue

[Greg Kroah-Hartman]

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

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

From: Kasin Li <donglil@codeaurora.org>

commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream.

In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.

Signed-off-by: Kasin Li <donglil@codeaurora.org>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -34,10 +34,13 @@ static inline void __user *to_user_ptr(u
 }
 
 static struct msm_gem_submit *submit_create(struct drm_device *dev,
-		struct msm_gpu *gpu, int nr)
+		struct msm_gpu *gpu, uint32_t int nr)
 {
 	struct msm_gem_submit *submit;
-	int sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+	uint64_t sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+
+	if (sz > SIZE_MAX)
+		return NULL;
 
 	submit = kmalloc(sz, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
 	if (submit) {

[PATCH 4.4 13/40] drm/msm: fix an integer overflow test

[Greg Kroah-Hartman]

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

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

From: Dan Carpenter <dan.carpenter@oracle.com>

commit 65e93108891e571f177c202add9288eda9ac4100 upstream.

We recently added an integer overflow check but it needs an additional
tweak to work properly on 32 bit systems.

The problem is that we're doing the right hand side of the assignment as
type unsigned long so the max it will have an integer overflow instead
of being larger than SIZE_MAX.  That means the "sz > SIZE_MAX" condition
is never true even on 32 bit systems.  We need to first cast it to u64
and then do the math.

Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/msm/msm_gem_submit.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -37,7 +37,7 @@ static struct msm_gem_submit *submit_cre
 		struct msm_gpu *gpu, uint32_t int nr)
 {
 	struct msm_gem_submit *submit;
-	uint64_t sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+	uint64_t sz = sizeof(*submit) + ((u64)nr * sizeof(submit->bos[0]));
 
 	if (sz > SIZE_MAX)
 		return NULL;

[PATCH 4.4 14/40] tracing/samples: Fix creation and deletion of simple_thread_fn creation

[Greg Kroah-Hartman]

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

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

From: Steven Rostedt (VMware) <rostedt@goodmis.org>

commit 6575257c60e1a26a5319ccf2b5ce5b6449001017 upstream.

Commit 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and
DEFINE_EVENT()") added template examples for all the events. It created a
DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg
functions.

Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace
events caused the foo_bar_reg to be called twice, creating the test thread
twice. The foo_bar_unreg would remove it only once, even if it was called
multiple times, leaving a thread existing when the module is unloaded,
causing an oops.

Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by
multiple trace events.

Fixes: 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 samples/trace_events/trace-events-sample.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/samples/trace_events/trace-events-sample.c
+++ b/samples/trace_events/trace-events-sample.c
@@ -78,28 +78,36 @@ static int simple_thread_fn(void *arg)
 }
 
 static DEFINE_MUTEX(thread_mutex);
+static bool simple_thread_cnt;
 
 void foo_bar_reg(void)
 {
+	mutex_lock(&thread_mutex);
+	if (simple_thread_cnt++)
+		goto out;
+
 	pr_info("Starting thread for foo_bar_fn\n");
 	/*
 	 * We shouldn't be able to start a trace when the module is
 	 * unloading (there's other locks to prevent that). But
 	 * for consistency sake, we still take the thread_mutex.
 	 */
-	mutex_lock(&thread_mutex);
 	simple_tsk_fn = kthread_run(simple_thread_fn, NULL, "event-sample-fn");
+ out:
 	mutex_unlock(&thread_mutex);
 }
 
 void foo_bar_unreg(void)
 {
-	pr_info("Killing thread for foo_bar_fn\n");
-	/* protect against module unloading */
 	mutex_lock(&thread_mutex);
+	if (--simple_thread_cnt)
+		goto out;
+
+	pr_info("Killing thread for foo_bar_fn\n");
 	if (simple_tsk_fn)
 		kthread_stop(simple_tsk_fn);
 	simple_tsk_fn = NULL;
+ out:
 	mutex_unlock(&thread_mutex);
 }
 

[PATCH 4.4 15/40] Fix tracing sample code warning.

[Greg Kroah-Hartman]

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

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

From: Linus Torvalds <torvalds@linux-foundation.org>

commit a0cb2b5c390151837b08e5f7bca4a6ecddbcd39c upstream.

Commit 6575257c60e1 ("tracing/samples: Fix creation and deletion of
simple_thread_fn creation") introduced a new warning due to using a
boolean as a counter.

Just make it "int".

Fixes: 6575257c60e1 ("tracing/samples: Fix creation and deletion of simple_thread_fn creation")
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 samples/trace_events/trace-events-sample.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/samples/trace_events/trace-events-sample.c
+++ b/samples/trace_events/trace-events-sample.c
@@ -78,7 +78,7 @@ static int simple_thread_fn(void *arg)
 }
 
 static DEFINE_MUTEX(thread_mutex);
-static bool simple_thread_cnt;
+static int simple_thread_cnt;
 
 void foo_bar_reg(void)
 {

[PATCH 4.4 16/40] PM / wakeirq: report a wakeup_event on dedicated wekup irq

[Greg Kroah-Hartman]

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

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

From: Grygorii Strashko <grygorii.strashko@ti.com>


[ Upstream commit 09bb6e93956ae5175b96905b723ec879c3ca0765 ]

There are two reasons for reporting wakeup event when dedicated wakeup
IRQ is triggered:

- wakeup events accounting, so proper statistical data will be
  displayed in sysfs and debugfs;

- there are small window when System is entering suspend during which
  dedicated wakeup IRQ can be lost:

dpm_suspend_noirq()
  |- device_wakeup_arm_wake_irqs()
      |- dev_pm_arm_wake_irq(X)
         |- IRQ is enabled and marked as wakeup source
[1]...
  |- suspend_device_irqs()
     |- suspend_device_irq(X)
	|- irqd_set(X, IRQD_WAKEUP_ARMED);
	   |- wakup IRQ armed

The wakeup IRQ can be lost if it's triggered at point [1]
and not armed yet.

Hence, fix above cases by adding simple pm_wakeup_event() call in
handle_threaded_wake_irq().

Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
[ tony@atomide.com: added missing return to avoid warnings ]
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/base/power/wakeirq.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/base/power/wakeirq.c
+++ b/drivers/base/power/wakeirq.c
@@ -141,6 +141,13 @@ static irqreturn_t handle_threaded_wake_
 	struct wake_irq *wirq = _wirq;
 	int res;
 
+	/* Maybe abort suspend? */
+	if (irqd_is_wakeup_set(irq_get_irq_data(irq))) {
+		pm_wakeup_event(wirq->dev, 0);
+
+		return IRQ_HANDLED;
+	}
+
 	/* We don't want RPM_ASYNC or RPM_NOWAIT here */
 	res = pm_runtime_resume(wirq->dev);
 	if (res < 0)

[PATCH 4.4 17/40] mmc: s3cmci: include linux/interrupt.h for tasklet_struct

[Greg Kroah-Hartman]

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

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

From: Arnd Bergmann <arnd@arndb.de>


[ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ]

I got this new build error on today's linux-next

drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
  struct tasklet_struct pio_tasklet;
drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]

While I haven't found out why this happened now and not earlier, the
solution is obvious, we should include the header that defines
the structure.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/mmc/host/s3cmci.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -21,6 +21,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include <linux/gpio.h>
+#include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/io.h>
 

[PATCH 4.4 18/40] ARM: pxa: Dont rely on public mmc header to include leds.h

[Greg Kroah-Hartman]

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

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

From: Ulf Hansson <ulf.hansson@linaro.org>


[ Upstream commit 40d727a2defa176b78159d445bcf7afcc2ed9021 ]

Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.

Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/arm/mach-pxa/balloon3.c              |    1 +
 arch/arm/mach-pxa/colibri-pxa270-income.c |    1 +
 arch/arm/mach-pxa/corgi.c                 |    1 +
 arch/arm/mach-pxa/trizeps4.c              |    1 +
 arch/arm/mach-pxa/vpac270.c               |    1 +
 arch/arm/mach-pxa/zeus.c                  |    1 +
 arch/arm/mach-pxa/zylonite.c              |    1 +
 7 files changed, 7 insertions(+)

--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -17,6 +17,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/sched.h>
 #include <linux/bitops.h>
 #include <linux/fb.h>
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -17,6 +17,7 @@
 #include <linux/gpio.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -18,6 +18,7 @@
 #include <linux/major.h>
 #include <linux/fs.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/mmc/host.h>
 #include <linux/mtd/physmap.h>
 #include <linux/pm.h>
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/export.h>
 #include <linux/sched.h>
 #include <linux/bitops.h>
--- a/arch/arm/mach-pxa/vpac270.c
+++ b/arch/arm/mach-pxa/vpac270.c
@@ -15,6 +15,7 @@
 #include <linux/irq.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
+#include <linux/leds.h>
 #include <linux/gpio.h>
 #include <linux/usb/gpio_vbus.h>
 #include <linux/mtd/mtd.h>
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -13,6 +13,7 @@
 
 #include <linux/cpufreq.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/irq.h>
 #include <linux/pm.h>
 #include <linux/gpio.h>
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>

[PATCH 4.4 18/40] ARM: pxa: Dont rely on public mmc header to include leds.h

[Greg Kroah-Hartman]

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

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

From: Ulf Hansson <ulf.hansson@linaro.org>


[ Upstream commit 40d727a2defa176b78159d445bcf7afcc2ed9021 ]

Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.

Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/arm/mach-pxa/balloon3.c              |    1 +
 arch/arm/mach-pxa/colibri-pxa270-income.c |    1 +
 arch/arm/mach-pxa/corgi.c                 |    1 +
 arch/arm/mach-pxa/trizeps4.c              |    1 +
 arch/arm/mach-pxa/vpac270.c               |    1 +
 arch/arm/mach-pxa/zeus.c                  |    1 +
 arch/arm/mach-pxa/zylonite.c              |    1 +
 7 files changed, 7 insertions(+)

--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -17,6 +17,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/sched.h>
 #include <linux/bitops.h>
 #include <linux/fb.h>
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -17,6 +17,7 @@
 #include <linux/gpio.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -18,6 +18,7 @@
 #include <linux/major.h>
 #include <linux/fs.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/mmc/host.h>
 #include <linux/mtd/physmap.h>
 #include <linux/pm.h>
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/export.h>
 #include <linux/sched.h>
 #include <linux/bitops.h>
--- a/arch/arm/mach-pxa/vpac270.c
+++ b/arch/arm/mach-pxa/vpac270.c
@@ -15,6 +15,7 @@
 #include <linux/irq.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
+#include <linux/leds.h>
 #include <linux/gpio.h>
 #include <linux/usb/gpio_vbus.h>
 #include <linux/mtd/mtd.h>
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -13,6 +13,7 @@
 
 #include <linux/cpufreq.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/irq.h>
 #include <linux/pm.h>
 #include <linux/gpio.h>
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
+#include <linux/leds.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>

[PATCH 4.4 19/40] mfd: ab8500-sysctrl: Handle probe deferral

[Greg Kroah-Hartman]

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

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

From: Linus Walleij <linus.walleij@linaro.org>


[ Upstream commit 7e9c40c63933a643908d686bd89dfc2315e8c70a ]

In the current boot, clients making use of the AB8500 sysctrl
may be probed before the ab8500-sysctrl driver. This gives them
-EINVAL, but should rather give -EPROBE_DEFER.

Before this, the abx500 clock driver didn't probe properly,
and as a result the codec driver in turn using the clocks did
not probe properly. After this patch, everything probes
properly.

Also add OF compatible-string probing. This driver is all
device tree, so let's just make a drive-by-fix of that as
well.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/mfd/ab8500-sysctrl.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -99,7 +99,7 @@ int ab8500_sysctrl_read(u16 reg, u8 *val
 	u8 bank;
 
 	if (sysctrl_dev == NULL)
-		return -EINVAL;
+		return -EPROBE_DEFER;
 
 	bank = (reg >> 8);
 	if (!valid_bank(bank))
@@ -115,11 +115,13 @@ int ab8500_sysctrl_write(u16 reg, u8 mas
 	u8 bank;
 
 	if (sysctrl_dev == NULL)
-		return -EINVAL;
+		return -EPROBE_DEFER;
 
 	bank = (reg >> 8);
-	if (!valid_bank(bank))
+	if (!valid_bank(bank)) {
+		pr_err("invalid bank\n");
 		return -EINVAL;
+	}
 
 	return abx500_mask_and_set_register_interruptible(sysctrl_dev, bank,
 		(u8)(reg & 0xFF), mask, value);
@@ -180,9 +182,15 @@ static int ab8500_sysctrl_remove(struct
 	return 0;
 }
 
+static const struct of_device_id ab8500_sysctrl_match[] = {
+	{ .compatible = "stericsson,ab8500-sysctrl", },
+	{}
+};
+
 static struct platform_driver ab8500_sysctrl_driver = {
 	.driver = {
 		.name = "ab8500-sysctrl",
+		.of_match_table = ab8500_sysctrl_match,
 	},
 	.probe = ab8500_sysctrl_probe,
 	.remove = ab8500_sysctrl_remove,

[PATCH 4.4 20/40] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped

[Greg Kroah-Hartman]

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

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

From: Hans de Goede <hdegoede@redhat.com>


[ Upstream commit 1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ]

The R in PEK_DBR stands for rising, so it should be mapped to
AXP288_IRQ_POKP where the last P stands for positive edge.

Likewise PEK_DBF should be mapped to the falling edge, aka the
_N_egative edge, so it should be mapped to AXP288_IRQ_POKN.

This fixes the inverted powerbutton status reporting by the
axp20x-pek driver.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/mfd/axp20x.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -164,14 +164,14 @@ static struct resource axp22x_pek_resour
 static struct resource axp288_power_button_resources[] = {
 	{
 		.name	= "PEK_DBR",
-		.start	= AXP288_IRQ_POKN,
-		.end	= AXP288_IRQ_POKN,
+		.start	= AXP288_IRQ_POKP,
+		.end	= AXP288_IRQ_POKP,
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
 		.name	= "PEK_DBF",
-		.start	= AXP288_IRQ_POKP,
-		.end	= AXP288_IRQ_POKP,
+		.start	= AXP288_IRQ_POKN,
+		.end	= AXP288_IRQ_POKN,
 		.flags	= IORESOURCE_IRQ,
 	},
 };

[PATCH 4.4 21/40] staging: rtl8712u: Fix endian settings for structs describing network packets

[Greg Kroah-Hartman]

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

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

From: Larry Finger <Larry.Finger@lwfinger.net>


[ Upstream commit 221c46d28957bd6e2158abc2179ce4a8c9ce07d3 ]

The headers describing a number of network packets do not have the
correct endian settings for several types of data.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/rtl8712/ieee80211.h |   84 ++++++++++++++++++------------------
 1 file changed, 42 insertions(+), 42 deletions(-)

--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -143,52 +143,52 @@ struct ieee_ibss_seq {
 };
 
 struct ieee80211_hdr {
-	u16 frame_ctl;
-	u16 duration_id;
+	__le16 frame_ctl;
+	__le16 duration_id;
 	u8 addr1[ETH_ALEN];
 	u8 addr2[ETH_ALEN];
 	u8 addr3[ETH_ALEN];
-	u16 seq_ctl;
+	__le16 seq_ctl;
 	u8 addr4[ETH_ALEN];
-} __packed;
+}  __packed __aligned(2);
 
 struct ieee80211_hdr_3addr {
-	u16 frame_ctl;
-	u16 duration_id;
+	__le16 frame_ctl;
+	__le16 duration_id;
 	u8 addr1[ETH_ALEN];
 	u8 addr2[ETH_ALEN];
 	u8 addr3[ETH_ALEN];
-	u16 seq_ctl;
-} __packed;
+	__le16 seq_ctl;
+}  __packed __aligned(2);
 
 
 struct	ieee80211_hdr_qos {
-	u16 frame_ctl;
-	u16 duration_id;
+	__le16 frame_ctl;
+	__le16 duration_id;
 	u8 addr1[ETH_ALEN];
 	u8 addr2[ETH_ALEN];
 	u8 addr3[ETH_ALEN];
-	u16 seq_ctl;
+	__le16 seq_ctl;
 	u8 addr4[ETH_ALEN];
-	u16	qc;
-}  __packed;
+	__le16	qc;
+}   __packed __aligned(2);
 
 struct  ieee80211_hdr_3addr_qos {
-	u16 frame_ctl;
-	u16 duration_id;
+	__le16 frame_ctl;
+	__le16 duration_id;
 	u8  addr1[ETH_ALEN];
 	u8  addr2[ETH_ALEN];
 	u8  addr3[ETH_ALEN];
-	u16 seq_ctl;
-	u16 qc;
+	__le16 seq_ctl;
+	__le16 qc;
 }  __packed;
 
 struct eapol {
 	u8 snap[6];
-	u16 ethertype;
+	__be16 ethertype;
 	u8 version;
 	u8 type;
-	u16 length;
+	__le16 length;
 } __packed;
 
 
@@ -528,13 +528,13 @@ struct ieee80211_security {
  */
 
 struct ieee80211_header_data {
-	u16 frame_ctl;
-	u16 duration_id;
+	__le16 frame_ctl;
+	__le16 duration_id;
 	u8 addr1[6];
 	u8 addr2[6];
 	u8 addr3[6];
-	u16 seq_ctrl;
-};
+	__le16 seq_ctrl;
+} __packed __aligned(2);
 
 #define BEACON_PROBE_SSID_ID_POSITION 12
 
@@ -566,18 +566,18 @@ struct ieee80211_info_element {
 /*
  * These are the data types that can make up management packets
  *
-	u16 auth_algorithm;
-	u16 auth_sequence;
-	u16 beacon_interval;
-	u16 capability;
+	__le16 auth_algorithm;
+	__le16 auth_sequence;
+	__le16 beacon_interval;
+	__le16 capability;
 	u8 current_ap[ETH_ALEN];
-	u16 listen_interval;
+	__le16 listen_interval;
 	struct {
 		u16 association_id:14, reserved:2;
 	} __packed;
-	u32 time_stamp[2];
-	u16 reason;
-	u16 status;
+	__le32 time_stamp[2];
+	__le16 reason;
+	__le16 status;
 */
 
 #define IEEE80211_DEFAULT_TX_ESSID "Penguin"
@@ -585,16 +585,16 @@ struct ieee80211_info_element {
 
 struct ieee80211_authentication {
 	struct ieee80211_header_data header;
-	u16 algorithm;
-	u16 transaction;
-	u16 status;
+	__le16 algorithm;
+	__le16 transaction;
+	__le16 status;
 } __packed;
 
 struct ieee80211_probe_response {
 	struct ieee80211_header_data header;
-	u32 time_stamp[2];
-	u16 beacon_interval;
-	u16 capability;
+	__le32 time_stamp[2];
+	__le16 beacon_interval;
+	__le16 capability;
 	struct ieee80211_info_element info_element;
 } __packed;
 
@@ -604,16 +604,16 @@ struct ieee80211_probe_request {
 
 struct ieee80211_assoc_request_frame {
 	struct ieee80211_hdr_3addr header;
-	u16 capability;
-	u16 listen_interval;
+	__le16 capability;
+	__le16 listen_interval;
 	struct ieee80211_info_element_hdr info_element;
 } __packed;
 
 struct ieee80211_assoc_response_frame {
 	struct ieee80211_hdr_3addr header;
-	u16 capability;
-	u16 status;
-	u16 aid;
+	__le16 capability;
+	__le16 status;
+	__le16 aid;
 } __packed;
 
 struct ieee80211_txb {

[PATCH 4.4 22/40] ext4: fix stripe-unaligned allocations

[Greg Kroah-Hartman]

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

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

From: Jan Kara <jack@suse.cz>


[ Upstream commit d9b22cf9f5466a057f2a4f1e642b469fa9d73117 ]

When a filesystem is created using:

	mkfs.ext4 -b 4096 -E stride=512 <dev>

and we try to allocate 64MB extent, we will end up directly in
ext4_mb_complex_scan_group(). This is because the request is detected
as power-of-two allocation (so we start in ext4_mb_regular_allocator()
with ac_criteria == 0) however the check before
ext4_mb_simple_scan_group() refuses the direct buddy scan because the
allocation request is too large. Since cr == 0, the check whether we
should use ext4_mb_scan_aligned() fails as well and we fall back to
ext4_mb_complex_scan_group().

Fix the problem by checking for upper limit on power-of-two requests
directly when detecting them.

Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/ext4/mballoc.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2136,8 +2136,10 @@ ext4_mb_regular_allocator(struct ext4_al
 	 * We search using buddy data only if the order of the request
 	 * is greater than equal to the sbi_s_mb_order2_reqs
 	 * You can tune it via /sys/fs/ext4/<partition>/mb_order2_req
+	 * We also support searching for power-of-two requests only for
+	 * requests upto maximum buddy size we have constructed.
 	 */
-	if (i >= sbi->s_mb_order2_reqs) {
+	if (i >= sbi->s_mb_order2_reqs && i <= sb->s_blocksize_bits + 2) {
 		/*
 		 * This should tell if fe_len is exactly power of 2
 		 */
@@ -2207,7 +2209,7 @@ repeat:
 			}
 
 			ac->ac_groups_scanned++;
-			if (cr == 0 && ac->ac_2order < sb->s_blocksize_bits+2)
+			if (cr == 0)
 				ext4_mb_simple_scan_group(ac, &e4b);
 			else if (cr == 1 && sbi->s_stripe &&
 					!(ac->ac_g_ex.fe_len % sbi->s_stripe))

[PATCH 4.4 23/40] ext4: do not use stripe_width if it is not set

[Greg Kroah-Hartman]

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

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

From: Jan Kara <jack@suse.cz>


[ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ]

Avoid using stripe_width for sbi->s_stripe value if it is not actually
set. It prevents using the stride for sbi->s_stripe.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/ext4/super.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2499,9 +2499,9 @@ static unsigned long ext4_get_stripe_siz
 
 	if (sbi->s_stripe && sbi->s_stripe <= sbi->s_blocks_per_group)
 		ret = sbi->s_stripe;
-	else if (stripe_width <= sbi->s_blocks_per_group)
+	else if (stripe_width && stripe_width <= sbi->s_blocks_per_group)
 		ret = stripe_width;
-	else if (stride <= sbi->s_blocks_per_group)
+	else if (stride && stride <= sbi->s_blocks_per_group)
 		ret = stride;
 	else
 		ret = 0;

[PATCH 4.4 24/40] i2c: riic: correctly finish transfers

[Greg Kroah-Hartman]

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

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

From: Chris Brandt <chris.brandt@renesas.com>


[ Upstream commit 71ccea095ea1d4efd004dab971be6d599e06fc3f ]

This fixes the condition where the controller has not fully completed its
final transfer and leaves the bus and controller in a undesirable state.

At the end of the last transmitted byte, the existing driver would just
signal for a STOP condition to be transmitted then immediately signal
completion. However, the full STOP procedure might not have fully taken
place by the time the runtime PM shuts off the peripheral clock, leaving
the bus in a suspended state.

Alternatively, the STOP condition on the bus may have completed, but when
the next transaction is requested by the upper layer, not all the
necessary register cleanup was finished from the last transfer which made
the driver return BUS BUSY when it really wasn't.

This patch now makes all transmit and receive transactions wait for the
STOP condition to fully complete before signaling a completed transaction.
With this new method, runtime PM no longer seems to be an issue.

Fixes: 310c18a41450 ("i2c: riic: add driver")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/i2c/busses/i2c-riic.c |   30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -80,6 +80,7 @@
 #define ICIER_TEIE	0x40
 #define ICIER_RIE	0x20
 #define ICIER_NAKIE	0x10
+#define ICIER_SPIE	0x08
 
 #define ICSR2_NACKF	0x10
 
@@ -216,11 +217,10 @@ static irqreturn_t riic_tend_isr(int irq
 		return IRQ_NONE;
 	}
 
-	if (riic->is_last || riic->err)
+	if (riic->is_last || riic->err) {
+		riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
 		writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
-
-	writeb(0, riic->base + RIIC_ICIER);
-	complete(&riic->msg_done);
+	}
 
 	return IRQ_HANDLED;
 }
@@ -240,13 +240,13 @@ static irqreturn_t riic_rdrf_isr(int irq
 
 	if (riic->bytes_left == 1) {
 		/* STOP must come before we set ACKBT! */
-		if (riic->is_last)
+		if (riic->is_last) {
+			riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
 			writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
+		}
 
 		riic_clear_set_bit(riic, 0, ICMR3_ACKBT, RIIC_ICMR3);
 
-		writeb(0, riic->base + RIIC_ICIER);
-		complete(&riic->msg_done);
 	} else {
 		riic_clear_set_bit(riic, ICMR3_ACKBT, 0, RIIC_ICMR3);
 	}
@@ -259,6 +259,21 @@ static irqreturn_t riic_rdrf_isr(int irq
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t riic_stop_isr(int irq, void *data)
+{
+	struct riic_dev *riic = data;
+
+	/* read back registers to confirm writes have fully propagated */
+	writeb(0, riic->base + RIIC_ICSR2);
+	readb(riic->base + RIIC_ICSR2);
+	writeb(0, riic->base + RIIC_ICIER);
+	readb(riic->base + RIIC_ICIER);
+
+	complete(&riic->msg_done);
+
+	return IRQ_HANDLED;
+}
+
 static u32 riic_func(struct i2c_adapter *adap)
 {
 	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
@@ -326,6 +341,7 @@ static struct riic_irq_desc riic_irqs[]
 	{ .res_num = 0, .isr = riic_tend_isr, .name = "riic-tend" },
 	{ .res_num = 1, .isr = riic_rdrf_isr, .name = "riic-rdrf" },
 	{ .res_num = 2, .isr = riic_tdre_isr, .name = "riic-tdre" },
+	{ .res_num = 3, .isr = riic_stop_isr, .name = "riic-stop" },
 	{ .res_num = 5, .isr = riic_tend_isr, .name = "riic-nack" },
 };
 

[PATCH 4.4 26/40] perf tools: Only increase index if perf_evsel__new_idx() succeeds

[Greg Kroah-Hartman]

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

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

From: Taeung Song <treeze.taeung@gmail.com>


[ Upstream commit 75fc5ae5cc53fff71041ecadeb3354a2b4c9fe42 ]

Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1485952447-7013-2-git-send-email-treeze.taeung@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 tools/perf/util/parse-events.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -291,10 +291,11 @@ __add_event(struct list_head *list, int
 
 	event_attr_init(attr);
 
-	evsel = perf_evsel__new_idx(attr, (*idx)++);
+	evsel = perf_evsel__new_idx(attr, *idx);
 	if (!evsel)
 		return NULL;
 
+	(*idx)++;
 	evsel->cpus     = cpu_map__get(cpus);
 	evsel->own_cpus = cpu_map__get(cpus);
 

[PATCH 4.4 27/40] cx231xx: Fix I2C on Internal Master 3 Bus

[Greg Kroah-Hartman]

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

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

From: Oleh Kravchenko <oleg@kaa.org.ua>


[ Upstream commit 6c5da8031a3abfad259190d35f83d89568b72ee2 ]

Internal Master 3 Bus can send and receive only 4 bytes per time.

Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/media/usb/cx231xx/cx231xx-core.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/media/usb/cx231xx/cx231xx-core.c
+++ b/drivers/media/usb/cx231xx/cx231xx-core.c
@@ -356,7 +356,12 @@ int cx231xx_send_vendor_cmd(struct cx231
 	 */
 	if ((ven_req->wLength > 4) && ((ven_req->bRequest == 0x4) ||
 					(ven_req->bRequest == 0x5) ||
-					(ven_req->bRequest == 0x6))) {
+					(ven_req->bRequest == 0x6) ||
+
+					/* Internal Master 3 Bus can send
+					 * and receive only 4 bytes per time
+					 */
+					(ven_req->bRequest == 0x2))) {
 		unsend_size = 0;
 		pdata = ven_req->pBuff;
 

[PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge

[Greg Kroah-Hartman]

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

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

From: Archit Taneja <architt@codeaurora.org>


[ Upstream commit 0bb70b82c2f91e4667f3c617505235efd6d77e46 ]

The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.

The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.

msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.

Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.

Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpu/drm/msm/dsi/dsi.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi
 		goto fail;
 	}
 
+	for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
+		msm_dsi->encoders[i] = encoders[i];
+
 	msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
 	if (IS_ERR(msm_dsi->bridge)) {
 		ret = PTR_ERR(msm_dsi->bridge);
@@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi
 		goto fail;
 	}
 
-	for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
-		encoders[i]->bridge = msm_dsi->bridge;
-		msm_dsi->encoders[i] = encoders[i];
-	}
-
 	/*
 	 * check if the dsi encoder output is connected to a panel or an
 	 * external bridge. We create a connector only if we're connected to a

[PATCH 4.4 29/40] xen/manage: correct return value check on xenbus_scanf()

[Greg Kroah-Hartman]

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

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

From: Jan Beulich <JBeulich@suse.com>


[ Upstream commit 4fed1b125eb6252bde478665fc05d4819f774fa8 ]

A negative return value indicates an error; in fact the function at
present won't ever return zero.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/xen/manage.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -275,7 +275,7 @@ static void sysrq_handler(struct xenbus_
 	err = xenbus_transaction_start(&xbt);
 	if (err)
 		return;
-	if (!xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key)) {
+	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
 		pr_err("Unable to read sysrq code in control/sysrq\n");
 		xenbus_transaction_end(xbt, 1);
 		return;

[PATCH 4.4 30/40] scsi: aacraid: Process Error for response I/O

[Greg Kroah-Hartman]

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

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

From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>


[ Upstream commit 4ec57fb4edaec523f0f78a0449a3b063749ac58b ]

Make sure that the driver processes error conditions even in the fast
response path for response from the adapter.

Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Dave Carroll <David.Carroll@microsemi.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/scsi/aacraid/aachba.c |  291 +++++++++++++++++++++---------------------
 1 file changed, 152 insertions(+), 139 deletions(-)

--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -2977,16 +2977,11 @@ static void aac_srb_callback(void *conte
 		return;
 
 	BUG_ON(fibptr == NULL);
-	dev = fibptr->dev;
-
-	scsi_dma_unmap(scsicmd);
 
-	/* expose physical device if expose_physicald flag is on */
-	if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
-	  && expose_physicals > 0)
-		aac_expose_phy_device(scsicmd);
+	dev = fibptr->dev;
 
 	srbreply = (struct aac_srb_reply *) fib_data(fibptr);
+
 	scsicmd->sense_buffer[0] = '\0';  /* Initialize sense valid flag to false */
 
 	if (fibptr->flags & FIB_CONTEXT_FLAG_FASTRESP) {
@@ -2999,158 +2994,176 @@ static void aac_srb_callback(void *conte
 		 */
 		scsi_set_resid(scsicmd, scsi_bufflen(scsicmd)
 				   - le32_to_cpu(srbreply->data_xfer_length));
-		/*
-		 * First check the fib status
-		 */
+	}
 
-		if (le32_to_cpu(srbreply->status) != ST_OK) {
-			int len;
 
-			printk(KERN_WARNING "aac_srb_callback: srb failed, status = %d\n", le32_to_cpu(srbreply->status));
-			len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
-				    SCSI_SENSE_BUFFERSIZE);
-			scsicmd->result = DID_ERROR << 16
-						| COMMAND_COMPLETE << 8
-						| SAM_STAT_CHECK_CONDITION;
-			memcpy(scsicmd->sense_buffer,
-					srbreply->sense_data, len);
-		}
+	scsi_dma_unmap(scsicmd);
 
-		/*
-		 * Next check the srb status
-		 */
-		switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
-		case SRB_STATUS_ERROR_RECOVERY:
-		case SRB_STATUS_PENDING:
-		case SRB_STATUS_SUCCESS:
-			scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
-			break;
-		case SRB_STATUS_DATA_OVERRUN:
-			switch (scsicmd->cmnd[0]) {
-			case  READ_6:
-			case  WRITE_6:
-			case  READ_10:
-			case  WRITE_10:
-			case  READ_12:
-			case  WRITE_12:
-			case  READ_16:
-			case  WRITE_16:
-				if (le32_to_cpu(srbreply->data_xfer_length)
-							< scsicmd->underflow)
-					printk(KERN_WARNING"aacraid: SCSI CMD underflow\n");
-				else
-					printk(KERN_WARNING"aacraid: SCSI CMD Data Overrun\n");
-				scsicmd->result = DID_ERROR << 16
-							| COMMAND_COMPLETE << 8;
-				break;
-			case INQUIRY: {
-				scsicmd->result = DID_OK << 16
-							| COMMAND_COMPLETE << 8;
-				break;
-			}
-			default:
-				scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
-				break;
-			}
-			break;
-		case SRB_STATUS_ABORTED:
-			scsicmd->result = DID_ABORT << 16 | ABORT << 8;
-			break;
-		case SRB_STATUS_ABORT_FAILED:
-			/*
-			 * Not sure about this one - but assuming the
-			 * hba was trying to abort for some reason
-			 */
-			scsicmd->result = DID_ERROR << 16 | ABORT << 8;
-			break;
-		case SRB_STATUS_PARITY_ERROR:
-			scsicmd->result = DID_PARITY << 16
-						| MSG_PARITY_ERROR << 8;
-			break;
-		case SRB_STATUS_NO_DEVICE:
-		case SRB_STATUS_INVALID_PATH_ID:
-		case SRB_STATUS_INVALID_TARGET_ID:
-		case SRB_STATUS_INVALID_LUN:
-		case SRB_STATUS_SELECTION_TIMEOUT:
-			scsicmd->result = DID_NO_CONNECT << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+	/* expose physical device if expose_physicald flag is on */
+	if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
+	  && expose_physicals > 0)
+		aac_expose_phy_device(scsicmd);
 
-		case SRB_STATUS_COMMAND_TIMEOUT:
-		case SRB_STATUS_TIMEOUT:
-			scsicmd->result = DID_TIME_OUT << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+	/*
+	 * First check the fib status
+	 */
 
-		case SRB_STATUS_BUSY:
-			scsicmd->result = DID_BUS_BUSY << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+	if (le32_to_cpu(srbreply->status) != ST_OK) {
+		int len;
 
-		case SRB_STATUS_BUS_RESET:
-			scsicmd->result = DID_RESET << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+		pr_warn("aac_srb_callback: srb failed, status = %d\n",
+				le32_to_cpu(srbreply->status));
+		len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+			    SCSI_SENSE_BUFFERSIZE);
+		scsicmd->result = DID_ERROR << 16
+				| COMMAND_COMPLETE << 8
+				| SAM_STAT_CHECK_CONDITION;
+		memcpy(scsicmd->sense_buffer,
+				srbreply->sense_data, len);
+	}
 
-		case SRB_STATUS_MESSAGE_REJECTED:
+	/*
+	 * Next check the srb status
+	 */
+	switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
+	case SRB_STATUS_ERROR_RECOVERY:
+	case SRB_STATUS_PENDING:
+	case SRB_STATUS_SUCCESS:
+		scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+		break;
+	case SRB_STATUS_DATA_OVERRUN:
+		switch (scsicmd->cmnd[0]) {
+		case  READ_6:
+		case  WRITE_6:
+		case  READ_10:
+		case  WRITE_10:
+		case  READ_12:
+		case  WRITE_12:
+		case  READ_16:
+		case  WRITE_16:
+			if (le32_to_cpu(srbreply->data_xfer_length)
+						< scsicmd->underflow)
+				pr_warn("aacraid: SCSI CMD underflow\n");
+			else
+				pr_warn("aacraid: SCSI CMD Data Overrun\n");
 			scsicmd->result = DID_ERROR << 16
-						| MESSAGE_REJECT << 8;
+					| COMMAND_COMPLETE << 8;
+			break;
+		case INQUIRY:
+			scsicmd->result = DID_OK << 16
+					| COMMAND_COMPLETE << 8;
 			break;
-		case SRB_STATUS_REQUEST_FLUSHED:
-		case SRB_STATUS_ERROR:
-		case SRB_STATUS_INVALID_REQUEST:
-		case SRB_STATUS_REQUEST_SENSE_FAILED:
-		case SRB_STATUS_NO_HBA:
-		case SRB_STATUS_UNEXPECTED_BUS_FREE:
-		case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
-		case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
-		case SRB_STATUS_DELAYED_RETRY:
-		case SRB_STATUS_BAD_FUNCTION:
-		case SRB_STATUS_NOT_STARTED:
-		case SRB_STATUS_NOT_IN_USE:
-		case SRB_STATUS_FORCE_ABORT:
-		case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
 		default:
+			scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+			break;
+		}
+		break;
+	case SRB_STATUS_ABORTED:
+		scsicmd->result = DID_ABORT << 16 | ABORT << 8;
+		break;
+	case SRB_STATUS_ABORT_FAILED:
+		/*
+		 * Not sure about this one - but assuming the
+		 * hba was trying to abort for some reason
+		 */
+		scsicmd->result = DID_ERROR << 16 | ABORT << 8;
+		break;
+	case SRB_STATUS_PARITY_ERROR:
+		scsicmd->result = DID_PARITY << 16
+				| MSG_PARITY_ERROR << 8;
+		break;
+	case SRB_STATUS_NO_DEVICE:
+	case SRB_STATUS_INVALID_PATH_ID:
+	case SRB_STATUS_INVALID_TARGET_ID:
+	case SRB_STATUS_INVALID_LUN:
+	case SRB_STATUS_SELECTION_TIMEOUT:
+		scsicmd->result = DID_NO_CONNECT << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_COMMAND_TIMEOUT:
+	case SRB_STATUS_TIMEOUT:
+		scsicmd->result = DID_TIME_OUT << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_BUSY:
+		scsicmd->result = DID_BUS_BUSY << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_BUS_RESET:
+		scsicmd->result = DID_RESET << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_MESSAGE_REJECTED:
+		scsicmd->result = DID_ERROR << 16
+				| MESSAGE_REJECT << 8;
+		break;
+	case SRB_STATUS_REQUEST_FLUSHED:
+	case SRB_STATUS_ERROR:
+	case SRB_STATUS_INVALID_REQUEST:
+	case SRB_STATUS_REQUEST_SENSE_FAILED:
+	case SRB_STATUS_NO_HBA:
+	case SRB_STATUS_UNEXPECTED_BUS_FREE:
+	case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
+	case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
+	case SRB_STATUS_DELAYED_RETRY:
+	case SRB_STATUS_BAD_FUNCTION:
+	case SRB_STATUS_NOT_STARTED:
+	case SRB_STATUS_NOT_IN_USE:
+	case SRB_STATUS_FORCE_ABORT:
+	case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
+	default:
 #ifdef AAC_DETAILED_STATUS_INFO
-			printk(KERN_INFO "aacraid: SRB ERROR(%u) %s scsi cmd 0x%x - scsi status 0x%x\n",
-				le32_to_cpu(srbreply->srb_status) & 0x3F,
-				aac_get_status_string(
-					le32_to_cpu(srbreply->srb_status) & 0x3F),
-				scsicmd->cmnd[0],
-				le32_to_cpu(srbreply->scsi_status));
+		pr_info("aacraid: SRB ERROR(%u) %s scsi cmd 0x%x -scsi status 0x%x\n",
+			le32_to_cpu(srbreply->srb_status) & 0x3F,
+			aac_get_status_string(
+				le32_to_cpu(srbreply->srb_status) & 0x3F),
+			scsicmd->cmnd[0],
+			le32_to_cpu(srbreply->scsi_status));
 #endif
-			if ((scsicmd->cmnd[0] == ATA_12)
-				|| (scsicmd->cmnd[0] == ATA_16)) {
-					if (scsicmd->cmnd[2] & (0x01 << 5)) {
-						scsicmd->result = DID_OK << 16
-							| COMMAND_COMPLETE << 8;
-				break;
-				} else {
-					scsicmd->result = DID_ERROR << 16
-						| COMMAND_COMPLETE << 8;
-					break;
-				}
+		/*
+		 * When the CC bit is SET by the host in ATA pass thru CDB,
+		 *  driver is supposed to return DID_OK
+		 *
+		 * When the CC bit is RESET by the host, driver should
+		 *  return DID_ERROR
+		 */
+		if ((scsicmd->cmnd[0] == ATA_12)
+			|| (scsicmd->cmnd[0] == ATA_16)) {
+
+			if (scsicmd->cmnd[2] & (0x01 << 5)) {
+				scsicmd->result = DID_OK << 16
+					| COMMAND_COMPLETE << 8;
+			break;
 			} else {
 				scsicmd->result = DID_ERROR << 16
 					| COMMAND_COMPLETE << 8;
-				break;
+			break;
 			}
+		} else {
+			scsicmd->result = DID_ERROR << 16
+				| COMMAND_COMPLETE << 8;
+			break;
 		}
-		if (le32_to_cpu(srbreply->scsi_status)
-				== SAM_STAT_CHECK_CONDITION) {
-			int len;
-
-			scsicmd->result |= SAM_STAT_CHECK_CONDITION;
-			len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
-				    SCSI_SENSE_BUFFERSIZE);
+	}
+	if (le32_to_cpu(srbreply->scsi_status)
+			== SAM_STAT_CHECK_CONDITION) {
+		int len;
+
+		scsicmd->result |= SAM_STAT_CHECK_CONDITION;
+		len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+			    SCSI_SENSE_BUFFERSIZE);
 #ifdef AAC_DETAILED_STATUS_INFO
-			printk(KERN_WARNING "aac_srb_callback: check condition, status = %d len=%d\n",
-						le32_to_cpu(srbreply->status), len);
+		pr_warn("aac_srb_callback: check condition, status = %d len=%d\n",
+					le32_to_cpu(srbreply->status), len);
 #endif
-			memcpy(scsicmd->sense_buffer,
-					srbreply->sense_data, len);
-		}
+		memcpy(scsicmd->sense_buffer,
+				srbreply->sense_data, len);
 	}
+
 	/*
 	 * OR in the scsi status (already shifted up a bit)
 	 */

[PATCH 4.4 30/40] scsi: aacraid: Process Error for response I/O

[Greg Kroah-Hartman]

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

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

From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>


[ Upstream commit 4ec57fb4edaec523f0f78a0449a3b063749ac58b ]

Make sure that the driver processes error conditions even in the fast
response path for response from the adapter.

Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Dave Carroll <David.Carroll@microsemi.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/scsi/aacraid/aachba.c |  291 +++++++++++++++++++++---------------------
 1 file changed, 152 insertions(+), 139 deletions(-)

--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -2977,16 +2977,11 @@ static void aac_srb_callback(void *conte
 		return;
 
 	BUG_ON(fibptr == NULL);
-	dev = fibptr->dev;
-
-	scsi_dma_unmap(scsicmd);
 
-	/* expose physical device if expose_physicald flag is on */
-	if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
-	  && expose_physicals > 0)
-		aac_expose_phy_device(scsicmd);
+	dev = fibptr->dev;
 
 	srbreply = (struct aac_srb_reply *) fib_data(fibptr);
+
 	scsicmd->sense_buffer[0] = '\0';  /* Initialize sense valid flag to false */
 
 	if (fibptr->flags & FIB_CONTEXT_FLAG_FASTRESP) {
@@ -2999,158 +2994,176 @@ static void aac_srb_callback(void *conte
 		 */
 		scsi_set_resid(scsicmd, scsi_bufflen(scsicmd)
 				   - le32_to_cpu(srbreply->data_xfer_length));
-		/*
-		 * First check the fib status
-		 */
+	}
 
-		if (le32_to_cpu(srbreply->status) != ST_OK) {
-			int len;
 
-			printk(KERN_WARNING "aac_srb_callback: srb failed, status = %d\n", le32_to_cpu(srbreply->status));
-			len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
-				    SCSI_SENSE_BUFFERSIZE);
-			scsicmd->result = DID_ERROR << 16
-						| COMMAND_COMPLETE << 8
-						| SAM_STAT_CHECK_CONDITION;
-			memcpy(scsicmd->sense_buffer,
-					srbreply->sense_data, len);
-		}
+	scsi_dma_unmap(scsicmd);
 
-		/*
-		 * Next check the srb status
-		 */
-		switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
-		case SRB_STATUS_ERROR_RECOVERY:
-		case SRB_STATUS_PENDING:
-		case SRB_STATUS_SUCCESS:
-			scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
-			break;
-		case SRB_STATUS_DATA_OVERRUN:
-			switch (scsicmd->cmnd[0]) {
-			case  READ_6:
-			case  WRITE_6:
-			case  READ_10:
-			case  WRITE_10:
-			case  READ_12:
-			case  WRITE_12:
-			case  READ_16:
-			case  WRITE_16:
-				if (le32_to_cpu(srbreply->data_xfer_length)
-							< scsicmd->underflow)
-					printk(KERN_WARNING"aacraid: SCSI CMD underflow\n");
-				else
-					printk(KERN_WARNING"aacraid: SCSI CMD Data Overrun\n");
-				scsicmd->result = DID_ERROR << 16
-							| COMMAND_COMPLETE << 8;
-				break;
-			case INQUIRY: {
-				scsicmd->result = DID_OK << 16
-							| COMMAND_COMPLETE << 8;
-				break;
-			}
-			default:
-				scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
-				break;
-			}
-			break;
-		case SRB_STATUS_ABORTED:
-			scsicmd->result = DID_ABORT << 16 | ABORT << 8;
-			break;
-		case SRB_STATUS_ABORT_FAILED:
-			/*
-			 * Not sure about this one - but assuming the
-			 * hba was trying to abort for some reason
-			 */
-			scsicmd->result = DID_ERROR << 16 | ABORT << 8;
-			break;
-		case SRB_STATUS_PARITY_ERROR:
-			scsicmd->result = DID_PARITY << 16
-						| MSG_PARITY_ERROR << 8;
-			break;
-		case SRB_STATUS_NO_DEVICE:
-		case SRB_STATUS_INVALID_PATH_ID:
-		case SRB_STATUS_INVALID_TARGET_ID:
-		case SRB_STATUS_INVALID_LUN:
-		case SRB_STATUS_SELECTION_TIMEOUT:
-			scsicmd->result = DID_NO_CONNECT << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+	/* expose physical device if expose_physicald flag is on */
+	if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
+	  && expose_physicals > 0)
+		aac_expose_phy_device(scsicmd);
 
-		case SRB_STATUS_COMMAND_TIMEOUT:
-		case SRB_STATUS_TIMEOUT:
-			scsicmd->result = DID_TIME_OUT << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+	/*
+	 * First check the fib status
+	 */
 
-		case SRB_STATUS_BUSY:
-			scsicmd->result = DID_BUS_BUSY << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+	if (le32_to_cpu(srbreply->status) != ST_OK) {
+		int len;
 
-		case SRB_STATUS_BUS_RESET:
-			scsicmd->result = DID_RESET << 16
-						| COMMAND_COMPLETE << 8;
-			break;
+		pr_warn("aac_srb_callback: srb failed, status = %d\n",
+				le32_to_cpu(srbreply->status));
+		len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+			    SCSI_SENSE_BUFFERSIZE);
+		scsicmd->result = DID_ERROR << 16
+				| COMMAND_COMPLETE << 8
+				| SAM_STAT_CHECK_CONDITION;
+		memcpy(scsicmd->sense_buffer,
+				srbreply->sense_data, len);
+	}
 
-		case SRB_STATUS_MESSAGE_REJECTED:
+	/*
+	 * Next check the srb status
+	 */
+	switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
+	case SRB_STATUS_ERROR_RECOVERY:
+	case SRB_STATUS_PENDING:
+	case SRB_STATUS_SUCCESS:
+		scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+		break;
+	case SRB_STATUS_DATA_OVERRUN:
+		switch (scsicmd->cmnd[0]) {
+		case  READ_6:
+		case  WRITE_6:
+		case  READ_10:
+		case  WRITE_10:
+		case  READ_12:
+		case  WRITE_12:
+		case  READ_16:
+		case  WRITE_16:
+			if (le32_to_cpu(srbreply->data_xfer_length)
+						< scsicmd->underflow)
+				pr_warn("aacraid: SCSI CMD underflow\n");
+			else
+				pr_warn("aacraid: SCSI CMD Data Overrun\n");
 			scsicmd->result = DID_ERROR << 16
-						| MESSAGE_REJECT << 8;
+					| COMMAND_COMPLETE << 8;
+			break;
+		case INQUIRY:
+			scsicmd->result = DID_OK << 16
+					| COMMAND_COMPLETE << 8;
 			break;
-		case SRB_STATUS_REQUEST_FLUSHED:
-		case SRB_STATUS_ERROR:
-		case SRB_STATUS_INVALID_REQUEST:
-		case SRB_STATUS_REQUEST_SENSE_FAILED:
-		case SRB_STATUS_NO_HBA:
-		case SRB_STATUS_UNEXPECTED_BUS_FREE:
-		case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
-		case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
-		case SRB_STATUS_DELAYED_RETRY:
-		case SRB_STATUS_BAD_FUNCTION:
-		case SRB_STATUS_NOT_STARTED:
-		case SRB_STATUS_NOT_IN_USE:
-		case SRB_STATUS_FORCE_ABORT:
-		case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
 		default:
+			scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+			break;
+		}
+		break;
+	case SRB_STATUS_ABORTED:
+		scsicmd->result = DID_ABORT << 16 | ABORT << 8;
+		break;
+	case SRB_STATUS_ABORT_FAILED:
+		/*
+		 * Not sure about this one - but assuming the
+		 * hba was trying to abort for some reason
+		 */
+		scsicmd->result = DID_ERROR << 16 | ABORT << 8;
+		break;
+	case SRB_STATUS_PARITY_ERROR:
+		scsicmd->result = DID_PARITY << 16
+				| MSG_PARITY_ERROR << 8;
+		break;
+	case SRB_STATUS_NO_DEVICE:
+	case SRB_STATUS_INVALID_PATH_ID:
+	case SRB_STATUS_INVALID_TARGET_ID:
+	case SRB_STATUS_INVALID_LUN:
+	case SRB_STATUS_SELECTION_TIMEOUT:
+		scsicmd->result = DID_NO_CONNECT << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_COMMAND_TIMEOUT:
+	case SRB_STATUS_TIMEOUT:
+		scsicmd->result = DID_TIME_OUT << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_BUSY:
+		scsicmd->result = DID_BUS_BUSY << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_BUS_RESET:
+		scsicmd->result = DID_RESET << 16
+				| COMMAND_COMPLETE << 8;
+		break;
+
+	case SRB_STATUS_MESSAGE_REJECTED:
+		scsicmd->result = DID_ERROR << 16
+				| MESSAGE_REJECT << 8;
+		break;
+	case SRB_STATUS_REQUEST_FLUSHED:
+	case SRB_STATUS_ERROR:
+	case SRB_STATUS_INVALID_REQUEST:
+	case SRB_STATUS_REQUEST_SENSE_FAILED:
+	case SRB_STATUS_NO_HBA:
+	case SRB_STATUS_UNEXPECTED_BUS_FREE:
+	case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
+	case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
+	case SRB_STATUS_DELAYED_RETRY:
+	case SRB_STATUS_BAD_FUNCTION:
+	case SRB_STATUS_NOT_STARTED:
+	case SRB_STATUS_NOT_IN_USE:
+	case SRB_STATUS_FORCE_ABORT:
+	case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
+	default:
 #ifdef AAC_DETAILED_STATUS_INFO
-			printk(KERN_INFO "aacraid: SRB ERROR(%u) %s scsi cmd 0x%x - scsi status 0x%x\n",
-				le32_to_cpu(srbreply->srb_status) & 0x3F,
-				aac_get_status_string(
-					le32_to_cpu(srbreply->srb_status) & 0x3F),
-				scsicmd->cmnd[0],
-				le32_to_cpu(srbreply->scsi_status));
+		pr_info("aacraid: SRB ERROR(%u) %s scsi cmd 0x%x -scsi status 0x%x\n",
+			le32_to_cpu(srbreply->srb_status) & 0x3F,
+			aac_get_status_string(
+				le32_to_cpu(srbreply->srb_status) & 0x3F),
+			scsicmd->cmnd[0],
+			le32_to_cpu(srbreply->scsi_status));
 #endif
-			if ((scsicmd->cmnd[0] == ATA_12)
-				|| (scsicmd->cmnd[0] == ATA_16)) {
-					if (scsicmd->cmnd[2] & (0x01 << 5)) {
-						scsicmd->result = DID_OK << 16
-							| COMMAND_COMPLETE << 8;
-				break;
-				} else {
-					scsicmd->result = DID_ERROR << 16
-						| COMMAND_COMPLETE << 8;
-					break;
-				}
+		/*
+		 * When the CC bit is SET by the host in ATA pass thru CDB,
+		 *  driver is supposed to return DID_OK
+		 *
+		 * When the CC bit is RESET by the host, driver should
+		 *  return DID_ERROR
+		 */
+		if ((scsicmd->cmnd[0] == ATA_12)
+			|| (scsicmd->cmnd[0] == ATA_16)) {
+
+			if (scsicmd->cmnd[2] & (0x01 << 5)) {
+				scsicmd->result = DID_OK << 16
+					| COMMAND_COMPLETE << 8;
+			break;
 			} else {
 				scsicmd->result = DID_ERROR << 16
 					| COMMAND_COMPLETE << 8;
-				break;
+			break;
 			}
+		} else {
+			scsicmd->result = DID_ERROR << 16
+				| COMMAND_COMPLETE << 8;
+			break;
 		}
-		if (le32_to_cpu(srbreply->scsi_status)
-				== SAM_STAT_CHECK_CONDITION) {
-			int len;
-
-			scsicmd->result |= SAM_STAT_CHECK_CONDITION;
-			len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
-				    SCSI_SENSE_BUFFERSIZE);
+	}
+	if (le32_to_cpu(srbreply->scsi_status)
+			== SAM_STAT_CHECK_CONDITION) {
+		int len;
+
+		scsicmd->result |= SAM_STAT_CHECK_CONDITION;
+		len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+			    SCSI_SENSE_BUFFERSIZE);
 #ifdef AAC_DETAILED_STATUS_INFO
-			printk(KERN_WARNING "aac_srb_callback: check condition, status = %d len=%d\n",
-						le32_to_cpu(srbreply->status), len);
+		pr_warn("aac_srb_callback: check condition, status = %d len=%d\n",
+					le32_to_cpu(srbreply->status), len);
 #endif
-			memcpy(scsicmd->sense_buffer,
-					srbreply->sense_data, len);
-		}
+		memcpy(scsicmd->sense_buffer,
+				srbreply->sense_data, len);
 	}
+
 	/*
 	 * OR in the scsi status (already shifted up a bit)
 	 */

[PATCH 4.4 31/40] platform/x86: intel_mid_thermal: Fix module autoload

[Greg Kroah-Hartman]

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

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

From: Javier Martinez Canillas <javier@osg.samsung.com>


[ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
$

After this patch:

$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
alias:          platform:msic_thermal

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/platform/x86/intel_mid_thermal.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/platform/x86/intel_mid_thermal.c
+++ b/drivers/platform/x86/intel_mid_thermal.c
@@ -550,6 +550,7 @@ static const struct platform_device_id t
 	{ "msic_thermal", 1 },
 	{ }
 };
+MODULE_DEVICE_TABLE(platform, therm_id_table);
 
 static struct platform_driver mid_thermal_driver = {
 	.driver = {

[PATCH 4.4 32/40] staging: lustre: llite: dont invoke direct_IO for the EOF case

[Greg Kroah-Hartman]

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

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

From: Yang Sheng <yang.sheng@intel.com>


[ Upstream commit 77759771fb95420d23876cb104ab65c022613325 ]

The function generic_file_read_iter() does not check EOF
before invoke direct_IO callback. So we have to check it
ourselves.

Signed-off-by: Yang Sheng <yang.sheng@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969
Reviewed-on: https://review.whamcloud.com/24552
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/lustre/lustre/llite/rw26.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/staging/lustre/lustre/llite/rw26.c
+++ b/drivers/staging/lustre/lustre/llite/rw26.c
@@ -376,6 +376,10 @@ static ssize_t ll_direct_IO_26(struct ki
 	if (!lli->lli_has_smd)
 		return -EBADF;
 
+	/* Check EOF by ourselves */
+	if (iov_iter_rw(iter) == READ && file_offset >= i_size_read(inode))
+		return 0;
+
 	/* FIXME: io smaller than PAGE_SIZE is broken on ia64 ??? */
 	if ((file_offset & ~CFS_PAGE_MASK) || (count & ~CFS_PAGE_MASK))
 		return -EINVAL;

[PATCH 4.4 33/40] staging: lustre: hsm: stack overrun in hai_dump_data_field

[Greg Kroah-Hartman]

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

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

From: frank zago <fzago@cray.com>


[ Upstream commit 22aadb91c0a0055935109c175f5446abfb130702 ]

The function hai_dump_data_field will do a stack buffer
overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has
some data in it.

hai_dump_data_field uses snprintf. But there is no check for
truncation, and the value returned by snprintf is used as-is.  The
coordinator code calls hai_dump_data_field with 12 bytes in the
buffer. The 6th byte of data is printed incompletely to make room for
the terminating NUL. However snprintf still returns 2, so when
hai_dump_data_field writes the final NUL, it does it outside the
reserved buffer, in the 13th byte of the buffer. This stack buffer
overrun hangs my VM.

Fix by checking that there is enough room for the next 2 characters
plus the NUL terminator. Don't print half bytes. Change the format to
02X instead of .2X, which makes more sense.

Signed-off-by: frank zago <fzago@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171
Reviewed-on: http://review.whamcloud.com/20338
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Jean-Baptiste Riaux <riaux.jb@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/lustre/lustre/include/lustre/lustre_user.h |   18 +++++--------
 1 file changed, 8 insertions(+), 10 deletions(-)

--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -1063,23 +1063,21 @@ struct hsm_action_item {
  * \retval buffer
  */
 static inline char *hai_dump_data_field(struct hsm_action_item *hai,
-					char *buffer, int len)
+					char *buffer, size_t len)
 {
-	int i, sz, data_len;
+	int i, data_len;
 	char *ptr;
 
 	ptr = buffer;
-	sz = len;
 	data_len = hai->hai_len - sizeof(*hai);
-	for (i = 0 ; (i < data_len) && (sz > 0) ; i++) {
-		int cnt;
-
-		cnt = snprintf(ptr, sz, "%.2X",
-			       (unsigned char)hai->hai_data[i]);
-		ptr += cnt;
-		sz -= cnt;
+	for (i = 0; (i < data_len) && (len > 2); i++) {
+		snprintf(ptr, 3, "%02X", (unsigned char)hai->hai_data[i]);
+		ptr += 2;
+		len -= 2;
 	}
+
 	*ptr = '\0';
+
 	return buffer;
 }
 

[PATCH 4.4 34/40] staging: lustre: ptlrpc: skip lock if export failed

[Greg Kroah-Hartman]

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

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

From: Alexander Boyko <alexander.boyko@seagate.com>


[ Upstream commit 4c43c27ddc461d8473cedd70f2549614641dfbc7 ]

This patch resolves IO vs eviction race.
After eviction failed export stayed at stale list,
a client had IO processing and reconnected during it.
A client sent brw rpc with last lock cookie and new connection.
The lock with failed export was found and assert was happened.
 (ost_handler.c:1812:ost_prolong_lock_one())
  ASSERTION( lock->l_export == opd->opd_exp ) failed:

 1. Skip the lock at ldlm_handle2lock if lock export failed.
 2. Validation of lock for IO was added at hpreq_check(). The lock
    searching is based on granted interval tree. If server doesn`t
    have a valid lock, it reply to client with ESTALE.

Signed-off-by: Alexander Boyko <alexander.boyko@seagate.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702
Seagate-bug-id: MRP-2787
Reviewed-on: http://review.whamcloud.com/18120
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |    7 +++++++
 drivers/staging/lustre/lustre/ptlrpc/service.c |   21 ++++++++-------------
 2 files changed, 15 insertions(+), 13 deletions(-)

--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
@@ -550,6 +550,13 @@ struct ldlm_lock *__ldlm_handle2lock(con
 	if (lock == NULL)
 		return NULL;
 
+	if (lock->l_export && lock->l_export->exp_failed) {
+		CDEBUG(D_INFO, "lock export failed: lock %p, exp %p\n",
+		       lock, lock->l_export);
+		LDLM_LOCK_PUT(lock);
+		return NULL;
+	}
+
 	/* It's unlikely but possible that someone marked the lock as
 	 * destroyed after we did handle2object on it */
 	if (flags == 0 && ((lock->l_flags & LDLM_FL_DESTROYED) == 0)) {
--- a/drivers/staging/lustre/lustre/ptlrpc/service.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/service.c
@@ -1240,20 +1240,15 @@ static int ptlrpc_server_hpreq_init(stru
 		 * it may hit swab race at LU-1044. */
 		if (req->rq_ops->hpreq_check) {
 			rc = req->rq_ops->hpreq_check(req);
-			/**
-			 * XXX: Out of all current
-			 * ptlrpc_hpreq_ops::hpreq_check(), only
-			 * ldlm_cancel_hpreq_check() can return an error code;
-			 * other functions assert in similar places, which seems
-			 * odd. What also does not seem right is that handlers
-			 * for those RPCs do not assert on the same checks, but
-			 * rather handle the error cases. e.g. see
-			 * ost_rw_hpreq_check(), and ost_brw_read(),
-			 * ost_brw_write().
+			if (rc == -ESTALE) {
+				req->rq_status = rc;
+				ptlrpc_error(req);
+			}
+			/** can only return error,
+			 * 0 for normal request,
+			 *  or 1 for high priority request
 			 */
-			if (rc < 0)
-				return rc;
-			LASSERT(rc == 0 || rc == 1);
+			LASSERT(rc <= 1);
 		}
 
 		spin_lock_bh(&req->rq_export->exp_rpc_lock);

[PATCH 4.4 35/40] exynos4-is: fimc-is: Unmap region obtained by of_iomap()

[Greg Kroah-Hartman]

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

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

From: Arvind Yadav <arvind.yadav.cs@gmail.com>


[ Upstream commit 4742575cde1f3cee0ea6b41af42781672315b04b ]

Free memory mapping, if fimc_is_probe is not successful.

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/media/platform/exynos4-is/fimc-is.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -815,12 +815,13 @@ static int fimc_is_probe(struct platform
 	is->irq = irq_of_parse_and_map(dev->of_node, 0);
 	if (!is->irq) {
 		dev_err(dev, "no irq found\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto err_iounmap;
 	}
 
 	ret = fimc_is_get_clocks(is);
 	if (ret < 0)
-		return ret;
+		goto err_iounmap;
 
 	platform_set_drvdata(pdev, is);
 
@@ -880,6 +881,8 @@ err_irq:
 	free_irq(is->irq, is);
 err_clk:
 	fimc_is_put_clocks(is);
+err_iounmap:
+	iounmap(is->pmu_regs);
 	return ret;
 }
 
@@ -935,6 +938,7 @@ static int fimc_is_remove(struct platfor
 	fimc_is_unregister_subdevs(is);
 	vb2_dma_contig_cleanup_ctx(is->alloc_ctx);
 	fimc_is_put_clocks(is);
+	iounmap(is->pmu_regs);
 	fimc_is_debugfs_remove(is);
 	release_firmware(is->fw.f_w);
 	fimc_is_free_cpu_memory(is);

[PATCH 4.4 36/40] mei: return error on notification request to a disconnected client

[Greg Kroah-Hartman]

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

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

From: Alexander Usyskin <alexander.usyskin@intel.com>


[ Upstream commit 7c47d2ca0feca767479329da23523ed798acb854 ]

Request for a notification from a disconnected client will be ignored
silently by the FW but the caller should know that the operation hasn't
succeeded.

Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/misc/mei/client.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1300,6 +1300,9 @@ int mei_cl_notify_request(struct mei_cl
 		return -EOPNOTSUPP;
 	}
 
+	if (!mei_cl_is_connected(cl))
+		return -ENODEV;
+
 	rets = pm_runtime_get(dev->dev);
 	if (rets < 0 && rets != -EINPROGRESS) {
 		pm_runtime_put_noidle(dev->dev);

[PATCH 4.4 37/40] s390/dasd: check for device error pointer within state change interrupts

[Greg Kroah-Hartman]

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

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

From: Stefan Haberland <sth@linux.vnet.ibm.com>


[ Upstream commit 2202134e48a3b50320aeb9e3dd1186833e9d7e66 ]

Check if the device pointer is valid. Just a sanity check since we already
are in the int handler of the device.

Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/s390/block/dasd.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -1635,8 +1635,11 @@ void dasd_int_handler(struct ccw_device
 	/* check for for attention message */
 	if (scsw_dstat(&irb->scsw) & DEV_STAT_ATTENTION) {
 		device = dasd_device_from_cdev_locked(cdev);
-		device->discipline->check_attention(device, irb->esw.esw1.lpum);
-		dasd_put_device(device);
+		if (!IS_ERR(device)) {
+			device->discipline->check_attention(device,
+							    irb->esw.esw1.lpum);
+			dasd_put_device(device);
+		}
 	}
 
 	if (!cqr)

[PATCH 4.4 38/40] bt8xx: fix memory leak

[Greg Kroah-Hartman]

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

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

From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>


[ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ]

If dvb_attach() fails then we were just printing an error message and
exiting but the memory allocated to state was not released.

Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/media/pci/bt8xx/dvb-bt8xx.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/media/pci/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/pci/bt8xx/dvb-bt8xx.c
@@ -680,6 +680,7 @@ static void frontend_init(struct dvb_bt8
 		/*	DST is not a frontend, attaching the ASIC	*/
 		if (dvb_attach(dst_attach, state, &card->dvb_adapter) == NULL) {
 			pr_err("%s: Could not find a Twinhan DST\n", __func__);
+			kfree(state);
 			break;
 		}
 		/*	Attach other DST peripherals if any		*/

[PATCH 4.4 39/40] xen: dont print error message in case of missing Xenstore entry

[Greg Kroah-Hartman]

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

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

From: Juergen Gross <jgross@suse.com>


[ Upstream commit 4e93b6481c87ea5afde944a32b4908357ec58992 ]

When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/xen/manage.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -275,8 +275,16 @@ static void sysrq_handler(struct xenbus_
 	err = xenbus_transaction_start(&xbt);
 	if (err)
 		return;
-	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
-		pr_err("Unable to read sysrq code in control/sysrq\n");
+	err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
+	if (err < 0) {
+		/*
+		 * The Xenstore watch fires directly after registering it and
+		 * after a suspend/resume cycle. So ENOENT is no error but
+		 * might happen in those cases.
+		 */
+		if (err != -ENOENT)
+			pr_err("Error %d reading sysrq code in control/sysrq\n",
+			       err);
 		xenbus_transaction_end(xbt, 1);
 		return;
 	}

[PATCH 4.4 40/40] staging: r8712u: Fix Sparse warning in rtl871x_xmit.c

[Greg Kroah-Hartman]

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

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

From: Larry Finger <Larry.Finger@lwfinger.net>


[ Upstream commit 07222e535831b916221dd2a48a3047ec7e45dc72 ]

Sparse reports the following:
  CHECK   drivers/staging/rtl8712/rtl871x_xmit.c
drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:491:23:    expected unsigned short [usertype] *fctrl
drivers/staging/rtl8712/rtl871x_xmit.c:491:23:    got restricted __le16 *<noident>
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:580:36:    expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/staging/rtl8712/rtl871x_xmit.c:580:36:    got restricted __be16 [usertype] <noident>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/rtl8712/rtl871x_xmit.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -339,7 +339,8 @@ sint r8712_update_attrib(struct _adapter
 	/* if in MP_STATE, update pkt_attrib from mp_txcmd, and overwrite
 	 * some settings above.*/
 	if (check_fwstate(pmlmepriv, WIFI_MP_STATE))
-		pattrib->priority = (txdesc.txdw1 >> QSEL_SHT) & 0x1f;
+		pattrib->priority =
+		    (le32_to_cpu(txdesc.txdw1) >> QSEL_SHT) & 0x1f;
 	return _SUCCESS;
 }
 
@@ -479,7 +480,7 @@ static sint make_wlanhdr(struct _adapter
 	struct ieee80211_hdr *pwlanhdr = (struct ieee80211_hdr *)hdr;
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	struct qos_priv *pqospriv = &pmlmepriv->qospriv;
-	u16 *fctrl = &pwlanhdr->frame_ctl;
+	__le16 *fctrl = &pwlanhdr->frame_ctl;
 
 	memset(hdr, 0, WLANHDR_OFFSET);
 	SetFrameSubType(fctrl, pattrib->subtype);
@@ -568,7 +569,7 @@ static sint r8712_put_snap(u8 *data, u16
 	snap->oui[0] = oui[0];
 	snap->oui[1] = oui[1];
 	snap->oui[2] = oui[2];
-	*(u16 *)(data + SNAP_SIZE) = htons(h_proto);
+	*(__be16 *)(data + SNAP_SIZE) = htons(h_proto);
 	return SNAP_SIZE + sizeof(u16);
 }
 

Re: [PATCH 4.4 00/40] 4.4.97-stable review

[Guenter Roeck]

On Mon, Nov 06, 2017 at 10:44:35AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov  8 09:44:42 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 116 pass: 116 fail: 0

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

Guenter

Re: [PATCH 4.4 00/40] 4.4.97-stable review

[Shuah Khan]

On 11/06/2017 02:44 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov  8 09:44:42 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.97-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.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg and kselftest regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge

[Archit Taneja]

Hi Greg,

On 11/06/2017 03:15 PM, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.

This patch isn't needed on 4.4 or the 4.9 stable branches. This was required
only after drm_bridge API was changed with the commit:

(3bb80f2495) drm: bridge: Link encoder and bridge in core code

This was merged only in 4.11.

Thanks,
Archit

> 
> ------------------
> 
> From: Archit Taneja <architt@codeaurora.org>
> 
> 
> [ Upstream commit 0bb70b82c2f91e4667f3c617505235efd6d77e46 ]
> 
> The commit "drm: bridge: Link encoder and bridge in core code" updated
> the drm_bridge_attach() API to also include the drm_encoder pointer
> the bridge attaches to.
> 
> The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
> pointer stored in msm_dsi->encoders to pass the encoder to the bridge
> API.
> 
> msm_dsi->encoders is unfortunately set after this function is called,
> resulting in us passing a NULL pointer to drm_brigde_attach. This
> results in an error and the DSI driver probe fails.
> 
> Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
> try to set the encoder's bridge. That's now managed by the bridge
> API.
> 
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>   drivers/gpu/drm/msm/dsi/dsi.c |    8 +++-----
>   1 file changed, 3 insertions(+), 5 deletions(-)
> 
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi
>   		goto fail;
>   	}
>   
> +	for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
> +		msm_dsi->encoders[i] = encoders[i];
> +
>   	msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
>   	if (IS_ERR(msm_dsi->bridge)) {
>   		ret = PTR_ERR(msm_dsi->bridge);
> @@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi
>   		goto fail;
>   	}
>   
> -	for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
> -		encoders[i]->bridge = msm_dsi->bridge;
> -		msm_dsi->encoders[i] = encoders[i];
> -	}
> -
>   	/*
>   	 * check if the dsi encoder output is connected to a panel or an
>   	 * external bridge. We create a connector only if we're connected to a
> 
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge

[Greg Kroah-Hartman]

On Tue, Nov 07, 2017 at 10:02:23AM +0530, Archit Taneja wrote:
> Hi Greg,
> 
> On 11/06/2017 03:15 PM, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> This patch isn't needed on 4.4 or the 4.9 stable branches. This was required
> only after drm_bridge API was changed with the commit:
> 
> (3bb80f2495) drm: bridge: Link encoder and bridge in core code
> 
> This was merged only in 4.11.

Great, thanks for the review, they are now dropped from 4.4 and 4.9.

greg k-h

Re: [PATCH 4.4 00/40] 4.4.97-stable review

[Tom Gall]

> On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov  8 09:44:42 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.97-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.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from Linaro’s test farm. As per usual HiKey results held separate because it’s platform support is out of tree.

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

kernel: 4.4.97-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 3a8149abdccbecc21c68451ee8ffd86b56ff3061
git describe: v4.4.96-41-g3a8149abdccb
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.96-41-g3a8149abdccb


Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, fail: 11, skip: 11 (known failures)
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, fail: 4, skip: 67  (known failures)
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 15, skip: 9  (known failures)
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 959, fail: 3, skip: 164  (known failures)
* ltp-timers-tests - pass: 13,


Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

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

kernel: 4.4.97-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.97-rc1-hikey-20171107
git commit: f9ac28c428c0ddaf64cca891932a283fcca26516
git describe: 4.4.97-rc1-hikey-20171107
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.97-rc1-hikey-20171107


No regressions (compared to build 4.4.96-rc1-hikey-20171031)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, fail: 13, skip: 9  (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, fail: 13, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, fail: 3, skip: 125  (known failures)
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill

[Sebastian Gottschall]

what about 4.9?

Am 06.11.2017 um 10:44 schrieb Greg Kroah-Hartman:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Yan Markman <ymarkman@marvell.com>
>
> commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.
>
> Under heavy system stress mvebu SoC using Cortex A9 sporadically
> encountered instability issues.
>
> The "double linefill" feature of L2 cache was identified as causing
> dependency between read and write which lead to the deadlock.
>
> Especially, it was the cause of deadlock seen under heavy PCIe traffic,
> as this dependency violates PCIE overtaking rule.
>
> Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
> Signed-off-by: Yan Markman <ymarkman@marvell.com>
> Signed-off-by: Igal Liberman <igall@marvell.com>
> Signed-off-by: Nadav Haklai <nadavh@marvell.com>
> [gregory.clement@free-electrons.com: reformulate commit log, add Armada
> 375 and add Fixes tag]
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
>   arch/arm/boot/dts/armada-375.dtsi |    4 ++--
>   arch/arm/boot/dts/armada-38x.dtsi |    4 ++--
>   arch/arm/boot/dts/armada-39x.dtsi |    4 ++--
>   3 files changed, 6 insertions(+), 6 deletions(-)
>
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -176,9 +176,9 @@
>   				reg = <0x8000 0x1000>;
>   				cache-unified;
>   				cache-level = <2>;
> -				arm,double-linefill-incr = <1>;
> +				arm,double-linefill-incr = <0>;
>   				arm,double-linefill-wrap = <0>;
> -				arm,double-linefill = <1>;
> +				arm,double-linefill = <0>;
>   				prefetch-data = <1>;
>   			};
>   
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -143,9 +143,9 @@
>   				reg = <0x8000 0x1000>;
>   				cache-unified;
>   				cache-level = <2>;
> -				arm,double-linefill-incr = <1>;
> +				arm,double-linefill-incr = <0>;
>   				arm,double-linefill-wrap = <0>;
> -				arm,double-linefill = <1>;
> +				arm,double-linefill = <0>;
>   				prefetch-data = <1>;
>   			};
>   
> --- a/arch/arm/boot/dts/armada-39x.dtsi
> +++ b/arch/arm/boot/dts/armada-39x.dtsi
> @@ -104,9 +104,9 @@
>   				reg = <0x8000 0x1000>;
>   				cache-unified;
>   				cache-level = <2>;
> -				arm,double-linefill-incr = <1>;
> +				arm,double-linefill-incr = <0>;
>   				arm,double-linefill-wrap = <0>;
> -				arm,double-linefill = <1>;
> +				arm,double-linefill = <0>;
>   				prefetch-data = <1>;
>   			};
>   
>
>
>

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill

[Greg Kroah-Hartman]

On Wed, Nov 08, 2017 at 12:06:48AM +0100, Sebastian Gottschall wrote:
> what about 4.9?

Ok, that was odd, I don't know what happened there, now added to the 4.9
tree, thanks for catching that.

greg k-h

Re: [PATCH 4.4 00/40] 4.4.97-stable review

[Greg Kroah-Hartman]

On Tue, Nov 07, 2017 at 04:55:36PM -0600, Tom Gall wrote:
> 
> > On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 
> > This is the start of the stable review cycle for the 4.4.97 release.
> > There are 40 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 Wed Nov  8 09:44:42 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.97-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.4.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Results from Linaro’s test farm. As per usual HiKey results held separate because it’s platform support is out of tree.

Thanks for letting me know, but howcome you all are not testing 4.13
releases?

thanks,

greg k-h

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Ben Hutchings]

On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Mark Rutland <mark.rutland@arm.com>
> 
> commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> 
> It's possible for a user to deliberately trigger __dump_instr with a
> chosen kernel address.
> 
> Let's avoid problems resulting from this by using get_user() rather than
> __get_user(), ensuring that we don't erroneously access kernel memory.
> 
> Where we use __dump_instr() on kernel text, we already switch to
> KERNEL_DS, so this shouldn't adversely affect those cases.
> 
> Fixes: 60ffc30d5652810d ("arm64: Exception handling")
[...]

This seems harmless, but I don't think it will fix the bug in 4.4
unless you also cherry-pick:

commit c5cea06be060f38e5400d796e61cfc8c36e52924
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Mon Jun 13 11:15:14 2016 +0100

    arm64: fix dump_instr when PAN and UAO are in use

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Catalin Marinas]

On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Mark Rutland <mark.rutland@arm.com>
> > 
> > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > 
> > It's possible for a user to deliberately trigger __dump_instr with a
> > chosen kernel address.
> > 
> > Let's avoid problems resulting from this by using get_user() rather than
> > __get_user(), ensuring that we don't erroneously access kernel memory.
> > 
> > Where we use __dump_instr() on kernel text, we already switch to
> > KERNEL_DS, so this shouldn't adversely affect those cases.
> > 
> > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> [...]
> 
> This seems harmless, but I don't think it will fix the bug in 4.4
> unless you also cherry-pick:
> 
> commit c5cea06be060f38e5400d796e61cfc8c36e52924
> Author: Mark Rutland <mark.rutland@arm.com>
> Date:   Mon Jun 13 11:15:14 2016 +0100
> 
>     arm64: fix dump_instr when PAN and UAO are in use

I agree. In 4.4 dump_instr() doesn't do any checks, just
set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
Override"; merged in 4.6), it also makes sense on its own as a security
improvement for 4.4.

Mark is currently on holiday but he'll follow up next week if any
patches need back-porting.

-- 
Catalin

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Catalin Marinas]

On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Mark Rutland <mark.rutland@arm.com>
> > 
> > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > 
> > It's possible for a user to deliberately trigger __dump_instr with a
> > chosen kernel address.
> > 
> > Let's avoid problems resulting from this by using get_user() rather than
> > __get_user(), ensuring that we don't erroneously access kernel memory.
> > 
> > Where we use __dump_instr() on kernel text, we already switch to
> > KERNEL_DS, so this shouldn't adversely affect those cases.
> > 
> > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> [...]
> 
> This seems harmless, but I don't think it will fix the bug in 4.4
> unless you also cherry-pick:
> 
> commit c5cea06be060f38e5400d796e61cfc8c36e52924
> Author: Mark Rutland <mark.rutland@arm.com>
> Date:���Mon Jun 13 11:15:14 2016 +0100
> 
> ����arm64: fix dump_instr when PAN and UAO are in use

I agree. In 4.4 dump_instr() doesn't do any checks, just
set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
Override"; merged in 4.6), it also makes sense on its own as a security
improvement for 4.4.

Mark is currently on holiday but he'll follow up next week if any
patches need back-porting.

-- 
Catalin

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Mark Rutland]

On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote:
> On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Mark Rutland <mark.rutland@arm.com>
> > > 
> > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > > 
> > > It's possible for a user to deliberately trigger __dump_instr with a
> > > chosen kernel address.
> > > 
> > > Let's avoid problems resulting from this by using get_user() rather than
> > > __get_user(), ensuring that we don't erroneously access kernel memory.
> > > 
> > > Where we use __dump_instr() on kernel text, we already switch to
> > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > > 
> > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > [...]
> > 
> > This seems harmless, but I don't think it will fix the bug in 4.4
> > unless you also cherry-pick:
> > 
> > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > Author: Mark Rutland <mark.rutland@arm.com>
> > Date:   Mon Jun 13 11:15:14 2016 +0100
> > 
> >     arm64: fix dump_instr when PAN and UAO are in use
> 
> I agree. In 4.4 dump_instr() doesn't do any checks, just
> set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
> fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
> Override"; merged in 4.6), it also makes sense on its own as a security
> improvement for 4.4.
> 
> Mark is currently on holiday but he'll follow up next week if any
> patches need back-porting.

I accidentally glanced at my gmail filter this morning; so I can reply today.
;)

I agree that we need both patches. On its own (in the absence of PAN/UAO),
57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
can dump kernel instructions when we intend to, with 7a7003b1da010d2b
backported.

Backporting 57f4959bad0a154a as a prerequisite makes sense to me.

I hadn't realised you could list prerequisites in a stable Cc -- I'll try to do
that in future.

Thanks,
Mark.

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Ben Hutchings]

On Mon, 2017-11-13 at 19:05 +0000, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > > > From: Mark Rutland <mark.rutland@arm.com>
> > 
> > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > 
> > It's possible for a user to deliberately trigger __dump_instr with a
> > chosen kernel address.
> > 
> > Let's avoid problems resulting from this by using get_user() rather than
> > __get_user(), ensuring that we don't erroneously access kernel memory.
> > 
> > Where we use __dump_instr() on kernel text, we already switch to
> > KERNEL_DS, so this shouldn't adversely affect those cases.
> > 
> > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> 
> [...]
> 
> This seems harmless, but I don't think it will fix the bug in 4.4
> unless you also cherry-pick:
> 
> commit c5cea06be060f38e5400d796e61cfc8c36e52924
> Author: Mark Rutland <mark.rutland@arm.com>
> Date:   Mon Jun 13 11:15:14 2016 +0100
> 
>     arm64: fix dump_instr when PAN and UAO are in use

Oops, now I see you already have that as patch #36.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Ben Hutchings]

On Wed, 2017-11-15 at 13:28 +0000, Ben Hutchings wrote:
> On Mon, 2017-11-13 at 19:05 +0000, Ben Hutchings wrote:
> > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please
> > > let me know.
> > > 
> > > ------------------
> > > 
> > > > > From: Mark Rutland <mark.rutland@arm.com>
> > > 
> > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > > 
> > > It's possible for a user to deliberately trigger __dump_instr
> > > with a
> > > chosen kernel address.
> > > 
> > > Let's avoid problems resulting from this by using get_user()
> > > rather than
> > > __get_user(), ensuring that we don't erroneously access kernel
> > > memory.
> > > 
> > > Where we use __dump_instr() on kernel text, we already switch to
> > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > > 
> > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > 
> > [...]
> > 
> > This seems harmless, but I don't think it will fix the bug in 4.4
> > unless you also cherry-pick:
> > 
> > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > Author: Mark Rutland <mark.rutland@arm.com>
> > Date:   Mon Jun 13 11:15:14 2016 +0100
> > 
> >     arm64: fix dump_instr when PAN and UAO are in use
> 
> Oops, now I see you already have that as patch #36.

Only not, because I'm confusing arm and arm64.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Greg Kroah-Hartman]

On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote:
> > On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> > > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Mark Rutland <mark.rutland@arm.com>
> > > > 
> > > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > > > 
> > > > It's possible for a user to deliberately trigger __dump_instr with a
> > > > chosen kernel address.
> > > > 
> > > > Let's avoid problems resulting from this by using get_user() rather than
> > > > __get_user(), ensuring that we don't erroneously access kernel memory.
> > > > 
> > > > Where we use __dump_instr() on kernel text, we already switch to
> > > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > > > 
> > > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > > [...]
> > > 
> > > This seems harmless, but I don't think it will fix the bug in 4.4
> > > unless you also cherry-pick:
> > > 
> > > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > > Author: Mark Rutland <mark.rutland@arm.com>
> > > Date:   Mon Jun 13 11:15:14 2016 +0100
> > > 
> > >     arm64: fix dump_instr when PAN and UAO are in use
> > 
> > I agree. In 4.4 dump_instr() doesn't do any checks, just
> > set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
> > fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
> > Override"; merged in 4.6), it also makes sense on its own as a security
> > improvement for 4.4.
> > 
> > Mark is currently on holiday but he'll follow up next week if any
> > patches need back-porting.
> 
> I accidentally glanced at my gmail filter this morning; so I can reply today.
> ;)
> 
> I agree that we need both patches. On its own (in the absence of PAN/UAO),
> 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> backported.
> 
> Backporting 57f4959bad0a154a as a prerequisite makes sense to me.

But that is a "new feature", are you sure about this?

So, just apply that one patch and we are all ok?  Nothing else?

confused,

greg k-h

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Greg Kroah-Hartman]

On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote:
> > On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> > > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Mark Rutland <mark.rutland@arm.com>
> > > > 
> > > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > > > 
> > > > It's possible for a user to deliberately trigger __dump_instr with a
> > > > chosen kernel address.
> > > > 
> > > > Let's avoid problems resulting from this by using get_user() rather than
> > > > __get_user(), ensuring that we don't erroneously access kernel memory.
> > > > 
> > > > Where we use __dump_instr() on kernel text, we already switch to
> > > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > > > 
> > > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > > [...]
> > > 
> > > This seems harmless, but I don't think it will fix the bug in 4.4
> > > unless you also cherry-pick:
> > > 
> > > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > > Author: Mark Rutland <mark.rutland@arm.com>
> > > Date:���Mon Jun 13 11:15:14 2016 +0100
> > > 
> > > ����arm64: fix dump_instr when PAN and UAO are in use
> > 
> > I agree. In 4.4 dump_instr() doesn't do any checks, just
> > set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
> > fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
> > Override"; merged in 4.6), it also makes sense on its own as a security
> > improvement for 4.4.
> > 
> > Mark is currently on holiday but he'll follow up next week if any
> > patches need back-porting.
> 
> I accidentally glanced at my gmail filter this morning; so I can reply today.
> ;)
> 
> I agree that we need both patches. On its own (in the absence of PAN/UAO),
> 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> backported.
> 
> Backporting 57f4959bad0a154a as a prerequisite makes sense to me.

But that is a "new feature", are you sure about this?

So, just apply that one patch and we are all ok?  Nothing else?

confused,

greg k-h

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Mark Rutland]

On Sun, Nov 19, 2017 at 11:29:35AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> > I agree that we need both patches. On its own (in the absence of PAN/UAO),
> > 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> > can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> > backported.
> > 
> > Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
> 
> But that is a "new feature", are you sure about this?

Sorry, I copied the wrong commit ID when replying. I meant to say that
we should backport commit:

  c5cea06be060f38e ("arm64: fix dump_instr when PAN and UAO are in use")

... which on its own does nothing, but will prevent 7a7003b1da010d2b
from breaking kernel dumps.

We should *not* backport commit:

 57f4959bad0a154a ("arm64: kernel: Add support for User Access Override")

> So, just apply that one patch and we are all ok?  Nothing else?

Just apply c5cea06be060f38e as a prerequisite for 7a7003b1da010d2b, and
I think we're good. I'm not aware of anything else we need.

> confused,

Sorry about that. Hopefully the above clarified things?

Thanks,
Mark.

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

[Greg Kroah-Hartman]

On Mon, Nov 20, 2017 at 11:26:20AM +0000, Mark Rutland wrote:
> On Sun, Nov 19, 2017 at 11:29:35AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> > > I agree that we need both patches. On its own (in the absence of PAN/UAO),
> > > 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> > > can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> > > backported.
> > > 
> > > Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
> > 
> > But that is a "new feature", are you sure about this?
> 
> Sorry, I copied the wrong commit ID when replying. I meant to say that
> we should backport commit:
> 
>   c5cea06be060f38e ("arm64: fix dump_instr when PAN and UAO are in use")
> 
> ... which on its own does nothing, but will prevent 7a7003b1da010d2b
> from breaking kernel dumps.
> 
> We should *not* backport commit:
> 
>  57f4959bad0a154a ("arm64: kernel: Add support for User Access Override")
> 
> > So, just apply that one patch and we are all ok?  Nothing else?
> 
> Just apply c5cea06be060f38e as a prerequisite for 7a7003b1da010d2b, and
> I think we're good. I'm not aware of anything else we need.
> 
> > confused,
> 
> Sorry about that. Hopefully the above clarified things?

Yes, it did, thanks, I think I've queued up the right patches now, if
not, please let me know :)

greg k-h