Skip to contentSkip to conversation

3.14.75-stable review

PATCH In review Greg Kroah-Hartman 3 participants 22 messages Aug 8, 2016 – Aug 9, 2016 Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.14.75-stable review

This is the start of the stable review cycle for the 3.14.75 release. There are 21 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 Aug 10 18:01:28 UTC 2016. 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/v3.x/stable-review/patch-3.14.75-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-3.14.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 3.14.75-rc1

Dmitri Epshtein <[email protected]>
net: mvneta: set real interrupt per packet for tx_done

Ilya Dryomov <[email protected]>
libceph: apply new_state before new_up_client on incrementals

Brian King <[email protected]>
ipr: Clear interrupt on croc/crocodile when running with LSI

Oliver Hartkopp <[email protected]>
can: fix oops caused by wrong rtnl dellink usage

Oliver Hartkopp <[email protected]>
can: fix handling of unmodifiable configuration options fix

Wolfgang Grandegger <[email protected]>
can: at91_can: RX queue could get stuck at high bus load

Taras Kondratiuk <[email protected]>
mmc: block: fix packed command header endianness

Ursula Braun <[email protected]>
qeth: delete napi struct when removing a qeth device

Vegard Nossum <[email protected]>
ext4: verify extent header depth

Vineet Gupta <[email protected]>
ARC: use ASL assembler mnemonic

Jeff Mahoney <[email protected]>
ecryptfs: don't allow mmap when the lower fs doesn't support it

Jeff Mahoney <[email protected]>
Revert "ecryptfs: forbid opening files without mmap handler"

Tony Lindgren <[email protected]>
pinctrl: single: Fix missing flush of posted write for a wakeirq

Cameron Gutman <[email protected]>
Input: xpad - validate USB endpoint count during probe

Ping Cheng <[email protected]>

    Input: wacom_w8001 - w8001_MAX_LENGTH should be 13

Kangjie Lu <[email protected]>
ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt

Kangjie Lu <[email protected]>
ALSA: timer: Fix leak in events via snd_timer_user_ccallback

Kangjie Lu <[email protected]>
ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS

Andrey Grodzovsky <[email protected]>
xen/pciback: Fix conf_space read/write overlap check.

Alexey Brodkin <[email protected]>
arc: unwind: warn only once if DW2_UNWIND is disabled

Torsten Hilbrich <[email protected]>
fs/nilfs2: fix potential underflow in call to crc32_le

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

Diffstat:

 Makefile                                |   4 +-
 arch/arc/kernel/stacktrace.c            |   2 +-
 arch/arc/mm/tlbex.S                     |   6 +-
 drivers/input/joystick/xpad.c           |   3 +
 drivers/input/touchscreen/wacom_w8001.c |   2 +-
 drivers/mmc/card/block.c                |  12 +--
 drivers/net/can/at91_can.c              |   5 +-
 drivers/net/can/dev.c                   |   9 ++
 drivers/net/ethernet/marvell/mvneta.c   |   2 +-
 drivers/pinctrl/pinctrl-single.c        |   3 +
 drivers/s390/net/qeth_l2_main.c         |   1 +
 drivers/s390/net/qeth_l3_main.c         |   1 +
 drivers/scsi/ipr.c                      |   1 +
 drivers/xen/xen-pciback/conf_space.c    |   6 +-
 fs/ecryptfs/file.c                      |  15 +++-
 fs/ecryptfs/kthread.c                   |  13 +--
 fs/ext4/extents.c                       |   4 +
 fs/nilfs2/the_nilfs.c                   |   2 +-
 net/ceph/osdmap.c                       | 152 +++++++++++++++++++++++---------
 sound/core/timer.c                      |   3 +
 20 files changed, 169 insertions(+), 77 deletions(-)
author maintainer
#1 lore raw

PATCH 1/21 fs/nilfs2: fix potential underflow in call to crc32_le

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

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

From: Torsten Hilbrich <[email protected]>

commit 63d2f95d63396059200c391ca87161897b99e74a upstream.

The value `bytes' comes from the filesystem which is about to be mounted. We cannot trust that the value is always in the range we expect it to be.

Check its value before using it to calculate the length for the crc32_le call. It value must be larger (or equal) sumoff + 4.

This fixes a kernel bug when accidentially mounting an image file which had the nilfs2 magic value 0x3434 at the right offset 0x406 by chance. The bytes 0x01 0x00 were stored at 0x408 and were interpreted as a s_bytes value of 1. This caused an underflow when substracting sumoff + 4 (20) in the call to crc32_le.

  BUG: unable to handle kernel paging request at ffff88021e600000
  IP:  crc32_le+0x36/0x100
  ...
  Call Trace:
    nilfs_valid_sb.part.5+0x52/0x60 [nilfs2]
    nilfs_load_super_block+0x142/0x300 [nilfs2]
    init_nilfs+0x60/0x390 [nilfs2]
    nilfs_mount+0x302/0x520 [nilfs2]
    mount_fs+0x38/0x160
    vfs_kern_mount+0x67/0x110
    do_mount+0x269/0xe00
    SyS_mount+0x9f/0x100
    entry_SYSCALL_64_fastpath+0x16/0x71
---
 fs/nilfs2/the_nilfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nilfs2/the_nilfs.c +1 -1
@@ -431,7 +431,7 @@ static int nilfs_valid_sb(struct nilfs_s
 	if (!sbp || le16_to_cpu(sbp->s_magic) != NILFS_SUPER_MAGIC)
 		return 0;
 	bytes = le16_to_cpu(sbp->s_bytes);
-	if (bytes > BLOCK_SIZE)
+	if (bytes < sumoff + 4 || bytes > BLOCK_SIZE)
 		return 0;
 	crc = crc32_le(le32_to_cpu(sbp->s_crc_seed), (unsigned char *)sbp,
 		       sumoff);
author maintainer
#2 lore raw

PATCH 2/21 arc: unwind: warn only once if DW2_UNWIND is disabled

In reply to Greg Kroah-Hartman

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

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

From: Alexey Brodkin <[email protected]>

commit 9bd54517ee86cb164c734f72ea95aeba4804f10b upstream.

If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core() gets called following message gets printed in debug console:
----------------->8--------------- CONFIG_ARC_DW2_UNWIND needs to be enabled ----------------->8---------------

That message makes sense if user indeed wants to see a backtrace or get nice function call-graphs in perf but what if user disabled unwinder for the purpose? Why pollute his debug console?

So instead we'll warn user about possibly missing feature once and let him decide if that was what he or she really wanted.

---
 arch/arc/kernel/stacktrace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arc/kernel/stacktrace.c +1 -1
@@ -131,7 +131,7 @@ arc_unwind_core(struct task_struct *tsk,
 	 * prelogue is setup (callee regs saved and then fp set and not other
 	 * way around
 	 */
-	pr_warn("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
+	pr_warn_once("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
 	return 0;
 
 #endif
author maintainer
#3 lore raw

PATCH 3/21 xen/pciback: Fix conf_space read/write overlap check.

In reply to Greg Kroah-Hartman

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

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

From: Andrey Grodzovsky <[email protected]>

commit 02ef871ecac290919ea0c783d05da7eedeffc10e upstream.

Current overlap check is evaluating to false a case where a filter field is fully contained (proper subset) of a r/w request. This change applies classical overlap check instead to include all the scenarios.

More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver the logic is such that the entire confspace is read and written in 4 byte chunks. In this case as an example, CACHE_LINE_SIZE, LATENCY_TIMER and PCI_BIST are arriving together in one call to xen_pcibk_config_write() with offset == 0xc and size == 4. With the exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length == 1) is fully contained in the write request and hence is excluded from write, which is incorrect.

---
 drivers/xen/xen-pciback/conf_space.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/xen/xen-pciback/conf_space.c +2 -4
@@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev
 		field_start = OFFSET(cfg_entry);
 		field_end = OFFSET(cfg_entry) + field->size;
 
-		if ((req_start >= field_start && req_start < field_end)
-		    || (req_end > field_start && req_end <= field_end)) {
+		 if (req_end > field_start && field_end > req_start) {
 			err = conf_space_read(dev, cfg_entry, field_start,
 					      &tmp_val);
 			if (err)
@@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_de
 		field_start = OFFSET(cfg_entry);
 		field_end = OFFSET(cfg_entry) + field->size;
 
-		if ((req_start >= field_start && req_start < field_end)
-		    || (req_end > field_start && req_end <= field_end)) {
+		 if (req_end > field_start && field_end > req_start) {
 			tmp_val = 0;
 
 			err = xen_pcibk_config_read(dev, field_start,
author maintainer
#4 lore raw

PATCH 7/21 Input: wacom_w8001 - w8001_MAX_LENGTH should be 13

In reply to Greg Kroah-Hartman

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

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

From: Ping Cheng <[email protected]>

commit 12afb34400eb2b301f06b2aa3535497d14faee59 upstream.

Somehow the patch that added two-finger touch support forgot to update W8001_MAX_LENGTH from 11 to 13.

---
 drivers/input/touchscreen/wacom_w8001.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/touchscreen/wacom_w8001.c +1 -1
@@ -27,7 +27,7 @@ MODULE_AUTHOR("Jaya Kumar <jayakumar.lkm
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
 
-#define W8001_MAX_LENGTH	11
+#define W8001_MAX_LENGTH	13
 #define W8001_LEAD_MASK		0x80
 #define W8001_LEAD_BYTE		0x80
 #define W8001_TAB_MASK		0x40
author maintainer
#5 lore raw

PATCH 8/21 Input: xpad - validate USB endpoint count during probe

In reply to Greg Kroah-Hartman

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

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

From: Cameron Gutman <[email protected]>

commit caca925fca4fb30c67be88cacbe908eec6721e43 upstream.

This prevents a malicious USB device from causing an oops.

---
 drivers/input/joystick/xpad.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/input/joystick/xpad.c +3 -0
@@ -844,6 +844,9 @@ static int xpad_probe(struct usb_interfa
 	struct usb_endpoint_descriptor *ep_irq_in;
 	int i, error;
 
+	if (intf->cur_altsetting->desc.bNumEndpoints != 2)
+		return -ENODEV;
+
 	for (i = 0; xpad_device[i].idVendor; i++) {
 		if ((le16_to_cpu(udev->descriptor.idVendor) == xpad_device[i].idVendor) &&
 		    (le16_to_cpu(udev->descriptor.idProduct) == xpad_device[i].idProduct))
author maintainer
#6 lore raw

PATCH 9/21 pinctrl: single: Fix missing flush of posted write for a wakeirq

In reply to Greg Kroah-Hartman

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

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

From: Tony Lindgren <[email protected]>

commit 0ac3c0a4025f41748a083bdd4970cb3ede802b15 upstream.

With many repeated suspend resume cycles, the pin specific wakeirq may not always work on omaps. This is because the write to enable the pin interrupt may not have reached the device over the interconnect before suspend happens.

Let's fix the issue with a flush of posted write with a readback.

---
 drivers/pinctrl/pinctrl-single.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/pinctrl/pinctrl-single.c +3 -0
@@ -1616,6 +1616,9 @@ static inline void pcs_irq_set(struct pc
 		else
 			mask &= ~soc_mask;
 		pcs->write(mask, pcswi->reg);
+
+		/* flush posted write */
+		mask = pcs->read(pcswi->reg);
 		raw_spin_unlock(&pcs->lock);
 	}
 
author maintainer
#7 lore raw

PATCH 10/21 Revert "ecryptfs: forbid opening files without mmap handler"

In reply to Greg Kroah-Hartman

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

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

From: Jeff Mahoney <[email protected]>

commit 78c4e172412de5d0456dc00d2b34050aa0b683b5 upstream.

This reverts commit 2f36db71009304b3f0b95afacd8eba1f9f046b87.

It fixed a local root exploit but also introduced a dependency on the lower file system implementing an mmap operation just to open a file, which is a bit of a heavy hammer. The right fix is to have mmap depend on the existence of the mmap handler instead.

---
 fs/ecryptfs/kthread.c |   13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)
fs/ecryptfs/kthread.c +2 -11
@@ -25,7 +25,6 @@
 #include <linux/slab.h>
 #include <linux/wait.h>
 #include <linux/mount.h>
-#include <linux/file.h>
 #include "ecryptfs_kernel.h"
 
 struct ecryptfs_open_req {
@@ -148,7 +147,7 @@ int ecryptfs_privileged_open(struct file
 	flags |= IS_RDONLY(lower_dentry->d_inode) ? O_RDONLY : O_RDWR;
 	(*lower_file) = dentry_open(&req.path, flags, cred);
 	if (!IS_ERR(*lower_file))
-		goto have_file;
+		goto out;
 	if ((flags & O_ACCMODE) == O_RDONLY) {
 		rc = PTR_ERR((*lower_file));
 		goto out;
@@ -166,16 +165,8 @@ int ecryptfs_privileged_open(struct file
 	mutex_unlock(&ecryptfs_kthread_ctl.mux);
 	wake_up(&ecryptfs_kthread_ctl.wait);
 	wait_for_completion(&req.done);
-	if (IS_ERR(*lower_file)) {
+	if (IS_ERR(*lower_file))
 		rc = PTR_ERR(*lower_file);
-		goto out;
-	}
-have_file:
-	if ((*lower_file)->f_op->mmap == NULL) {
-		fput(*lower_file);
-		*lower_file = NULL;
-		rc = -EMEDIUMTYPE;
-	}
 out:
 	return rc;
 }
author maintainer
#8 lore raw

PATCH 11/21 ecryptfs: dont allow mmap when the lower fs doesnt support it

In reply to Greg Kroah-Hartman

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

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

From: Jeff Mahoney <[email protected]>

commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b upstream.

There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap support on file systems that don't offer support natively.

CVE-2016-1583

[tyhicks: clean up f_op check by using ecryptfs_file_to_lower()]
---
 fs/ecryptfs/file.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)
fs/ecryptfs/file.c +14 -1
@@ -178,6 +178,19 @@ out:
 	return rc;
 }
 
+static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	struct file *lower_file = ecryptfs_file_to_lower(file);
+	/*
+	 * Don't allow mmap on top of file systems that don't support it
+	 * natively.  If FILESYSTEM_MAX_STACK_DEPTH > 2 or ecryptfs
+	 * allows recursive mounting, this will need to be extended.
+	 */
+	if (!lower_file->f_op->mmap)
+		return -ENODEV;
+	return generic_file_mmap(file, vma);
+}
+
 /**
  * ecryptfs_open
  * @inode: inode speciying file to open
@@ -349,7 +362,7 @@ const struct file_operations ecryptfs_ma
 #ifdef CONFIG_COMPAT
 	.compat_ioctl = ecryptfs_compat_ioctl,
 #endif
-	.mmap = generic_file_mmap,
+	.mmap = ecryptfs_mmap,
 	.open = ecryptfs_open,
 	.flush = ecryptfs_flush,
 	.release = ecryptfs_release,
author maintainer
#9 lore raw

PATCH 12/21 ARC: use ASL assembler mnemonic

In reply to Greg Kroah-Hartman

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

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

From: Vineet Gupta <[email protected]>

commit a6416f57ce57fb390b6ee30b12c01c29032a26af upstream.

ARCompact and ARCv2 only have ASL, while binutils used to support LSL as a alias mnemonic.

Newer binutils (upstream) don't want to do that so replace it.

---
 arch/arc/mm/tlbex.S |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arc/mm/tlbex.S +3 -3
@@ -89,7 +89,7 @@ ex_saved_reg1:
 #ifdef CONFIG_SMP
 	sr  r0, [ARC_REG_SCRATCH_DATA0]	; freeup r0 to code with
 	GET_CPU_ID  r0			; get to per cpu scratch mem,
-	lsl r0, r0, L1_CACHE_SHIFT	; cache line wide per cpu
+	asl r0, r0, L1_CACHE_SHIFT	; cache line wide per cpu
 	add r0, @ex_saved_reg1, r0
 #else
 	st    r0, [@ex_saved_reg1]
@@ -108,7 +108,7 @@ ex_saved_reg1:
 .macro TLBMISS_RESTORE_REGS
 #ifdef CONFIG_SMP
 	GET_CPU_ID  r0			; get to per cpu scratch mem
-	lsl r0, r0, L1_CACHE_SHIFT	; each is cache line wide
+	asl r0, r0, L1_CACHE_SHIFT	; each is cache line wide
 	add r0, @ex_saved_reg1, r0
 	ld_s  r3, [r0,12]
 	ld_s  r2, [r0, 8]
@@ -220,7 +220,7 @@ ex_saved_reg1:
 
 .macro CONV_PTE_TO_TLB
 	and    r3, r0, PTE_BITS_RWX	;       r w x
-	lsl    r2, r3, 3		; r w x 0 0 0
+	asl    r2, r3, 3		; Kr Kw Kx 0  0  0 (GLOBAL, kernel only)
 	and.f  0,  r0, _PAGE_GLOBAL
 	or.z   r2, r2, r3		; r w x r w x
 
author maintainer
#10 lore raw

PATCH 13/21 ext4: verify extent header depth

In reply to Greg Kroah-Hartman

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

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

From: Vegard Nossum <[email protected]>

commit 7bc9491645118c9461bd21099c31755ff6783593 upstream.

Although the extent tree depth of 5 should enough be for the worst case of 2*32 extents of length 1, the extent tree code does not currently to merge nodes which are less than half-full with a sibling node, or to shrink the tree depth if possible. So it's possible, at least in theory, for the tree depth to be greater than 5. However, even in the worst case, a tree depth of 32 is highly unlikely, and if the file system is maliciously corrupted, an insanely large eh_depth can cause memory allocation failures that will trigger kernel warnings (here, eh_depth = 65280):

    JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max:256
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle+0x569/0x580
    CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #508
    Stack:
     604a8947 625badd8 0002fd09 00000000
     60078643 00000000 62623910 601bf9bc
     62623970 6002fc84 626239b0 900000125
    Call Trace:
     [<6001c2dc>] show_stack+0xdc/0x1a0
     [<601bf9bc>] dump_stack+0x2a/0x2e
     [<6002fc84>] __warn+0x114/0x140
     [<6002fdff>] warn_slowpath_null+0x1f/0x30
     [<60165829>] start_this_handle+0x569/0x580
     [<60165d4e>] jbd2__journal_start+0x11e/0x220
     [<60146690>] __ext4_journal_start_sb+0x60/0xa0
     [<60120a81>] ext4_truncate+0x131/0x3a0
     [<60123677>] ext4_setattr+0x757/0x840
     [<600d5d0f>] notify_change+0x16f/0x2a0
     [<600b2b16>] do_truncate+0x76/0xc0
     [<600c3e56>] path_openat+0x806/0x1300
     [<600c55c9>] do_filp_open+0x89/0xf0
     [<600b4074>] do_sys_open+0x134/0x1e0
     [<600b4140>] SyS_open+0x20/0x30
     [<6001ea68>] handle_syscall+0x88/0x90
     [<600295fd>] userspace+0x3fd/0x500
     [<6001ac55>] fork_handler+0x85/0x90

    ---[ end trace 08b0b88b6387a244 ]---

[ Commit message modified and the extent tree depath check changed from 5 to 32 -- tytso ]

---
 fs/ext4/extents.c |    4 ++++
 1 file changed, 4 insertions(+)
fs/ext4/extents.c +4 -0
@@ -452,6 +452,10 @@ static int __ext4_ext_check(const char *
 		error_msg = "invalid extent entries";
 		goto corrupted;
 	}
+	if (unlikely(depth > 32)) {
+		error_msg = "too large eh_depth";
+		goto corrupted;
+	}
 	/* Verify checksum on non-root extent tree nodes */
 	if (ext_depth(inode) != depth &&
 	    !ext4_extent_block_csum_verify(inode, eh)) {
author maintainer
#11 lore raw

PATCH 14/21 qeth: delete napi struct when removing a qeth device

In reply to Greg Kroah-Hartman

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

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

From: Ursula Braun <[email protected]>

commit 7831b4ff0d926e0deeaabef9db8800ed069a2757 upstream.

A qeth_card contains a napi_struct linked to the net_device during device probing. This struct must be deleted when removing the qeth device, otherwise Panic on oops can occur when qeth devices are repeatedly removed and added.

Fixes a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
---
 drivers/s390/net/qeth_l2_main.c |    1 +
 drivers/s390/net/qeth_l3_main.c |    1 +
 2 files changed, 2 insertions(+)
drivers/s390/net/qeth_l2_main.c +1 -0
@@ -906,6 +906,7 @@ static void qeth_l2_remove_device(struct
 		qeth_l2_set_offline(cgdev);
 
 	if (card->dev) {
+		netif_napi_del(&card->napi);
 		unregister_netdev(card->dev);
 		card->dev = NULL;
 	}
drivers/s390/net/qeth_l3_main.c +1 -0
@@ -3333,6 +3333,7 @@ static void qeth_l3_remove_device(struct
 		qeth_l3_set_offline(cgdev);
 
 	if (card->dev) {
+		netif_napi_del(&card->napi);
 		unregister_netdev(card->dev);
 		card->dev = NULL;
 	}
author maintainer
#12 lore raw

PATCH 15/21 mmc: block: fix packed command header endianness

In reply to Greg Kroah-Hartman

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

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

From: Taras Kondratiuk <[email protected]>

commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 upstream.

The code that fills packed command header assumes that CPU runs in little-endian mode. Hence the header is malformed in big-endian mode and causes MMC data transfer errors:

[  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1

Convert header data to LE.

Fixes ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
---
 drivers/mmc/card/block.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/mmc/card/block.c +6 -6
@@ -1610,8 +1610,8 @@ static void mmc_blk_packed_hdr_wrq_prep(
 
 	packed_cmd_hdr = packed->cmd_hdr;
 	memset(packed_cmd_hdr, 0, sizeof(packed->cmd_hdr));
-	packed_cmd_hdr[0] = (packed->nr_entries << 16) |
-		(PACKED_CMD_WR << 8) | PACKED_CMD_VER;
+	packed_cmd_hdr[0] = cpu_to_le32((packed->nr_entries << 16) |
+		(PACKED_CMD_WR << 8) | PACKED_CMD_VER);
 	hdr_blocks = mmc_large_sector(card) ? 8 : 1;
 
 	/*
@@ -1625,14 +1625,14 @@ static void mmc_blk_packed_hdr_wrq_prep(
 			((brq->data.blocks * brq->data.blksz) >=
 			 card->ext_csd.data_tag_unit_size);
 		/* Argument of CMD23 */
-		packed_cmd_hdr[(i * 2)] =
+		packed_cmd_hdr[(i * 2)] = cpu_to_le32(
 			(do_rel_wr ? MMC_CMD23_ARG_REL_WR : 0) |
 			(do_data_tag ? MMC_CMD23_ARG_TAG_REQ : 0) |
-			blk_rq_sectors(prq);
+			blk_rq_sectors(prq));
 		/* Argument of CMD18 or CMD25 */
-		packed_cmd_hdr[((i * 2)) + 1] =
+		packed_cmd_hdr[((i * 2)) + 1] = cpu_to_le32(
 			mmc_card_blockaddr(card) ?
-			blk_rq_pos(prq) : blk_rq_pos(prq) << 9;
+			blk_rq_pos(prq) : blk_rq_pos(prq) << 9);
 		packed->blocks += blk_rq_sectors(prq);
 		i++;
 	}
author maintainer
#13 lore raw

PATCH 16/21 can: at91_can: RX queue could get stuck at high bus load

In reply to Greg Kroah-Hartman

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

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

From: Wolfgang Grandegger <[email protected]>

commit 43200a4480cbbe660309621817f54cbb93907108 upstream.

At high bus load it could happen that "at91_poll()" enters with all RX message boxes filled up. If then at the end the "quota" is exceeded as well, "rx_next" will not be reset to the first RX mailbox and hence the interrupts remain disabled.

---
 drivers/net/can/at91_can.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/can/at91_can.c +3 -2
@@ -730,9 +730,10 @@ static int at91_poll_rx(struct net_devic
 
 	/* upper group completed, look again in lower */
 	if (priv->rx_next > get_mb_rx_low_last(priv) &&
-	    quota > 0 && mb > get_mb_rx_last(priv)) {
+	    mb > get_mb_rx_last(priv)) {
 		priv->rx_next = get_mb_rx_first(priv);
-		goto again;
+		if (quota > 0)
+			goto again;
 	}
 
 	return received;
author maintainer
#14 lore raw

PATCH 17/21 can: fix handling of unmodifiable configuration options fix

In reply to Greg Kroah-Hartman

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

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

From: Oliver Hartkopp <[email protected]>

commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.

With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable configuration options) a new can_validate() function was introduced.

When invoking 'ip link set can0 type can' without any configuration data can_validate() tries to validate the content without taking into account that there's totally no content. This patch adds a check for missing content.

---
 drivers/net/can/dev.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/net/can/dev.c +3 -0
@@ -665,6 +665,9 @@ static int can_changelink(struct net_dev
 		}
 	}
 
+	if (!data)
+		return 0;
+
 	if (data[IFLA_CAN_CTRLMODE]) {
 		struct can_ctrlmode *cm;
 
author maintainer
#15 lore raw

PATCH 18/21 can: fix oops caused by wrong rtnl dellink usage

In reply to Greg Kroah-Hartman

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

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

From: Oliver Hartkopp <[email protected]>

commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 upstream.

For 'real' hardware CAN devices the netlink interface is used to set CAN specific communication parameters. Real CAN hardware can not be created nor removed with the ip tool ...

This patch adds a private dellink function for the CAN device driver interface that does just nothing.

It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl newlink usage") but for dellink.

---
 drivers/net/can/dev.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/net/can/dev.c +6 -0
@@ -771,6 +771,11 @@ static int can_newlink(struct net *src_n
 	return -EOPNOTSUPP;
 }
 
+static void can_dellink(struct net_device *dev, struct list_head *head)
+{
+	return;
+}
+
 static struct rtnl_link_ops can_link_ops __read_mostly = {
 	.kind		= "can",
 	.maxtype	= IFLA_CAN_MAX,
@@ -778,6 +783,7 @@ static struct rtnl_link_ops can_link_ops
 	.setup		= can_setup,
 	.newlink	= can_newlink,
 	.changelink	= can_changelink,
+	.dellink	= can_dellink,
 	.get_size	= can_get_size,
 	.fill_info	= can_fill_info,
 	.get_xstats_size = can_get_xstats_size,
author maintainer
#16 lore raw

PATCH 19/21 ipr: Clear interrupt on croc/crocodile when running with LSI

In reply to Greg Kroah-Hartman

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

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

From: Brian King <[email protected]>

commit 54e430bbd490e18ab116afa4cd90dcc45787b3df upstream.

If we fall back to using LSI on the Croc or Crocodile chip we need to clear the interrupt so we don't hang the system.

---
 drivers/scsi/ipr.c |    1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ipr.c +1 -0
@@ -9644,6 +9644,7 @@ static int ipr_probe_ioa(struct pci_dev
 		ioa_cfg->intr_flag = IPR_USE_MSI;
 	else {
 		ioa_cfg->intr_flag = IPR_USE_LSI;
+		ioa_cfg->clear_isr = 1;
 		ioa_cfg->nvectors = 1;
 		dev_info(&pdev->dev, "Cannot enable MSI.\n");
 	}
author maintainer
#17 lore raw

PATCH 20/21 libceph: apply new_state before new_up_client on incrementals

In reply to Greg Kroah-Hartman

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

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

From: Ilya Dryomov <[email protected]>

commit 930c532869774ebf8af9efe9484c597f896a7d46 upstream.

Currently, osd_weight and osd_state fields are updated in the encoding order. This is wrong, because an incremental map may look like e.g.

new_up_client: { osd=6, addr=... } # set osd_state and addr
new_state: { osd=6, xorstate=EXISTS } # clear osd_state

Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down). After applying new_up_client, osd_state is changed to EXISTS | UP. Carrying on with the new_state update, we flip EXISTS and leave osd6 in a weird "!EXISTS but UP" state. A non-existent OSD is considered down by the mapping code

2087 for (i = 0; i < pg->pg_temp.len; i++) {
2088 if (ceph_osd_is_down(osdmap, pg->pg_temp.osds[i])) {
2089 if (ceph_can_shift_osds(pi))
2090 continue;
2091
2092 temp->osds[temp->size++] = CRUSH_ITEM_NONE;

and so requests get directed to the second OSD in the set instead of the first, resulting in OSD-side errors like:

[WRN] : client.4239 192.168.122.21:0/2444980242 misdirected client.4239.1:2827 pg 2.5df899f2 to osd.4 not [1,4,6] in e680/680

and hung rbds on the client:

[  493.566367] rbd: rbd0: write 400000 at 11cc00000 (0)
[  493.566805] rbd: rbd0:   result -6 xferred 400000
[  493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688

The fix is to decouple application from the decoding and:
- apply new_weight first
- apply new_state before new_up_client
- twiddle osd_state flags if marking in
- clear out some of the state if osd is destroyed

[[email protected]: backport to 3.10-3.14: strip primary-affinity]
---
 net/ceph/osdmap.c |  152 ++++++++++++++++++++++++++++++++++++++----------------
 1 file changed, 108 insertions(+), 44 deletions(-)
net/ceph/osdmap.c +108 -44
@@ -825,6 +825,110 @@ bad:
 }
 
 /*
+ * Encoding order is (new_up_client, new_state, new_weight).  Need to
+ * apply in the (new_weight, new_state, new_up_client) order, because
+ * an incremental map may look like e.g.
+ *
+ *     new_up_client: { osd=6, addr=... } # set osd_state and addr
+ *     new_state: { osd=6, xorstate=EXISTS } # clear osd_state
+ */
+static int decode_new_up_state_weight(void **p, void *end,
+				      struct ceph_osdmap *map)
+{
+	void *new_up_client;
+	void *new_state;
+	void *new_weight_end;
+	u32 len;
+
+	new_up_client = *p;
+	ceph_decode_32_safe(p, end, len, e_inval);
+	len *= sizeof(u32) + sizeof(struct ceph_entity_addr);
+	ceph_decode_need(p, end, len, e_inval);
+	*p += len;
+
+	new_state = *p;
+	ceph_decode_32_safe(p, end, len, e_inval);
+	len *= sizeof(u32) + sizeof(u8);
+	ceph_decode_need(p, end, len, e_inval);
+	*p += len;
+
+	/* new_weight */
+	ceph_decode_32_safe(p, end, len, e_inval);
+	while (len--) {
+		s32 osd;
+		u32 w;
+
+		ceph_decode_need(p, end, 2*sizeof(u32), e_inval);
+		osd = ceph_decode_32(p);
+		w = ceph_decode_32(p);
+		BUG_ON(osd >= map->max_osd);
+		pr_info("osd%d weight 0x%x %s\n", osd, w,
+		     w == CEPH_OSD_IN ? "(in)" :
+		     (w == CEPH_OSD_OUT ? "(out)" : ""));
+		map->osd_weight[osd] = w;
+
+		/*
+		 * If we are marking in, set the EXISTS, and clear the
+		 * AUTOOUT and NEW bits.
+		 */
+		if (w) {
+			map->osd_state[osd] |= CEPH_OSD_EXISTS;
+			map->osd_state[osd] &= ~(CEPH_OSD_AUTOOUT |
+						 CEPH_OSD_NEW);
+		}
+	}
+	new_weight_end = *p;
+
+	/* new_state (up/down) */
+	*p = new_state;
+	len = ceph_decode_32(p);
+	while (len--) {
+		s32 osd;
+		u8 xorstate;
+
+		osd = ceph_decode_32(p);
+		xorstate = ceph_decode_8(p);
+		if (xorstate == 0)
+			xorstate = CEPH_OSD_UP;
+		BUG_ON(osd >= map->max_osd);
+		if ((map->osd_state[osd] & CEPH_OSD_UP) &&
+		    (xorstate & CEPH_OSD_UP))
+			pr_info("osd%d down\n", osd);
+		if ((map->osd_state[osd] & CEPH_OSD_EXISTS) &&
+		    (xorstate & CEPH_OSD_EXISTS)) {
+			pr_info("osd%d does not exist\n", osd);
+			map->osd_weight[osd] = CEPH_OSD_IN;
+			memset(map->osd_addr + osd, 0, sizeof(*map->osd_addr));
+			map->osd_state[osd] = 0;
+		} else {
+			map->osd_state[osd] ^= xorstate;
+		}
+	}
+
+	/* new_up_client */
+	*p = new_up_client;
+	len = ceph_decode_32(p);
+	while (len--) {
+		s32 osd;
+		struct ceph_entity_addr addr;
+
+		osd = ceph_decode_32(p);
+		ceph_decode_copy(p, &addr, sizeof(addr));
+		ceph_decode_addr(&addr);
+		BUG_ON(osd >= map->max_osd);
+		pr_info("osd%d up\n", osd);
+		map->osd_state[osd] |= CEPH_OSD_EXISTS | CEPH_OSD_UP;
+		map->osd_addr[osd] = addr;
+	}
+
+	*p = new_weight_end;
+	return 0;
+
+e_inval:
+	return -EINVAL;
+}
+
+/*
  * decode and apply an incremental map update.
  */
 struct ceph_osdmap *osdmap_apply_incremental(void **p, void *end,
@@ -939,50 +1043,10 @@ struct ceph_osdmap *osdmap_apply_increme
 			__remove_pg_pool(&map->pg_pools, pi);
 	}
 
-	/* new_up */
-	err = -EINVAL;
-	ceph_decode_32_safe(p, end, len, bad);
-	while (len--) {
-		u32 osd;
-		struct ceph_entity_addr addr;
-		ceph_decode_32_safe(p, end, osd, bad);
-		ceph_decode_copy_safe(p, end, &addr, sizeof(addr), bad);
-		ceph_decode_addr(&addr);
-		pr_info("osd%d up\n", osd);
-		BUG_ON(osd >= map->max_osd);
-		map->osd_state[osd] |= CEPH_OSD_UP;
-		map->osd_addr[osd] = addr;
-	}
-
-	/* new_state */
-	ceph_decode_32_safe(p, end, len, bad);
-	while (len--) {
-		u32 osd;
-		u8 xorstate;
-		ceph_decode_32_safe(p, end, osd, bad);
-		xorstate = **(u8 **)p;
-		(*p)++;  /* clean flag */
-		if (xorstate == 0)
-			xorstate = CEPH_OSD_UP;
-		if (xorstate & CEPH_OSD_UP)
-			pr_info("osd%d down\n", osd);
-		if (osd < map->max_osd)
-			map->osd_state[osd] ^= xorstate;
-	}
-
-	/* new_weight */
-	ceph_decode_32_safe(p, end, len, bad);
-	while (len--) {
-		u32 osd, off;
-		ceph_decode_need(p, end, sizeof(u32)*2, bad);
-		osd = ceph_decode_32(p);
-		off = ceph_decode_32(p);
-		pr_info("osd%d weight 0x%x %s\n", osd, off,
-		     off == CEPH_OSD_IN ? "(in)" :
-		     (off == CEPH_OSD_OUT ? "(out)" : ""));
-		if (osd < map->max_osd)
-			map->osd_weight[osd] = off;
-	}
+	/* new_up_client, new_state, new_weight */
+	err = decode_new_up_state_weight(p, end, map);
+	if (err)
+		goto bad;
 
 	/* new_pg_temp */
 	ceph_decode_32_safe(p, end, len, bad);
author maintainer
#18 lore raw

PATCH 21/21 net: mvneta: set real interrupt per packet for tx_done

In reply to Greg Kroah-Hartman

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

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

From: Dmitri Epshtein <[email protected]>

commit 06708f81528725148473c0869d6af5f809c6824b upstream.

Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to set coalescing threshold to a value guaranteeing interrupt generation per each sent packet, so that buffers can be released with no delay.

In fact setting threshold to '1' was wrong, because it causes interrupt every two packets. According to the documentation a reason behind it is following - interrupt occurs once sent buffers counter reaches a value, which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This behavior was confirmed during tests. Also when testing the SoC working as a NAS device, better performance was observed with int-per-packet, as it strongly depends on the fact that all transmitted packets are released immediately.

This commit enables NETA controller work in interrupt per sent packet mode by setting coalescing threshold to 0.

Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")

---
 drivers/net/ethernet/marvell/mvneta.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/mvneta.c +1 -1
@@ -213,7 +213,7 @@
 /* Various constants */
 
 /* Coalescing */
-#define MVNETA_TXDONE_COAL_PKTS		1
+#define MVNETA_TXDONE_COAL_PKTS		0	/* interrupt per packet */
 #define MVNETA_RX_COAL_PKTS		32
 #define MVNETA_RX_COAL_USEC		100
 
#19 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.14.75 release. There are 21 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 Aug 10 18:01:28 UTC 2016. Anything received after that time might be too late.

Build results:

	total: 131 pass: 131 fail: 0
Qemu test results:
	total: 89 pass: 89 fail: 0

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

Guenter

author maintainer
#20 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.14.75 release. There are 21 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 Aug 10 18:01:28 UTC 2016. Anything received after that time might be too late.

Quoted 6 lines

Build results:

	total: 131 pass: 131 fail: 0
Qemu test results:
	total: 89 pass: 89 fail: 0

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

thanks for testing and letting me know.

greg k-h

#21 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.14.75 release. There are 21 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.

Quoted 9 lines

Responses should be made by Wed Aug 10 18:01:28 UTC 2016. 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/v3.x/stable-review/patch-3.14.75-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-3.14.y
and the diffstat can be found below.

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

thanks,
-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
[email protected]