4.9.96-stable review

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/n_tty.c  |    6 ++++++
 drivers/tty/tty_io.c |    9 +++++++++
 include/linux/tty.h  |    1 +
 3 files changed, 16 insertions(+)

drivers/tty/n_tty.c +6 -0

@@ -2182,6 +2182,12 @@ static ssize_t n_tty_read(struct tty_str
 				}
 				if (tty_hung_up_p(file))
 					break;
+				/*
+				 * Abort readers for ttys which never actually
+				 * get hung up.  See __tty_hangup().
+				 */
+				if (test_bit(TTY_HUPPING, &tty->flags))
+					break;
 				if (!timeout)
 					break;
 				if (file->f_flags & O_NONBLOCK) {

drivers/tty/tty_io.c +9 -0

@@ -709,6 +709,14 @@ static void __tty_hangup(struct tty_stru
 		return;
 	}
 
+	/*
+	 * Some console devices aren't actually hung up for technical and
+	 * historical reasons, which can lead to indefinite interruptible
+	 * sleep in n_tty_read().  The following explicitly tells
+	 * n_tty_read() to abort readers.
+	 */
+	set_bit(TTY_HUPPING, &tty->flags);
+
 	/* inuse_filps is protected by the single tty lock,
 	   this really needs to change if we want to flush the
 	   workqueue with the lock held */

@@ -763,6 +771,7 @@ static void __tty_hangup(struct tty_stru
 	 * from the ldisc side, which is now guaranteed.
 	 */
 	set_bit(TTY_HUPPED, &tty->flags);
+	clear_bit(TTY_HUPPING, &tty->flags);
 	tty_unlock(tty);
 
 	if (f)

include/linux/tty.h +1 -0

@@ -355,6 +355,7 @@ struct tty_file_private {
 #define TTY_PTY_LOCK 		16	/* pty private */
 #define TTY_NO_WRITE_SPLIT 	17	/* Preserve write boundaries to driver */
 #define TTY_HUPPED 		18	/* Post driver->hangup() */
+#define TTY_HUPPING		19	/* Hangup in progress */
 #define TTY_LDISC_HALTED	22	/* Line discipline is halted */
 
 /* Values for tty->flow_change */

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #2 lore raw

PATCH 2/95 ubifs: Check ubifs_wbuf_sync() return code

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

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

From: Richard Weinberger <[email protected]>

commit aac17948a7ce01fb60b9ee6cf902967a47b3ce26 upstream.

If ubifs_wbuf_sync() fails we must not write a master node with the dirty marker cleared.
Otherwise it is possible that in case of an IO error while syncing we mark the filesystem as clean and UBIFS refuses to recover upon next mount.

Fixes 1e51764a3c2a ("UBIFS: add new flash file system")

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ubifs/super.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

fs/ubifs/super.c +10 -4

@@ -1728,8 +1728,11 @@ static void ubifs_remount_ro(struct ubif
 
 	dbg_save_space_info(c);
 
-	for (i = 0; i < c->jhead_cnt; i++)
-		ubifs_wbuf_sync(&c->jheads[i].wbuf);
+	for (i = 0; i < c->jhead_cnt; i++) {
+		err = ubifs_wbuf_sync(&c->jheads[i].wbuf);
+		if (err)
+			ubifs_ro_mode(c, err);
+	}
 
 	c->mst_node->flags &= ~cpu_to_le32(UBIFS_MST_DIRTY);
 	c->mst_node->flags |= cpu_to_le32(UBIFS_MST_NO_ORPHS);

@@ -1795,8 +1798,11 @@ static void ubifs_put_super(struct super
 			int err;
 
 			/* Synchronize write-buffers */
-			for (i = 0; i < c->jhead_cnt; i++)
-				ubifs_wbuf_sync(&c->jheads[i].wbuf);
+			for (i = 0; i < c->jhead_cnt; i++) {
+				err = ubifs_wbuf_sync(&c->jheads[i].wbuf);
+				if (err)
+					ubifs_ro_mode(c, err);
+			}
 
 			/*
 			 * We are being cleanly unmounted which means the

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #3 lore raw

PATCH 3/95 ubi: fastmap: Dont flush fastmap work on detach

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

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

From: Richard Weinberger <[email protected]>

commit 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 upstream.

At this point UBI volumes have already been free()'ed and fastmap can no longer access these data structures.

Reported-by Martin Townsend <[email protected]>

Fixes 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/ubi/fastmap-wl.c |    1 -
 1 file changed, 1 deletion(-)

drivers/mtd/ubi/fastmap-wl.c +0 -1

@@ -362,7 +362,6 @@ static void ubi_fastmap_close(struct ubi
 {
 	int i;
 
-	flush_work(&ubi->fm_work);
 	return_unused_pool_pebs(ubi, &ubi->fm_pool);
 	return_unused_pool_pebs(ubi, &ubi->fm_wl_pool);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #4 lore raw

PATCH 4/95 ubi: Fix error for write access

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

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

From: Romain Izard <[email protected]>

commit 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d upstream.

When opening a device with write access, ubiblock_open returns an error code. Currently, this error code is -EPERM, but this is not the right value.

The open function for other block devices returns -EROFS when opening read-only devices with FMODE_WRITE set. When used with dm-verity, the veritysetup userspace tool is expecting EROFS, and refuses to use the ubiblock device.

Use -EROFS for ubiblock as well. As a result, veritysetup accepts the ubiblock device as valid.

Fixes 9d54c8a33eec (UBI: R/O block driver on top of UBI volumes)

Signed-off-by Romain Izard <[email protected]>

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/ubi/block.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mtd/ubi/block.c +1 -1

@@ -244,7 +244,7 @@ static int ubiblock_open(struct block_de
 	 * in any case.
 	 */
 	if (mode & FMODE_WRITE) {
-		ret = -EPERM;
+		ret = -EROFS;
 		goto out_unlock;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #5 lore raw

PATCH 5/95 ubi: Reject MLC NAND

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

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

From: Richard Weinberger <[email protected]>

commit b5094b7f135be34630e3ea8a98fa215715d0f29d upstream.

While UBI and UBIFS seem to work at first sight with MLC NAND, you will most likely lose all your data upon a power-cut or due to read/write disturb.
In order to protect users from bad surprises, refuse to attach to MLC NAND.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Boris Brezillon <[email protected]>

Acked-by Artem Bityutskiy <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/ubi/build.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/mtd/ubi/build.c +11 -0

@@ -894,6 +894,17 @@ int ubi_attach_mtd_dev(struct mtd_info *
 		return -EINVAL;
 	}
 
+	/*
+	 * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes.
+	 * MLC NAND is different and needs special care, otherwise UBI or UBIFS
+	 * will die soon and you will lose all your data.
+	 */
+	if (mtd->type == MTD_MLCNANDFLASH) {
+		pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
+			mtd->index);
+		return -EINVAL;
+	}
+
 	if (ubi_num == UBI_DEV_NUM_AUTO) {
 		/* Search for an empty slot in the @ubi_devices array */
 		for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #6 lore raw

PATCH 6/95 fs/reiserfs/journal.c: add missing resierfs_warning() arg

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

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

From: Andrew Morton <[email protected]>

commit 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 upstream.

One use of the reiserfs_warning() macro in journal_init_dev() is missing a parameter, causing the following warning:

REISERFS warning (device loop0): journal_init_dev: Cannot open '%s': %i journal_init_dev:

This also causes a WARN_ONCE() warning in the vsprintf code, and then a panic if panic_on_warn is set.

Please remove unsupported %/ in format string

  WARNING: CPU: 1 PID: 4480 at lib/vsprintf.c:2138 format_decode+0x77f/0x830 lib/vsprintf.c:2138
  Kernel panic - not syncing: panic_on_warn set ...

Just add another string argument to the macro invocation.

Addresses https://syzkaller.appspot.com/bug?id=0627d4551fdc39bf1ef5d82cd9eef587047f7718

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Randy Dunlap <[email protected]>

Reported-by <[email protected]>

Tested-by Randy Dunlap <[email protected]>

Acked-by Jeff Mahoney <[email protected]>

Cc Alexander Viro <[email protected]>

Cc Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/reiserfs/journal.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/reiserfs/journal.c +1 -1

@@ -2640,7 +2640,7 @@ static int journal_init_dev(struct super
 	if (IS_ERR(journal->j_dev_bd)) {
 		result = PTR_ERR(journal->j_dev_bd);
 		journal->j_dev_bd = NULL;
-		reiserfs_warning(super,
+		reiserfs_warning(super, "sh-457",
 				 "journal_init_dev: Cannot open '%s': %i",
 				 jdev_name, result);
 		return result;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #7 lore raw

PATCH 7/95 resource: fix integer overflow at reallocation

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

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

From: Takashi Iwai <[email protected]>

commit 60bb83b81169820c691fbfa33a6a4aef32aa4b0b upstream.

We've got a bug report indicating a kernel panic at booting on an x86-32 system, and it turned out to be the invalid PCI resource assigned after reallocation. __find_resource() first aligns the resource start address and resets the end address with start+size-1 accordingly, then checks whether it's contained. Here the end address may overflow the integer, although resource_contains() still returns true because the function validates only start and end address. So this ends up with returning an invalid resource (start > end).

There was already an attempt to cover such a problem in the commit 47ea91b4052d ("Resource: fix wrong resource window calculation"), but this case is an overseen one.

This patch adds the validity check of the newly calculated resource for avoiding the integer overflow problem.

Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 23c570a67448 ("resource: ability to resize an allocated resource")

Reported-by Michael Henders <[email protected]>

Tested-by Michael Henders <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Ram Pai <[email protected]>

Cc Bjorn Helgaas <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/resource.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

kernel/resource.c +2 -1

@@ -633,7 +633,8 @@ static int __find_resource(struct resour
 			alloc.start = constraint->alignf(constraint->alignf_data, &avail,
 					size, constraint->align);
 			alloc.end = alloc.start + size - 1;
-			if (resource_contains(&avail, &alloc)) {
+			if (alloc.start <= alloc.end &&
+			    resource_contains(&avail, &alloc)) {
 				new->start = alloc.start;
 				new->end = alloc.end;
 				return 0;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #8 lore raw

PATCH 8/95 ipc/shm: fix use-after-free of shm file via remap_file_pages()

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

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

From: Eric Biggers <[email protected]>

commit 3f05317d9889ab75c7190dcd39491d2a97921984 upstream.

syzbot reported a use-after-free of shm_file_data(file)->file->f_op in shm_get_unmapped_area(), called via sys_remap_file_pages().

Unfortunately it couldn't generate a reproducer, but I found a bug which I think caused it. When remap_file_pages() is passed a full System V shared memory segment, the memory is first unmapped, then a new map is created using the ->vm_file. Between these steps, the shm ID can be removed and reused for a new shm segment. But, shm_mmap() only checks whether the ID is currently valid before calling the underlying file's ->mmap(); it doesn't check whether it was reused. Thus it can use the wrong underlying file, one that was already freed.

Fix this by making the "outer" shm file (the one that gets put in ->vm_file) hold a reference to the real shm file, and by making __shm_open() require that the file associated with the shm ID matches the one associated with the "outer" file.

Taking the reference to the real shm file is needed to fully solve the problem, since otherwise sfd->file could point to a freed file, which then could be reallocated for the reused shm ID, causing the wrong shm segment to be mapped (and without the required permission checks).

Commit 1ac0b6dec656 ("ipc/shm: handle removed segments gracefully in shm_mmap()") almost fixed this bug, but it didn't go far enough because it didn't consider the case where the shm ID is reused.

The following program usually reproduces this bug:

	#include <stdlib.h>
	#include <sys/shm.h>
	#include <sys/syscall.h>
	#include <unistd.h>

	int main()
	{
		int is_parent = (fork() != 0);
		srand(getpid());
		for (;;) {
			int id = shmget(0xF00F, 4096, IPC_CREAT|0700);
			if (is_parent) {
				void *addr = shmat(id, NULL, 0);
				usleep(rand() % 50);
				while (!syscall(__NR_remap_file_pages, addr, 4096, 0, 0, 0));
			} else {
				usleep(rand() % 50);
				shmctl(id, IPC_RMID, NULL);
			}
		}
	}

It causes the following NULL pointer dereference due to a 'struct file' being used while it's being freed. (I couldn't actually get a KASAN use-after-free splat like in the syzbot report. But I think it's possible with this bug; it would just take a more extraordinary race...)

	BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
	PGD 0 P4D 0
	Oops: 0000 [#1] SMP NOPTI
	CPU: 9 PID: 258 Comm: syz_ipc Not tainted 4.16.0-05140-gf8cf2f16a7c95 #189
	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
	RIP: 0010:d_inode include/linux/dcache.h:519 [inline]
	RIP: 0010:touch_atime+0x25/0xd0 fs/inode.c:1724
	[...]
	Call Trace:
	 file_accessed include/linux/fs.h:2063 [inline]
	 shmem_mmap+0x25/0x40 mm/shmem.c:2149
	 call_mmap include/linux/fs.h:1789 [inline]
	 shm_mmap+0x34/0x80 ipc/shm.c:465
	 call_mmap include/linux/fs.h:1789 [inline]
	 mmap_region+0x309/0x5b0 mm/mmap.c:1712
	 do_mmap+0x294/0x4a0 mm/mmap.c:1483
	 do_mmap_pgoff include/linux/mm.h:2235 [inline]
	 SYSC_remap_file_pages mm/mmap.c:2853 [inline]
	 SyS_remap_file_pages+0x232/0x310 mm/mmap.c:2769
	 do_syscall_64+0x64/0x1a0 arch/x86/entry/common.c:287
	 entry_SYSCALL_64_after_hwframe+0x42/0xb7

[[email protected]: add comment]

Link http://lkml.kernel.org/r/[email protected] open here

Reported-by syzbot+d11f321e7f1923157eac80aa990b446596f46439@syzkaller.appspotmail.com

Fixes c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation")

Signed-off-by Eric Biggers <[email protected]>

Acked-by Kirill A. Shutemov <[email protected]>

Acked-by Davidlohr Bueso <[email protected]>

Cc Manfred Spraul <[email protected]>

Cc "Eric W . Biederman" <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 ipc/shm.c |   23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

ipc/shm.c +20 -3

@@ -198,6 +198,12 @@ static int __shm_open(struct vm_area_str
 	if (IS_ERR(shp))
 		return PTR_ERR(shp);
 
+	if (shp->shm_file != sfd->file) {
+		/* ID was reused */
+		shm_unlock(shp);
+		return -EINVAL;
+	}
+
 	shp->shm_atim = get_seconds();
 	shp->shm_lprid = task_tgid_vnr(current);
 	shp->shm_nattch++;

@@ -425,8 +431,9 @@ static int shm_mmap(struct file *file, s
 	int ret;
 
 	/*
-	 * In case of remap_file_pages() emulation, the file can represent
-	 * removed IPC ID: propogate shm_lock() error to caller.
+	 * In case of remap_file_pages() emulation, the file can represent an
+	 * IPC ID that was removed, and possibly even reused by another shm
+	 * segment already.  Propagate this case as an error to caller.
 	 */
 	ret =__shm_open(vma);
 	if (ret)

@@ -450,6 +457,7 @@ static int shm_release(struct inode *ino
 	struct shm_file_data *sfd = shm_file_data(file);
 
 	put_ipc_ns(sfd->ns);
+	fput(sfd->file);
 	shm_file_data(file) = NULL;
 	kfree(sfd);
 	return 0;

@@ -1212,7 +1220,16 @@ long do_shmat(int shmid, char __user *sh
 	file->f_mapping = shp->shm_file->f_mapping;
 	sfd->id = shp->shm_perm.id;
 	sfd->ns = get_ipc_ns(ns);
-	sfd->file = shp->shm_file;
+	/*
+	 * We need to take a reference to the real shm file to prevent the
+	 * pointer from becoming stale in cases where the lifetime of the outer
+	 * file extends beyond that of the shm segment.  It's not usually
+	 * possible, but it can happen during remap_file_pages() emulation as
+	 * that unmaps the memory, then does ->mmap() via file reference only.
+	 * We'll deny the ->mmap() if the shm segment was since removed, but to
+	 * detect shm ID reuse we need to compare the file pointers.
+	 */
+	sfd->file = get_file(shp->shm_file);
 	sfd->vm_ops = NULL;
 
 	err = security_mmap_file(file, prot, flags);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #9 lore raw

PATCH 9/95 mm, slab: reschedule cache_reap() on the same CPU

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

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

From: Vlastimil Babka <[email protected]>

commit a9f2a846f0503e7d729f552e3ccfe2279010fe94 upstream.

cache_reap() is initially scheduled in start_cpu_timer() via schedule_delayed_work_on(). But then the next iterations are scheduled via schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND.

Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") there is no guarantee the future iterations will run on the originally intended cpu, although it's still preferred. I was able to demonstrate this with /sys/module/workqueue/parameters/debug_force_rr_cpu. IIUC, it may also happen due to migrating timers in nohz context. As a result, some cpu's would be calling cache_reap() more frequently and others never.

This patch uses schedule_delayed_work_on() with the current cpu when scheduling the next iteration.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs")

Signed-off-by Vlastimil Babka <[email protected]>

Acked-by Pekka Enberg <[email protected]>

Acked-by Christoph Lameter <[email protected]>

Cc Joonsoo Kim <[email protected]>

Cc David Rientjes <[email protected]>

Cc Tejun Heo <[email protected]>

Cc Lai Jiangshan <[email protected]>

Cc John Stultz <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Stephen Boyd <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 mm/slab.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

mm/slab.c +2 -1

@@ -4096,7 +4096,8 @@ next:
 	next_reap_node();
 out:
 	/* Set up the next iteration */
-	schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
+	schedule_delayed_work_on(smp_processor_id(), work,
+				round_jiffies_relative(REAPTIMEOUT_AC));
 }
 
 #ifdef CONFIG_SLABINFO

Greg Kroah-Hartman

author maintainer

2018-04-22 14:11 UTC #10 lore raw

PATCH 10/95 usb: musb: gadget: misplaced out of bounds check

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

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

From: Heinrich Schuchardt <[email protected]>

commit af6f8529098aeb0e56a68671b450cf74e7a64fcd upstream.

musb->endpoints[] has array size MUSB_C_NUM_EPS.
We must check array bounds before accessing the array and not afterwards.

Signed-off-by Heinrich Schuchardt <[email protected]>

Signed-off-by Bin Liu <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/musb/musb_gadget_ep0.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/usb/musb/musb_gadget_ep0.c +9 -5

@@ -114,15 +114,19 @@ static int service_tx_status_request(
 		}
 
 		is_in = epnum & USB_DIR_IN;
-		if (is_in) {
-			epnum &= 0x0f;
+		epnum &= 0x0f;
+		if (epnum >= MUSB_C_NUM_EPS) {
+			handled = -EINVAL;
+			break;
+		}
+
+		if (is_in)
 			ep = &musb->endpoints[epnum].ep_in;
-		} else {
+		else
 			ep = &musb->endpoints[epnum].ep_out;
-		}
 		regs = musb->endpoints[epnum].regs;
 
-		if (epnum >= MUSB_C_NUM_EPS || !ep->desc) {
+		if (!ep->desc) {
 			handled = -EINVAL;
 			break;
 		}

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #11 lore raw

PATCH 11/95 usb: gadget: udc: core: update usb_ep_queue() documentation

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

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

From: Felipe Balbi <[email protected]>

commit eaa358c7790338d83bb6a31258bdc077de120414 upstream.

Mention that ->complete() should never be called from within usb_ep_queue().

Signed-off-by Felipe Balbi <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/udc/core.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/usb/gadget/udc/core.c +3 -0

@@ -248,6 +248,9 @@ EXPORT_SYMBOL_GPL(usb_ep_free_request);
  * arranges to poll once per interval, and the gadget driver usually will
  * have queued some data to transfer at that time.
  *
+ * Note that @req's ->complete() callback must never be called from
+ * within usb_ep_queue() as that can create deadlock situations.
+ *
  * Returns zero, or a negative error code.  Endpoints that are not enabled
  * report errors; errors will also be
  * reported when the usb peripheral is disconnected.

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #12 lore raw

PATCH 12/95 ARM: dts: at91: at91sam9g25: fix mux-mask pinctrl property

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

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

From: Nicolas Ferre <[email protected]>

commit e8fd0adf105e132fd84545997bbef3d5edc2c9c1 upstream.

There are only 19 PIOB pins having primary names PB0-PB18. Not all of them have a 'C' function. So the pinctrl property mask ends up being the same as the other SoC of the at91sam9x5 series.

Reported-by Marek Sieranski <[email protected]>

Signed-off-by Nicolas Ferre <[email protected]>

Cc <[email protected]> # v3.8+

Signed-off-by Alexandre Belloni <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

arch/arm/boot/dts/at91sam9g25.dtsi +1 -1

@@ -21,7 +21,7 @@
 				atmel,mux-mask = <
 				      /*    A         B          C     */
 				       0xffffffff 0xffe0399f 0xc000001c  /* pioA */
-				       0x0007ffff 0x8000fe3f 0x00000000  /* pioB */
+				       0x0007ffff 0x00047e3f 0x00000000  /* pioB */
 				       0x80000000 0x07c0ffff 0xb83fffff  /* pioC */
 				       0x003fffff 0x003f8000 0x00000000  /* pioD */
 				      >;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #13 lore raw

PATCH 13/95 ARM: dts: exynos: Fix IOMMU support for GScaler devices on Exynos5250

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

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

From: Marek Szyprowski <[email protected]>

commit 6f4870753f29edf7dc39444246f9e39987b8b158 upstream.

The proper name for the property, which assign given device to IOMMU is 'iommus', not 'iommu'. Fix incorrect name and let all GScaler devices to be properly handled when IOMMU support is enabled.

Reported-by Andrzej Hajda <[email protected]>

Signed-off-by Marek Szyprowski <[email protected]>

Fixes 6cbfdd73a94f ("ARM: dts: add sysmmu nodes for exynos5250")

Cc <[email protected]> # v4.8+

Signed-off-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/exynos5250.dtsi |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm/boot/dts/exynos5250.dtsi +4 -4

@@ -640,7 +640,7 @@
 			power-domains = <&pd_gsc>;
 			clocks = <&clock CLK_GSCL0>;
 			clock-names = "gscl";
-			iommu = <&sysmmu_gsc0>;
+			iommus = <&sysmmu_gsc0>;
 		};
 
 		gsc_1:  gsc@13e10000 {

@@ -650,7 +650,7 @@
 			power-domains = <&pd_gsc>;
 			clocks = <&clock CLK_GSCL1>;
 			clock-names = "gscl";
-			iommu = <&sysmmu_gsc1>;
+			iommus = <&sysmmu_gsc1>;
 		};
 
 		gsc_2:  gsc@13e20000 {

@@ -660,7 +660,7 @@
 			power-domains = <&pd_gsc>;
 			clocks = <&clock CLK_GSCL2>;
 			clock-names = "gscl";
-			iommu = <&sysmmu_gsc2>;
+			iommus = <&sysmmu_gsc2>;
 		};
 
 		gsc_3:  gsc@13e30000 {

@@ -670,7 +670,7 @@
 			power-domains = <&pd_gsc>;
 			clocks = <&clock CLK_GSCL3>;
 			clock-names = "gscl";
-			iommu = <&sysmmu_gsc3>;
+			iommus = <&sysmmu_gsc3>;
 		};
 
 		hdmi: hdmi@14530000 {

Greg Kroah-Hartman

author maintainer

2018-04-22 14:11 UTC #14 lore raw

PATCH 14/95 ARM: dts: at91: sama5d4: fix pinctrl compatible string

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

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

From: Santiago Esteban <[email protected]>

commit 9a06757dcc8509c162ac00488c8c82fc98e04227 upstream.

The compatible string is incorrect. Add atmel,sama5d3-pinctrl since it's the appropriate compatible string. Remove the atmel,at91rm9200-pinctrl compatible string, this fallback is useless, there are too many changes.

Signed-off-by Santiago Esteban <[email protected]>

Signed-off-by Ludovic Desroches <[email protected]>

Cc [email protected] #v3.18

Signed-off-by Alexandre Belloni <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

arch/arm/boot/dts/sama5d4.dtsi +1 -1

@@ -1362,7 +1362,7 @@
 			pinctrl@fc06a000 {
 				#address-cells = <1>;
 				#size-cells = <1>;
-				compatible = "atmel,at91sam9x5-pinctrl", "atmel,at91rm9200-pinctrl", "simple-bus";
+				compatible = "atmel,sama5d3-pinctrl", "atmel,at91sam9x5-pinctrl", "simple-bus";
 				ranges = <0xfc068000 0xfc068000 0x100
 					  0xfc06a000 0xfc06a000 0x4000>;
 				/* WARNING: revisit as pin spec has changed */

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #15 lore raw

PATCH 15/95 spi: Fix scatterlist elements size in spi_map_buf

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

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

From: Maxime Chevallier <[email protected]>

commit ce99319a182fe766be67f96338386f3ec73e321c upstream.

When SPI transfers can be offloaded using DMA, the SPI core need to build a scatterlist to make sure that the buffer to be transferred is dma-able.

This patch fixes the scatterlist entry size computation in the case where the maximum acceptable scatterlist entry supported by the DMA controller is less than PAGE_SIZE, when the buffer is vmalloced.

For each entry, the actual size is given by the minimum between the desc_len (which is the max buffer size supported by the DMA controller) and the remaining buffer length until we cross a page boundary.

Fixes 65598c13fd66 ("spi: Fix per-page mapping of unaligned vmalloc-ed buffer")

Signed-off-by Maxime Chevallier <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/spi/spi.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

drivers/spi/spi.c +8 -2

@@ -743,8 +743,14 @@ static int spi_map_buf(struct spi_master
 	for (i = 0; i < sgs; i++) {
 
 		if (vmalloced_buf || kmap_buf) {
-			min = min_t(size_t,
-				    len, desc_len - offset_in_page(buf));
+			/*
+			 * Next scatterlist entry size is the minimum between
+			 * the desc_len and the remaining buffer length that
+			 * fits in a page.
+			 */
+			min = min_t(size_t, desc_len,
+				    min_t(size_t, len,
+					  PAGE_SIZE - offset_in_page(buf)));
 			if (vmalloced_buf)
 				vm_page = vmalloc_to_page(buf);
 			else

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #16 lore raw

PATCH 16/95 xen-netfront: Fix hang on device removal

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

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

From: Jason Andryuk <[email protected]>

commit c2d2e6738a209f0f9dffa2dc8e7292fc45360d61 upstream.

A toolstack may delete the vif frontend and backend xenstore entries while xen-netfront is in the removal code path. In that case, the checks for xenbus_read_driver_state would return XenbusStateUnknown, and xennet_remove would hang indefinitely. This hang prevents system shutdown.

xennet_remove must be able to handle XenbusStateUnknown, and netback_changed must also wake up the wake_queue for that state as well.

Fixes 5b5971df3bc2 ("xen-netfront: remove warning when unloading module")

Signed-off-by Jason Andryuk <[email protected]>

Cc Eduardo Otubo <[email protected]>

Reviewed-by Boris Ostrovsky <[email protected]>

Signed-off-by Juergen Gross <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/xen-netfront.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/net/xen-netfront.c +6 -1

@@ -2038,7 +2038,10 @@ static void netback_changed(struct xenbu
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
+		break;
+
 	case XenbusStateUnknown:
+		wake_up_all(&module_unload_q);
 		break;
 
 	case XenbusStateInitWait:

@@ -2169,7 +2172,9 @@ static int xennet_remove(struct xenbus_d
 		xenbus_switch_state(dev, XenbusStateClosing);
 		wait_event(module_unload_q,
 			   xenbus_read_driver_state(dev->otherend) ==
-			   XenbusStateClosing);
+			   XenbusStateClosing ||
+			   xenbus_read_driver_state(dev->otherend) ==
+			   XenbusStateUnknown);
 
 		xenbus_switch_state(dev, XenbusStateClosed);
 		wait_event(module_unload_q,

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #17 lore raw

PATCH 17/95 regmap: Fix reversed bounds check in regmap_raw_write()

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

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

From: Dan Carpenter <[email protected]>

commit f00e71091ab92eba52122332586c6ecaa9cd1a56 upstream.

We're supposed to be checking that "val_len" is not too large but instead we check if it is smaller than the max.

The only function affected would be regmap_i2c_smbus_i2c_write() in drivers/base/regmap/regmap-i2c.c. Strangely that function has its own limit check which returns an error if (count >= I2C_SMBUS_BLOCK_MAX) so it doesn't look like it has ever been able to do anything except return an error.

Fixes c335931ed9d2 ("regmap: Add raw_write/read checks for max_raw_write/read sizes")

Signed-off-by Dan Carpenter <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/base/regmap/regmap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/base/regmap/regmap.c +1 -1

@@ -1736,7 +1736,7 @@ int regmap_raw_write(struct regmap *map,
 		return -EINVAL;
 	if (val_len % map->format.val_bytes)
 		return -EINVAL;
-	if (map->max_raw_write && map->max_raw_write > val_len)
+	if (map->max_raw_write && map->max_raw_write < val_len)
 		return -E2BIG;
 
 	map->lock(map->lock_arg);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #18 lore raw

PATCH 18/95 ACPI / video: Add quirk to force acpi-video backlight on Samsung 670Z5E

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

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

From: Hans de Goede <[email protected]>

commit bbf038618a24d72e2efc19146ef421bb1e1eda1a upstream.

Just like many other Samsung models, the 670Z5E needs to use the acpi-video backlight interface rather then the native one for backlight control to work, add a quirk for this.

Buglink https://bugzilla.redhat.com/show_bug.cgi?id=1557060

Cc All applicable <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/video_detect.c |    9 +++++++++
 1 file changed, 9 insertions(+)

drivers/acpi/video_detect.c +9 -0

@@ -214,6 +214,15 @@ static const struct dmi_system_id video_
 		},
 	},
 	{
+	 /* https://bugzilla.redhat.com/show_bug.cgi?id=1557060 */
+	 .callback = video_detect_force_video,
+	 .ident = "SAMSUNG 670Z5E",
+	 .matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "670Z5E"),
+		},
+	},
+	{
 	 /* https://bugzilla.redhat.com/show_bug.cgi?id=1094948 */
 	 .callback = video_detect_force_video,
 	 .ident = "SAMSUNG 730U3E/740U3E",

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #19 lore raw

PATCH 19/95 ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status()

Link https://bugzilla.kernel.org/show_bug.cgi?id=198557

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

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

From: Mika Westerberg <[email protected]>

commit 13d3047c81505cc0fb9bdae7810676e70523c8bf upstream.

Mike Lothian reported that plugging in a USB-C device does not work properly in his Dell Alienware system. This system has an Intel Alpine Ridge Thunderbolt controller providing USB-C functionality. In these systems the USB controller (xHCI) is hotplugged whenever a device is connected to the port using ACPI-based hotplug.

The ACPI description of the root port in question is as follows:

  Device (RP01)
  {
      Name (_ADR, 0x001C0000)

      Device (PXSX)
      {
          Name (_ADR, 0x02)

          Method (_RMV, 0, NotSerialized)
          {
              // ...
          }
      }

Here _ADR 0x02 means device 0, function 2 on the bus under root port (RP01) but that seems to be incorrect because device 0 is the upstream port of the Alpine Ridge PCIe switch and it has no functions other than 0 (the bridge itself). When we get ACPI Notify() to the root port resulting from connecting a USB-C device, Linux tries to read PCI_VENDOR_ID from device 0, function 2 which of course always returns 0xffffffff because there is no such function and we never find the device.

In Windows this works fine.

Now, since we get ACPI Notify() to the root port and not to the PXSX device we should actually start our scan from there as well and not from the non-existent PXSX device. Fix this by checking presence of the slot itself (function 0) if we fail to do that otherwise.

While there use pci_bus_read_dev_vendor_id() in get_slot_status(), which is the recommended way to read Device and Vendor IDs of devices on PCI buses.

Reported-by Mike Lothian <[email protected]>

Signed-off-by Mika Westerberg <[email protected]>

Signed-off-by Bjorn Helgaas <[email protected]>

Reviewed-by Rafael J. Wysocki <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/pci/hotplug/acpiphp_glue.c |   23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

drivers/pci/hotplug/acpiphp_glue.c +16 -7

@@ -587,6 +587,7 @@ static unsigned int get_slot_status(stru
 {
 	unsigned long long sta = 0;
 	struct acpiphp_func *func;
+	u32 dvid;
 
 	list_for_each_entry(func, &slot->funcs, sibling) {
 		if (func->flags & FUNC_HAS_STA) {

@@ -597,19 +598,27 @@ static unsigned int get_slot_status(stru
 			if (ACPI_SUCCESS(status) && sta)
 				break;
 		} else {
-			u32 dvid;
-
-			pci_bus_read_config_dword(slot->bus,
-						  PCI_DEVFN(slot->device,
-							    func->function),
-						  PCI_VENDOR_ID, &dvid);
-			if (dvid != 0xffffffff) {
+			if (pci_bus_read_dev_vendor_id(slot->bus,
+					PCI_DEVFN(slot->device, func->function),
+					&dvid, 0)) {
 				sta = ACPI_STA_ALL;
 				break;
 			}
 		}
 	}
 
+	if (!sta) {
+		/*
+		 * Check for the slot itself since it may be that the
+		 * ACPI slot is a device below PCIe upstream port so in
+		 * that case it may not even be reachable yet.
+		 */
+		if (pci_bus_read_dev_vendor_id(slot->bus,
+				PCI_DEVFN(slot->device, 0), &dvid, 0)) {
+			sta = ACPI_STA_ALL;
+		}
+	}
+
 	return (unsigned int)sta;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #20 lore raw

PATCH 20/95 USB: gadget: f_midi: fixing a possible double-free in f_midi

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

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

From: Yavuz, Tuba <[email protected]>

commit 7fafcfdf6377b18b2a726ea554d6e593ba44349f upstream.

It looks like there is a possibility of a double-free vulnerability on an error path of the f_midi_set_alt function in the f_midi driver. If the path is feasible then free_ep_req gets called twice:

         req->complete = f_midi_complete;
         err = usb_ep_queue(midi->out_ep, req, GFP_ATOMIC);
            => ...
             usb_gadget_giveback_request
               =>
                 f_midi_complete (CALLBACK)
                   (inside f_midi_complete, for various cases of status)
                   free_ep_req(ep, req); // first kfree
         if (err) {
                 ERROR(midi, "%s: couldn't enqueue request: %d\n",
                             midi->out_ep->name, err);
                 free_ep_req(midi->out_ep, req); // second kfree
                 return err;
         }

The double-free possibility was introduced with commit ad0d1a058eac ("usb: gadget: f_midi: fix leak on failed to enqueue out requests").

Found by MOXCAFE tool.

Signed-off-by Tuba Yavuz <[email protected]>

Fixes ad0d1a058eac ("usb: gadget: f_midi: fix leak on failed to enqueue out requests")

Acked-by Felipe Balbi <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/function/f_midi.c |    3 ++-
 drivers/usb/gadget/u_f.h             |    2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

drivers/usb/gadget/function/f_midi.c +2 -1

@@ -389,7 +389,8 @@ static int f_midi_set_alt(struct usb_fun
 		if (err) {
 			ERROR(midi, "%s: couldn't enqueue request: %d\n",
 				    midi->out_ep->name, err);
-			free_ep_req(midi->out_ep, req);
+			if (req->buf != NULL)
+				free_ep_req(midi->out_ep, req);
 			return err;
 		}
 	}

drivers/usb/gadget/u_f.h +2 -0

@@ -64,7 +64,9 @@ struct usb_request *alloc_ep_req(struct
 /* Frees a usb_request previously allocated by alloc_ep_req() */
 static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
 {
+	WARN_ON(req->buf == NULL);
 	kfree(req->buf);
+	req->buf = NULL;
 	usb_ep_free_request(ep, req);
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #21 lore raw

PATCH 21/95 USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw

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

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

From: Zhengjun Xing <[email protected]>

commit 64627388b50158fd24d6ad88132525b95a5ef573 upstream.

USB3 hubs don't support global suspend.

USB3 specification 10.10, Enhanced SuperSpeed hubs only support selective suspend and resume, they do not support global suspend/resume where the hub downstream facing ports states are not affected.

When system enters hibernation it first enters freeze process where only the root hub enters suspend, usb_port_suspend() is not called for other devices, and suspend status flags are not set for them. Other devices are expected to suspend globally. Some external USB3 hubs will suspend the downstream facing port at global suspend. These devices won't be resumed at thaw as the suspend status flag is not set.

A USB3 removable hard disk connected through a USB3 hub that won't resume at thaw will fail to synchronize SCSI cache, return “cmd cmplt err -71” error, and needs a 60 seconds timeout which causing system hang for 60s before the USB host reset the port for the USB3 removable hard disk to recover.

Fix this by always calling usb_port_suspend() during freeze for USB3 devices.

Signed-off-by Zhengjun Xing <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/generic.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

drivers/usb/core/generic.c +7 -2

@@ -208,8 +208,13 @@ static int generic_suspend(struct usb_de
 	if (!udev->parent)
 		rc = hcd_bus_suspend(udev, msg);
 
-	/* Non-root devices don't need to do anything for FREEZE or PRETHAW */
-	else if (msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW)
+	/*
+	 * Non-root USB2 devices don't need to do anything for FREEZE
+	 * or PRETHAW. USB3 devices don't support global suspend and
+	 * needs to be selectively suspended.
+	 */
+	else if ((msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW)
+		 && (udev->speed < USB_SPEED_SUPER))
 		rc = 0;
 	else
 		rc = usb_port_suspend(udev, msg);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #22 lore raw

PATCH 22/95 usb: dwc3: pci: Properly cleanup resource

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

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

From: Thinh Nguyen <[email protected]>

commit cabdf83dadfb3d83eec31e0f0638a92dbd716435 upstream.

Platform device is allocated before adding resources. Make sure to properly cleanup on error case.

Fixes f1c7e7108109 ("usb: dwc3: convert to pcim_enable_device()")

Signed-off-by Thinh Nguyen <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

drivers/usb/dwc3/dwc3-pci.c +1 -1

@@ -173,7 +173,7 @@ static int dwc3_pci_probe(struct pci_dev
 	ret = platform_device_add_resources(dwc3, res, ARRAY_SIZE(res));
 	if (ret) {
 		dev_err(dev, "couldn't add resources to dwc3 device\n");
-		return ret;
+		goto err;
 	}
 
 	dwc3->dev.parent = dev;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #23 lore raw

PATCH 23/95 smb3: Fix root directory when server returns inode number of zero

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

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

From: Steve French <[email protected]>

commit 7ea884c77e5c97f1e0a1a422d961d27f78ca2745 upstream.

Some servers return inode number zero for the root directory, which causes ls to display incorrect data (missing "." and "..").

If the server returns zero for the inode number of the root directory, fake an inode number for it.

Signed-off-by Steve French <[email protected]>

Reviewed-by Pavel Shilovsky <[email protected]>

CC Stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/cifsglob.h |    1 +
 fs/cifs/inode.c    |   33 +++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)

fs/cifs/cifsglob.h +1 -0

@@ -1412,6 +1412,7 @@ struct dfs_info3_param {
 #define CIFS_FATTR_NEED_REVAL		0x4
 #define CIFS_FATTR_INO_COLLISION	0x8
 #define CIFS_FATTR_UNKNOWN_NLINK	0x10
+#define CIFS_FATTR_FAKE_ROOT_INO	0x20
 
 struct cifs_fattr {
 	u32		cf_flags;

fs/cifs/inode.c +33 -0

@@ -701,6 +701,18 @@ cgfi_exit:
 	return rc;
 }
 
+/* Simple function to return a 64 bit hash of string.  Rarely called */
+static __u64 simple_hashstr(const char *str)
+{
+	const __u64 hash_mult =  1125899906842597L; /* a big enough prime */
+	__u64 hash = 0;
+
+	while (*str)
+		hash = (hash + (__u64) *str++) * hash_mult;
+
+	return hash;
+}
+
 int
 cifs_get_inode_info(struct inode **inode, const char *full_path,
 		    FILE_ALL_INFO *data, struct super_block *sb, int xid,

@@ -810,6 +822,14 @@ cifs_get_inode_info(struct inode **inode
 						 tmprc);
 					fattr.cf_uniqueid = iunique(sb, ROOT_I);
 					cifs_autodisable_serverino(cifs_sb);
+				} else if ((fattr.cf_uniqueid == 0) &&
+						strlen(full_path) == 0) {
+					/* some servers ret bad root ino ie 0 */
+					cifs_dbg(FYI, "Invalid (0) inodenum\n");
+					fattr.cf_flags |=
+						CIFS_FATTR_FAKE_ROOT_INO;
+					fattr.cf_uniqueid =
+						simple_hashstr(tcon->treeName);
 				}
 			}
 		} else

@@ -826,6 +846,16 @@ cifs_get_inode_info(struct inode **inode
 				&fattr.cf_uniqueid, data);
 			if (tmprc)
 				fattr.cf_uniqueid = CIFS_I(*inode)->uniqueid;
+			else if ((fattr.cf_uniqueid == 0) &&
+					strlen(full_path) == 0) {
+				/*
+				 * Reuse existing root inode num since
+				 * inum zero for root causes ls of . and .. to
+				 * not be returned
+				 */
+				cifs_dbg(FYI, "Srv ret 0 inode num for root\n");
+				fattr.cf_uniqueid = CIFS_I(*inode)->uniqueid;
+			}
 		} else
 			fattr.cf_uniqueid = CIFS_I(*inode)->uniqueid;
 	}

@@ -887,6 +917,9 @@ cifs_get_inode_info(struct inode **inode
 	}
 
 cgii_exit:
+	if ((*inode) && ((*inode)->i_ino == 0))
+		cifs_dbg(FYI, "inode number of zero returned\n");
+
 	kfree(buf);
 	cifs_put_tlink(tlink);
 	return rc;

Greg Kroah-Hartman

author maintainer

2018-04-22 14:13 UTC #24 lore raw

PATCH 24/95 HID: i2c-hid: fix size check and type usage

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

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

From: Aaron Ma <[email protected]>

commit ac75a041048b8c1f7418e27621ca5efda8571043 upstream.

When convert char array with signed int, if the inbuf[x] is negative then upper bits will be set to 1. Fix this by using u8 instead of char.

ret_size has to be at least 3, hid_input_report use it after minus 2 bytes.

Signed-off-by Aaron Ma <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/i2c-hid/i2c-hid.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

drivers/hid/i2c-hid/i2c-hid.c +7 -6

@@ -142,10 +142,10 @@ struct i2c_hid {
 						   * register of the HID
 						   * descriptor. */
 	unsigned int		bufsize;	/* i2c buffer size */
-	char			*inbuf;		/* Input buffer */
-	char			*rawbuf;	/* Raw Input buffer */
-	char			*cmdbuf;	/* Command buffer */
-	char			*argsbuf;	/* Command arguments buffer */
+	u8			*inbuf;		/* Input buffer */
+	u8			*rawbuf;	/* Raw Input buffer */
+	u8			*cmdbuf;	/* Command buffer */
+	u8			*argsbuf;	/* Command arguments buffer */
 
 	unsigned long		flags;		/* device flags */
 	unsigned long		quirks;		/* Various quirks */

@@ -451,7 +451,8 @@ out_unlock:
 
 static void i2c_hid_get_input(struct i2c_hid *ihid)
 {
-	int ret, ret_size;
+	int ret;
+	u32 ret_size;
 	int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
 
 	if (size > ihid->bufsize)

@@ -476,7 +477,7 @@ static void i2c_hid_get_input(struct i2c
 		return;
 	}
 
-	if (ret_size > size) {
+	if ((ret_size > size) || (ret_size <= 2)) {
 		dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
 			__func__, size, ret_size);
 		return;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #25 lore raw

PATCH 25/95 powerpc/powernv: Handle unknown OPAL errors in opal_nvram_write()

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

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

From: Nicholas Piggin <[email protected]>

commit 741de617661794246f84a21a02fc5e327bffc9ad upstream.

opal_nvram_write currently just assumes success if it encounters an error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO on other errors instead.

Fixes 628daa8d5abf ("powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks")

Cc [email protected] # v3.2+

Signed-off-by Nicholas Piggin <[email protected]>

Reviewed-by Vasant Hegde <[email protected]>

Acked-by Stewart Smith <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/platforms/powernv/opal-nvram.c |    4 ++++
 1 file changed, 4 insertions(+)

arch/powerpc/platforms/powernv/opal-nvram.c +4 -0

@@ -59,6 +59,10 @@ static ssize_t opal_nvram_write(char *bu
 		if (rc == OPAL_BUSY_EVENT)
 			opal_poll_events(NULL);
 	}
+
+	if (rc)
+		return -EIO;
+
 	*index += count;
 	return count;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #26 lore raw

PATCH 26/95 powerpc/64: Fix smp_wmb barrier definition use use lwsync consistently

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

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

From: Nicholas Piggin <[email protected]>

commit 0bfdf598900fd62869659f360d3387ed80eb71cf upstream.

asm/barrier.h is not always included after asm/synch.h, which meant it was missing __SUBARCH_HAS_LWSYNC, so in some files smp_wmb() would be eieio when it should be lwsync. kernel/time/hrtimer.c is one case.

__SUBARCH_HAS_LWSYNC is only used in one place, so just fold it in to where it's used. Previously with my small simulator config, 377 instances of eieio in the tree. After this patch there are 55.

Fixes 46d075be585e ("powerpc: Optimise smp_wmb")

Cc [email protected] # v2.6.29+

Signed-off-by Nicholas Piggin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/barrier.h |    3 ++-
 arch/powerpc/include/asm/synch.h   |    4 ----
 2 files changed, 2 insertions(+), 5 deletions(-)

arch/powerpc/include/asm/barrier.h +2 -1

@@ -34,7 +34,8 @@
 #define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
 #define wmb()  __asm__ __volatile__ ("sync" : : : "memory")
 
-#ifdef __SUBARCH_HAS_LWSYNC
+/* The sub-arch has lwsync */
+#if defined(__powerpc64__) || defined(CONFIG_PPC_E500MC)
 #    define SMPWMB      LWSYNC
 #else
 #    define SMPWMB      eieio

arch/powerpc/include/asm/synch.h +0 -4

@@ -5,10 +5,6 @@
 #include <linux/stringify.h>
 #include <asm/feature-fixups.h>
 
-#if defined(__powerpc64__) || defined(CONFIG_PPC_E500MC)
-#define __SUBARCH_HAS_LWSYNC
-#endif
-
 #ifndef __ASSEMBLY__
 extern unsigned int __start___lwsync_fixup, __stop___lwsync_fixup;
 extern void do_lwsync_fixups(unsigned long value, void *fixup_start,

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #27 lore raw

PATCH 27/95 powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops

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

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

From: Nicholas Piggin <[email protected]>

commit 3b8070335f751aac9f1526ae2e012e6f5b8b0f21 upstream.

The OPAL NVRAM driver does not sleep in case it gets OPAL_BUSY or OPAL_BUSY_EVENT from firmware, which causes large scheduling latencies, and various lockup errors to trigger (again, BMC reboot can cause it).

Fix this by converting it to the standard form OPAL_BUSY loop that sleeps.

Fixes 628daa8d5abf ("powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks")

Depends-on: 34dd25de9fe3 ("powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops")

Cc [email protected] # v3.2+

Signed-off-by Nicholas Piggin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/platforms/powernv/opal-nvram.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/powerpc/platforms/powernv/opal-nvram.c +6 -1

@@ -11,6 +11,7 @@
 
 #define DEBUG
 
+#include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/of.h>

@@ -56,8 +57,12 @@ static ssize_t opal_nvram_write(char *bu
 
 	while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
 		rc = opal_write_nvram(__pa(buf), count, off);
-		if (rc == OPAL_BUSY_EVENT)
+		if (rc == OPAL_BUSY_EVENT) {
+			msleep(OPAL_BUSY_DELAY_MS);
 			opal_poll_events(NULL);
+		} else if (rc == OPAL_BUSY) {
+			msleep(OPAL_BUSY_DELAY_MS);
+		}
 	}
 
 	if (rc)

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #28 lore raw

PATCH 28/95 HID: Fix hid_report_len usage

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

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

From: Aaron Ma <[email protected]>

commit 3064a03b94e60388f0955fcc29f3e8a978d28f75 upstream.

Follow the change of return type u32 of hid_report_len, fix all the types of variables those get the return value of hid_report_len to u32, and all other code already uses u32.

Signed-off-by Aaron Ma <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-input.c      |    3 ++-
 drivers/hid/hid-multitouch.c |    5 +++--
 drivers/hid/hid-rmi.c        |    4 ++--
 drivers/hid/wacom_sys.c      |    2 +-
 4 files changed, 8 insertions(+), 6 deletions(-)

drivers/hid/hid-input.c +2 -1

@@ -1279,7 +1279,8 @@ static void hidinput_led_worker(struct w
 					      led_work);
 	struct hid_field *field;
 	struct hid_report *report;
-	int len, ret;
+	int ret;
+	u32 len;
 	__u8 *buf;
 
 	field = hidinput_get_led_field(hid);

drivers/hid/hid-multitouch.c +3 -2

@@ -315,7 +315,8 @@ static struct attribute_group mt_attribu
 static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
 {
 	struct mt_device *td = hid_get_drvdata(hdev);
-	int ret, size = hid_report_len(report);
+	int ret;
+	u32 size = hid_report_len(report);
 	u8 *buf;
 
 	/*

@@ -919,7 +920,7 @@ static void mt_set_input_mode(struct hid
 	struct hid_report_enum *re;
 	struct mt_class *cls = &td->mtclass;
 	char *buf;
-	int report_len;
+	u32 report_len;
 
 	if (td->inputmode < 0)
 		return;

drivers/hid/hid-rmi.c +2 -2

@@ -110,8 +110,8 @@ struct rmi_data {
 	u8 *writeReport;
 	u8 *readReport;
 
-	int input_report_size;
-	int output_report_size;
+	u32 input_report_size;
+	u32 output_report_size;
 
 	unsigned long flags;

drivers/hid/wacom_sys.c +1 -1

@@ -351,7 +351,7 @@ static int wacom_set_device_mode(struct
 	u8 *rep_data;
 	struct hid_report *r;
 	struct hid_report_enum *re;
-	int length;
+	u32 length;
 	int error = -ENOMEM, limit = 0;
 
 	if (wacom_wac->mode_report < 0)

Greg Kroah-Hartman

author maintainer

2018-04-22 14:13 UTC #29 lore raw

PATCH 29/95 HID: core: Fix size as type u32

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

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

From: Aaron Ma <[email protected]>

commit 6de0b13cc0b4ba10e98a9263d7a83b940720b77a upstream.

When size is negative, calling memset will make segment fault. Declare the size as type u32 to keep memset safe.

size in struct hid_report is unsigned, fix return type of hid_report_len to u32.

Signed-off-by Aaron Ma <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-core.c |   10 +++++-----
 include/linux/hid.h    |    6 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

drivers/hid/hid-core.c +5 -5

@@ -1370,7 +1370,7 @@ u8 *hid_alloc_report_buf(struct hid_repo
 	 * of implement() working on 8 byte chunks
 	 */
 
-	int len = hid_report_len(report) + 7;
+	u32 len = hid_report_len(report) + 7;
 
 	return kmalloc(len, flags);
 }

@@ -1435,7 +1435,7 @@ void __hid_request(struct hid_device *hi
 {
 	char *buf;
 	int ret;
-	int len;
+	u32 len;
 
 	buf = hid_alloc_report_buf(report, GFP_KERNEL);
 	if (!buf)

@@ -1461,14 +1461,14 @@ out:
 }
 EXPORT_SYMBOL_GPL(__hid_request);
 
-int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
+int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
 		int interrupt)
 {
 	struct hid_report_enum *report_enum = hid->report_enum + type;
 	struct hid_report *report;
 	struct hid_driver *hdrv;
 	unsigned int a;
-	int rsize, csize = size;
+	u32 rsize, csize = size;
 	u8 *cdata = data;
 	int ret = 0;

@@ -1526,7 +1526,7 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
  *
  * This is data entry for lower layers.
  */
-int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, int interrupt)
+int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, int interrupt)
 {
 	struct hid_report_enum *report_enum;
 	struct hid_driver *hdrv;

include/linux/hid.h +3 -3

@@ -801,7 +801,7 @@ extern int hidinput_connect(struct hid_d
 extern void hidinput_disconnect(struct hid_device *);
 
 int hid_set_field(struct hid_field *, unsigned, __s32);
-int hid_input_report(struct hid_device *, int type, u8 *, int, int);
+int hid_input_report(struct hid_device *, int type, u8 *, u32, int);
 int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned int code, struct hid_field **field);
 struct hid_field *hidinput_get_led_field(struct hid_device *hid);
 unsigned int hidinput_count_leds(struct hid_device *hid);

@@ -1106,13 +1106,13 @@ static inline void hid_hw_wait(struct hi
  *
  * @report: the report we want to know the length
  */
-static inline int hid_report_len(struct hid_report *report)
+static inline u32 hid_report_len(struct hid_report *report)
 {
 	/* equivalent to DIV_ROUND_UP(report->size, 8) + !!(report->id > 0) */
 	return ((report->size - 1) >> 3) + 1 + (report->id > 0);
 }
 
-int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
+int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
 		int interrupt);
 
 /* HID quirks API */

Greg Kroah-Hartman

author maintainer

2018-04-22 13:52 UTC #30 lore raw

PATCH 30/95 ASoC: ssm2602: Replace reg_default_raw with reg_default

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

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

From: James Kelly <[email protected]>

commit a01df75ce737951ad13a08d101306e88c3f57cb2 upstream.

SSM2602 driver is broken on recent kernels (at least since 4.9). User space applications such as amixer or alsamixer get EIO when attempting to access codec controls via the relevant IOCTLs.

Root cause of these failures is the regcache_hw_init function in drivers/base/regmap/regcache.c, which prevents regmap cache initalization from the reg_defaults_raw element of the regmap_config structure when registers are write only. It also disables the regmap cache entirely when all registers are write only or volatile as is the case for the SSM2602 driver.

Using the reg_defaults element of the regmap_config structure rather than the reg_defaults_raw element to initalize the regmap cache avoids the logic in the regcache_hw_init function entirely. It also makes this driver consistent with other ASoC codec drivers, as this driver was the ONLY codec driver that used the reg_defaults_raw element to initalize the cache.

Tested on Digilent Zybo Z7 development board which has a SSM2603 codec chip connected to a Xilinx Zynq SoC.

Signed-off-by James Kelly <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/codecs/ssm2602.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

sound/soc/codecs/ssm2602.c +13 -6

@@ -54,10 +54,17 @@ struct ssm2602_priv {
  * using 2 wire for device control, so we cache them instead.
  * There is no point in caching the reset register
  */
-static const u16 ssm2602_reg[SSM2602_CACHEREGNUM] = {
-	0x0097, 0x0097, 0x0079, 0x0079,
-	0x000a, 0x0008, 0x009f, 0x000a,
-	0x0000, 0x0000
+static const struct reg_default ssm2602_reg[SSM2602_CACHEREGNUM] = {
+	{ .reg = 0x00, .def = 0x0097 },
+	{ .reg = 0x01, .def = 0x0097 },
+	{ .reg = 0x02, .def = 0x0079 },
+	{ .reg = 0x03, .def = 0x0079 },
+	{ .reg = 0x04, .def = 0x000a },
+	{ .reg = 0x05, .def = 0x0008 },
+	{ .reg = 0x06, .def = 0x009f },
+	{ .reg = 0x07, .def = 0x000a },
+	{ .reg = 0x08, .def = 0x0000 },
+	{ .reg = 0x09, .def = 0x0000 }
 };

@@ -620,8 +627,8 @@ const struct regmap_config ssm2602_regma
 	.volatile_reg = ssm2602_register_volatile,
 
 	.cache_type = REGCACHE_RBTREE,
-	.reg_defaults_raw = ssm2602_reg,
-	.num_reg_defaults_raw = ARRAY_SIZE(ssm2602_reg),
+	.reg_defaults = ssm2602_reg,
+	.num_reg_defaults = ARRAY_SIZE(ssm2602_reg),
 };
 EXPORT_SYMBOL_GPL(ssm2602_regmap_config);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #31 lore raw

PATCH 31/95 thunderbolt: Resume control channel after hibernation image is created

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

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

From: Mika Westerberg <[email protected]>

commit f2a659f7d8d5da803836583aa16df06bdf324252 upstream.

The driver misses implementation of PM hook that undoes what ->freeze_noirq() does after the hibernation image is created. This means the control channel is not resumed properly and the Thunderbolt bus becomes useless in later stages of hibernation (when the image is stored or if the operation fails).

Fix this by pointing ->thaw_noirq to driver nhi_resume_noirq(). This makes sure the control channel is resumed properly.

Fixes 23dd5bb49d98 ("thunderbolt: Add suspend/hibernate support")

Signed-off-by Mika Westerberg <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thunderbolt/nhi.c |    1 +
 1 file changed, 1 insertion(+)

drivers/thunderbolt/nhi.c +1 -0

@@ -628,6 +628,7 @@ static const struct dev_pm_ops nhi_pm_op
 					    * we just disable hotplug, the
 					    * pci-tunnels stay alive.
 					    */
+	.thaw_noirq = nhi_resume_noirq,
 	.restore_noirq = nhi_resume_noirq,
 };

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #32 lore raw

PATCH 32/95 irqchip/gic: Take lock when updating irq type

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

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

From: Aniruddha Banerjee <[email protected]>

commit aa08192a254d362a4d5317647a81de6996961aef upstream.

Most MMIO GIC register accesses use a 1-hot bit scheme that avoids requiring any form of locking. This isn't true for the GICD_ICFGRn registers, which require a RMW sequence.

Unfortunately, we seem to be missing a lock for these particular accesses, which could result in a race condition if changing the trigger type on any two interrupts within the same set of 16 interrupts (and thus controlled by the same CFGR register).

Introduce a private lock in the GIC common comde for this particular case, making it cover both GIC implementations in one go.

Signed-off-by Aniruddha Banerjee <[email protected]>

[maz: updated changelog]

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/irqchip/irq-gic-common.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/irqchip/irq-gic-common.c +8 -1

@@ -21,6 +21,8 @@
 
 #include "irq-gic-common.h"
 
+static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+
 static const struct gic_kvm_info *gic_kvm_info;
 
 const struct gic_kvm_info *gic_get_kvm_info(void)

@@ -52,11 +54,13 @@ int gic_configure_irq(unsigned int irq,
 	u32 confoff = (irq / 16) * 4;
 	u32 val, oldval;
 	int ret = 0;
+	unsigned long flags;
 
 	/*
 	 * Read current configuration register, and insert the config
 	 * for "irq", depending on "type".
 	 */
+	raw_spin_lock_irqsave(&irq_controller_lock, flags);
 	val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
 	if (type & IRQ_TYPE_LEVEL_MASK)
 		val &= ~confmask;

@@ -64,8 +68,10 @@ int gic_configure_irq(unsigned int irq,
 		val |= confmask;
 
 	/* If the current configuration is the same, then we are done */
-	if (val == oldval)
+	if (val == oldval) {
+		raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
 		return 0;
+	}
 
 	/*
 	 * Write back the new configuration, and possibly re-enable

@@ -83,6 +89,7 @@ int gic_configure_irq(unsigned int irq,
 			pr_warn("GIC: PPI%d is secure or misconfigured\n",
 				irq - 16);
 	}
+	raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
 
 	if (sync_access)
 		sync_access();

Greg Kroah-Hartman

author maintainer

2018-04-22 14:12 UTC #33 lore raw

PATCH 33/95 random: use a tighter cap in credit_entropy_bits_safe()

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

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

From: Theodore Ts'o <[email protected]>

commit 9f886f4d1d292442b2f22a0a33321eae821bde40 upstream.

This fixes a harmless UBSAN where root could potentially end up causing an overflow while bumping the entropy_total field (which is ignored once the entropy pool has been initialized, and this generally is completed during the boot sequence).

This is marginal for the stable kernel series, but it's a really trivial patch, and it fixes UBSAN warning that might cause security folks to get overly excited for no reason.

Reported-by Chen Feng <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/char/random.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/char/random.c +1 -1

@@ -741,7 +741,7 @@ retry:
 
 static int credit_entropy_bits_safe(struct entropy_store *r, int nbits)
 {
-	const int nbits_max = (int)(~0U >> (ENTROPY_SHIFT + 1));
+	const int nbits_max = r->poolinfo->poolwords * 32;
 
 	if (nbits < 0)
 		return -EINVAL;

Greg Kroah-Hartman

author maintainer

2018-04-22 14:12 UTC #34 lore raw

PATCH 34/95 jbd2: if the journal is aborted then dont allow update of the log tail

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

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

From: Theodore Ts'o <[email protected]>

commit 85e0c4e89c1b864e763c4e3bb15d0b6d501ad5d9 upstream.

This updates the jbd2 superblock unnecessarily, and on an abort we shouldn't truncate the log.

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/jbd2/journal.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

fs/jbd2/journal.c +4 -1

@@ -951,7 +951,7 @@ out:
 }
 
 /*
- * This is a variaon of __jbd2_update_log_tail which checks for validity of
+ * This is a variation of __jbd2_update_log_tail which checks for validity of
  * provided log tail and locks j_checkpoint_mutex. So it is safe against races
  * with other threads updating log tail.
  */

@@ -1394,6 +1394,9 @@ int jbd2_journal_update_sb_log_tail(jour
 	journal_superblock_t *sb = journal->j_superblock;
 	int ret;
 
+	if (is_journal_aborted(journal))
+		return -EIO;
+
 	BUG_ON(!mutex_is_locked(&journal->j_checkpoint_mutex));
 	jbd_debug(1, "JBD2: updating superblock (start %lu, seq %u)\n",
 		  tail_block, tail_tid);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #35 lore raw

PATCH 35/95 ext4: dont update checksum of new initialized bitmaps

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

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

From: Theodore Ts'o <[email protected]>

commit 044e6e3d74a3d7103a0c8a9305dfd94d64000660 upstream.

When reading the inode or block allocation bitmap, if the bitmap needs to be initialized, do not update the checksum in the block group descriptor. That's because we're not set up to journal those changes. Instead, just set the verified bit on the bitmap block, so that it's not necessary to validate the checksum.

When a block or inode allocation actually happens, at that point the checksum will be calculated, and update of the bg descriptor block will be properly journalled.

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/balloc.c |    3 +--
 fs/ext4/ialloc.c |   47 +++--------------------------------------------
 2 files changed, 4 insertions(+), 46 deletions(-)

fs/ext4/balloc.c +1 -2

@@ -242,8 +242,6 @@ static int ext4_init_block_bitmap(struct
 	 */
 	ext4_mark_bitmap_end(num_clusters_in_group(sb, block_group),
 			     sb->s_blocksize * 8, bh->b_data);
-	ext4_block_bitmap_csum_set(sb, block_group, gdp, bh);
-	ext4_group_desc_csum_set(sb, block_group, gdp);
 	return 0;
 }

@@ -447,6 +445,7 @@ ext4_read_block_bitmap_nowait(struct sup
 		err = ext4_init_block_bitmap(sb, bh, block_group, desc);
 		set_bitmap_uptodate(bh);
 		set_buffer_uptodate(bh);
+		set_buffer_verified(bh);
 		ext4_unlock_group(sb, block_group);
 		unlock_buffer(bh);
 		if (err) {

fs/ext4/ialloc.c +3 ~~-44~~

64 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #36 lore raw

PATCH 36/95 ext4: protect i_disksize update by i_data_sem in direct write path

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

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

From: Eryu Guan <[email protected]>

commit 73fdad00b208b139cf43f3163fbc0f67e4c6047c upstream.

i_disksize update should be protected by i_data_sem, by either taking the lock explicitly or by using ext4_update_i_disksize() helper. But the i_disksize updates in ext4_direct_IO_write() are not protected at all, which may be racing with i_disksize updates in writeback path in delalloc buffer write path.

This is found by code inspection, and I didn't hit any i_disksize corruption due to this bug. Thanks to Jan Kara for catching this bug and suggesting the fix!

Reported-by Jan Kara <[email protected]>

Suggested-by Jan Kara <[email protected]>

Signed-off-by Eryu Guan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

fs/ext4/inode.c +2 -3

@@ -3396,7 +3396,6 @@ static ssize_t ext4_direct_IO_write(stru
 {
 	struct file *file = iocb->ki_filp;
 	struct inode *inode = file->f_mapping->host;
-	struct ext4_inode_info *ei = EXT4_I(inode);
 	ssize_t ret;
 	loff_t offset = iocb->ki_pos;
 	size_t count = iov_iter_count(iter);

@@ -3420,7 +3419,7 @@ static ssize_t ext4_direct_IO_write(stru
 			goto out;
 		}
 		orphan = 1;
-		ei->i_disksize = inode->i_size;
+		ext4_update_i_disksize(inode, inode->i_size);
 		ext4_journal_stop(handle);
 	}

@@ -3548,7 +3547,7 @@ static ssize_t ext4_direct_IO_write(stru
 		if (ret > 0) {
 			loff_t end = offset + ret;
 			if (end > inode->i_size) {
-				ei->i_disksize = end;
+				ext4_update_i_disksize(inode, end);
 				i_size_write(inode, end);
 				/*
 				 * We're going to return a positive `ret'

Greg Kroah-Hartman

author maintainer

2018-04-22 14:12 UTC #37 lore raw

PATCH 37/95 ext4: add validity checks for bitmap block numbers

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

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

From: Theodore Ts'o <[email protected]>

commit 7dac4a1726a9c64a517d595c40e95e2d0d135f6f upstream.

An privileged attacker can cause a crash by mounting a crafted ext4 image which triggers a out-of-bounds read in the function ext4_valid_block_bitmap() in fs/ext4/balloc.c.

This issue has been assigned CVE-2018-1093.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=199181

BugLink https://bugzilla.redhat.com/show_bug.cgi?id=1560782

Reported-by Wen Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/balloc.c |   16 ++++++++++++++--
 fs/ext4/ialloc.c |    7 +++++++
 2 files changed, 21 insertions(+), 2 deletions(-)

fs/ext4/balloc.c +14 -2

@@ -337,20 +337,25 @@ static ext4_fsblk_t ext4_valid_block_bit
 	/* check whether block bitmap block number is set */
 	blk = ext4_block_bitmap(sb, desc);
 	offset = blk - group_first_block;
-	if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
 		/* bad block bitmap */
 		return blk;
 
 	/* check whether the inode bitmap block number is set */
 	blk = ext4_inode_bitmap(sb, desc);
 	offset = blk - group_first_block;
-	if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
 		/* bad block bitmap */
 		return blk;
 
 	/* check whether the inode table block number is set */
 	blk = ext4_inode_table(sb, desc);
 	offset = blk - group_first_block;
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    EXT4_B2C(sbi, offset + sbi->s_itb_per_group) >= sb->s_blocksize)
+		return blk;
 	next_zero_bit = ext4_find_next_zero_bit(bh->b_data,
 			EXT4_B2C(sbi, offset + EXT4_SB(sb)->s_itb_per_group),
 			EXT4_B2C(sbi, offset));

@@ -416,6 +421,7 @@ struct buffer_head *
 ext4_read_block_bitmap_nowait(struct super_block *sb, ext4_group_t block_group)
 {
 	struct ext4_group_desc *desc;
+	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	struct buffer_head *bh;
 	ext4_fsblk_t bitmap_blk;
 	int err;

@@ -424,6 +430,12 @@ ext4_read_block_bitmap_nowait(struct sup
 	if (!desc)
 		return ERR_PTR(-EFSCORRUPTED);
 	bitmap_blk = ext4_block_bitmap(sb, desc);
+	if ((bitmap_blk <= le32_to_cpu(sbi->s_es->s_first_data_block)) ||
+	    (bitmap_blk >= ext4_blocks_count(sbi->s_es))) {
+		ext4_error(sb, "Invalid block bitmap block %llu in "
+			   "block_group %u", bitmap_blk, block_group);
+		return ERR_PTR(-EFSCORRUPTED);
+	}
 	bh = sb_getblk(sb, bitmap_blk);
 	if (unlikely(!bh)) {
 		ext4_error(sb, "Cannot get buffer for block bitmap - "

fs/ext4/ialloc.c +7 -0

@@ -119,6 +119,7 @@ static struct buffer_head *
 ext4_read_inode_bitmap(struct super_block *sb, ext4_group_t block_group)
 {
 	struct ext4_group_desc *desc;
+	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	struct buffer_head *bh = NULL;
 	ext4_fsblk_t bitmap_blk;
 	int err;

@@ -128,6 +129,12 @@ ext4_read_inode_bitmap(struct super_bloc
 		return ERR_PTR(-EFSCORRUPTED);
 
 	bitmap_blk = ext4_inode_bitmap(sb, desc);
+	if ((bitmap_blk <= le32_to_cpu(sbi->s_es->s_first_data_block)) ||
+	    (bitmap_blk >= ext4_blocks_count(sbi->s_es))) {
+		ext4_error(sb, "Invalid inode bitmap blk %llu in "
+			   "block_group %u", bitmap_blk, block_group);
+		return ERR_PTR(-EFSCORRUPTED);
+	}
 	bh = sb_getblk(sb, bitmap_blk);
 	if (unlikely(!bh)) {
 		ext4_error(sb, "Cannot read inode bitmap - "

Ben Hutchings

2018-04-22 21:54 UTC #38 lore raw

Re: [PATCH 4.9 37/95] ext4: add validity checks for bitmap block numbers

Quoted 29 lines · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 7dac4a1726a9c64a517d595c40e95e2d0d135f6f upstream.
An privileged attacker can cause a crash by mounting a crafted ext4 image which triggers a out-of-bounds read in the function ext4_valid_block_bitmap() in fs/ext4/balloc.c.
This issue has been assigned CVE-2018-1093.
BugLink https://bugzilla.kernel.org/show_bug.cgi?id=199181
BugLink https://bugzilla.redhat.com/show_bug.cgi?id=1560782
Reported-by Wen Xu <[email protected]>
Signed-off-by Theodore Ts'o <[email protected]>
Cc [email protected]
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 fs/ext4/balloc.c |   16 ++++++++++++++--
 fs/ext4/ialloc.c |    7 +++++++
 2 files changed, 21 insertions(+), 2 deletions(-)

fs/ext4/balloc.c static ext4_fsblk_t ext4_valid_block_bit · line 341

Quoted 6 lines

fs/ext4/balloc.c +2 -1

@@ -337,20 +337,25 @@ static ext4_fsblk_t ext4_valid_block_bit
 	/* check whether block bitmap block number is set */
 	blk = ext4_block_bitmap(sb, desc);
 	offset = blk - group_first_block;
-	if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))

Isn't sb->s_blocksize a count of bytes? If so, doesn't that mean that we should be comparing with sb->s_blocksize * 8?

Ben.

Quoted 67 lines

fs/ext4/balloc.c +12 -1

 		/* bad block bitmap */
 		return blk;
 
 	/* check whether the inode bitmap block number is set */
 	blk = ext4_inode_bitmap(sb, desc);
 	offset = blk - group_first_block;
-	if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
 		/* bad block bitmap */
 		return blk;
 
 	/* check whether the inode table block number is set */
 	blk = ext4_inode_table(sb, desc);
 	offset = blk - group_first_block;
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    EXT4_B2C(sbi, offset + sbi->s_itb_per_group) >= sb->s_blocksize)
+		return blk;
 	next_zero_bit = ext4_find_next_zero_bit(bh->b_data,
 			EXT4_B2C(sbi, offset + EXT4_SB(sb)->s_itb_per_group),
 			EXT4_B2C(sbi, offset));

@@ -416,6 +421,7 @@ struct buffer_head *
 ext4_read_block_bitmap_nowait(struct super_block *sb, ext4_group_t block_group)
 {
 	struct ext4_group_desc *desc;
+	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	struct buffer_head *bh;
 	ext4_fsblk_t bitmap_blk;
 	int err;

@@ -424,6 +430,12 @@ ext4_read_block_bitmap_nowait(struct sup
 	if (!desc)
 		return ERR_PTR(-EFSCORRUPTED);
 	bitmap_blk = ext4_block_bitmap(sb, desc);
+	if ((bitmap_blk <= le32_to_cpu(sbi->s_es->s_first_data_block)) ||
+	    (bitmap_blk >= ext4_blocks_count(sbi->s_es))) {
+		ext4_error(sb, "Invalid block bitmap block %llu in "
+			   "block_group %u", bitmap_blk, block_group);
+		return ERR_PTR(-EFSCORRUPTED);
+	}
 	bh = sb_getblk(sb, bitmap_blk);
 	if (unlikely(!bh)) {
 		ext4_error(sb, "Cannot get buffer for block bitmap - "

fs/ext4/ialloc.c +7 -0

@@ -119,6 +119,7 @@ static struct buffer_head *
 ext4_read_inode_bitmap(struct super_block *sb, ext4_group_t block_group)
 {
 	struct ext4_group_desc *desc;
+	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	struct buffer_head *bh = NULL;
 	ext4_fsblk_t bitmap_blk;
 	int err;

@@ -128,6 +129,12 @@ ext4_read_inode_bitmap(struct super_bloc
 		return ERR_PTR(-EFSCORRUPTED);
 
 	bitmap_blk = ext4_inode_bitmap(sb, desc);
+	if ((bitmap_blk <= le32_to_cpu(sbi->s_es->s_first_data_block)) ||
+	    (bitmap_blk >= ext4_blocks_count(sbi->s_es))) {
+		ext4_error(sb, "Invalid inode bitmap blk %llu in "
+			   "block_group %u", bitmap_blk, block_group);
+		return ERR_PTR(-EFSCORRUPTED);
+	}
 	bh = sb_getblk(sb, bitmap_blk);
 	if (unlikely(!bh)) {
 		ext4_error(sb, "Cannot read inode bitmap - "

Signature · 3 lines

Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.

Theodore Y. Ts'o

2018-04-23 06:03 UTC #39 lore raw

Re: [PATCH 4.9 37/95] ext4: add validity checks for bitmap block numbers

Quoted 7 lines · Ben Hutchings

fs/ext4/balloc.c static ext4_fsblk_t ext4_valid_block_bit · line 341
Quoted 4 lines
fs/ext4/balloc.c +2 -1
 	offset = blk - group_first_block;
-	if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
Isn't sb->s_blocksize a count of bytes? If so, doesn't that mean that we should be comparing with sb->s_blocksize * 8?

Yes, nice catch, Ben! Can we temporarily drop this patch from the stable queue until I can get a fix in?

In practice this shouldn't be a problem because of the default ext4 layout with flex_bg. But we should definitely get this fixed before we let this flow into the stable kernel.

- Ted

Greg Kroah-Hartman

author maintainer

2018-04-23 07:13 UTC #40 lore raw

Re: [PATCH 4.9 37/95] ext4: add validity checks for bitmap block numbers

Quoted 9 lines · Theodore Y. Ts'o

Quoted 7 lines · Ben Hutchings
fs/ext4/balloc.c static ext4_fsblk_t ext4_valid_block_bit · line 341
Quoted 4 lines
fs/ext4/balloc.c +2 -1
 	offset = blk - group_first_block;
-	if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
+	if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize ||
+	    !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data))
Isn't sb->s_blocksize a count of bytes? If so, doesn't that mean that we should be comparing with sb->s_blocksize * 8?

Quoted 6 lines

Yes, nice catch, Ben! Can we temporarily drop this patch from the stable queue until I can get a fix in?
In practice this shouldn't be a problem because of the default ext4 layout with flex_bg. But we should definitely get this fixed before we let this flow into the stable kernel.

Now dropped from all queues. When you submit the fix, can you also tag it for stable so I know to pick this one back up?

thanks,

greg k-h

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #41 lore raw

PATCH 38/95 ext4: fail ext4_iget for root directory if unallocated

https://bugzilla.kernel.org/show_bug.cgi?id=199179
https://bugzilla.redhat.com/show_bug.cgi?id=1560777

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

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

From: Theodore Ts'o <[email protected]>

commit 8e4b5eae5decd9dfe5a4ee369c22028f90ab4c44 upstream.

If the root directory has an i_links_count of zero, then when the file system is mounted, then when ext4_fill_super() notices the problem and tries to call iput() the root directory in the error return path, ext4_evict_inode() will try to free the inode on disk, before all of the file system structures are set up, and this will result in an OOPS caused by a NULL pointer dereference.

This issue has been assigned CVE-2018-1092.

Reported-by Wen Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/inode.c |    6 ++++++
 1 file changed, 6 insertions(+)

fs/ext4/inode.c +6 -0

@@ -4493,6 +4493,12 @@ struct inode *ext4_iget(struct super_blo
 		goto bad_inode;
 	raw_inode = ext4_raw_inode(&iloc);
 
+	if ((ino == EXT4_ROOT_INO) && (raw_inode->i_links_count == 0)) {
+		EXT4_ERROR_INODE(inode, "root inode unallocated");
+		ret = -EFSCORRUPTED;
+		goto bad_inode;
+	}
+
 	if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
 		ei->i_extra_isize = le16_to_cpu(raw_inode->i_extra_isize);
 		if (EXT4_GOOD_OLD_INODE_SIZE + ei->i_extra_isize >

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #42 lore raw

PATCH 39/95 RDMA/ucma: Dont allow setting RDMA_OPTION_IB_PATH without an RDMA device

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

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

From: Roland Dreier <[email protected]>

commit 8435168d50e66fa5eae01852769d20a36f9e5e83 upstream.

Check to make sure that ctx->cm_id->device is set before we use it. Otherwise userspace can trigger a NULL dereference by doing RDMA_USER_CM_CMD_SET_OPTION on an ID that is not bound to a device.

Reported-by <[email protected]>

Signed-off-by Roland Dreier <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/core/ucma.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/infiniband/core/ucma.c +3 -0

@@ -1231,6 +1231,9 @@ static int ucma_set_ib_path(struct ucma_
 	if (!optlen)
 		return -EINVAL;
 
+	if (!ctx->cm_id->device)
+		return -EINVAL;
+
 	memset(&sa_path, 0, sizeof(sa_path));
 
 	ib_sa_unpack_path(path_data->path_rec, &sa_path);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #43 lore raw

PATCH 40/95 RDMA/rxe: Fix an out-of-bounds read

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

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

From: Bart Van Assche <[email protected]>

commit a6544a624c3ff92a64e4aca3931fa064607bd3da upstream.

This patch avoids that KASAN reports the following when the SRP initiator calls srp_post_send():

==================================================================

BUG: KASAN: stack-out-of-bounds in rxe_post_send+0x5c4/0x980 [rdma_rxe]
Read of size 8 at addr ffff880066606e30 by task 02-mq/1074

CPU: 2 PID: 1074 Comm: 02-mq Not tainted 4.16.0-rc3-dbg+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x85/0xc7
print_address_description+0x65/0x270
kasan_report+0x231/0x350
rxe_post_send+0x5c4/0x980 [rdma_rxe]
srp_post_send.isra.16+0x149/0x190 [ib_srp]
srp_queuecommand+0x94d/0x1670 [ib_srp]
scsi_dispatch_cmd+0x1c2/0x550 [scsi_mod]
scsi_queue_rq+0x843/0xa70 [scsi_mod]
blk_mq_dispatch_rq_list+0x143/0xac0
blk_mq_do_dispatch_ctx+0x1c5/0x260
blk_mq_sched_dispatch_requests+0x2bf/0x2f0
__blk_mq_run_hw_queue+0xdb/0x160
__blk_mq_delay_run_hw_queue+0xba/0x100
blk_mq_run_hw_queue+0xf2/0x190
blk_mq_sched_insert_request+0x163/0x2f0
blk_execute_rq+0xb0/0x130
scsi_execute+0x14e/0x260 [scsi_mod]
scsi_probe_and_add_lun+0x366/0x13d0 [scsi_mod]
__scsi_scan_target+0x18a/0x810 [scsi_mod]
scsi_scan_target+0x11e/0x130 [scsi_mod]
srp_create_target+0x1522/0x19e0 [ib_srp]
kernfs_fop_write+0x180/0x210
__vfs_write+0xb1/0x2e0
vfs_write+0xf6/0x250
SyS_write+0x99/0x110
do_syscall_64+0xee/0x2b0
entry_SYSCALL_64_after_hwframe+0x42/0xb7

The buggy address belongs to the page:
page:ffffea0001998180 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x4000000000000000()
raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff880066606d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1
ffff880066606d80: f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2
>ffff880066606e00: f2 00 00 00 00 00 f2 f2 f2 f3 f3 f3 f3 00 00 00
                                    ^
ffff880066606e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880066606f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

Fixes 8700e3e7c485 ("Soft RoCE driver")

Signed-off-by Bart Van Assche <[email protected]>

Cc Moni Shoua <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/sw/rxe/rxe_verbs.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

drivers/infiniband/sw/rxe/rxe_verbs.c +2 -3

@@ -747,9 +747,8 @@ static int init_send_wqe(struct rxe_qp *
 		memcpy(wqe->dma.sge, ibwr->sg_list,
 		       num_sge * sizeof(struct ib_sge));
 
-	wqe->iova		= (mask & WR_ATOMIC_MASK) ?
-					atomic_wr(ibwr)->remote_addr :
-					rdma_wr(ibwr)->remote_addr;
+	wqe->iova = mask & WR_ATOMIC_MASK ? atomic_wr(ibwr)->remote_addr :
+		mask & WR_READ_OR_WRITE_MASK ? rdma_wr(ibwr)->remote_addr : 0;
 	wqe->mask		= mask;
 	wqe->dma.length		= length;
 	wqe->dma.resid		= length;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #44 lore raw

PATCH 41/95 ALSA: pcm: Fix UAF at PCM release via PCM timer access

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

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

From: Takashi Iwai <[email protected]>

commit a820ccbe21e8ce8e86c39cd1d3bc8c7d1cbb949b upstream.

The PCM runtime object is created and freed dynamically at PCM stream open / close time. This is tracked via substream->runtime, and it's cleared at snd_pcm_detach_substream().

The runtime object assignment is protected by PCM open_mutex, so for all PCM operations, it's safely handled. However, each PCM substream provides also an ALSA timer interface, and user-space can access to this while closing a PCM substream. This may eventually lead to a UAF, as snd_pcm_timer_resolution() tries to access the runtime while clearing it in other side.

Fortunately, it's the only concurrent access from the PCM timer, and it merely reads runtime->timer_resolution field. So, we can avoid the race by reordering kfree() and wrapping the substream->runtime clearance with the corresponding timer lock.

Reported-by [email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/pcm.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

sound/core/pcm.c +7 -1

@@ -28,6 +28,7 @@
 #include <sound/core.h>
 #include <sound/minors.h>
 #include <sound/pcm.h>
+#include <sound/timer.h>
 #include <sound/control.h>
 #include <sound/info.h>

@@ -1025,8 +1026,13 @@ void snd_pcm_detach_substream(struct snd
 	snd_free_pages((void*)runtime->control,
 		       PAGE_ALIGN(sizeof(struct snd_pcm_mmap_control)));
 	kfree(runtime->hw_constraints.rules);
-	kfree(runtime);
+	/* Avoid concurrent access to runtime via PCM timer interface */
+	if (substream->timer)
+		spin_lock_irq(&substream->timer->lock);
 	substream->runtime = NULL;
+	if (substream->timer)
+		spin_unlock_irq(&substream->timer->lock);
+	kfree(runtime);
 	put_pid(substream->pid);
 	substream->pid = NULL;
 	substream->pstr->substream_opened--;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #45 lore raw

PATCH 42/95 IB/srp: Fix srp_abort()

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

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

From: Bart Van Assche <[email protected]>

commit e68088e78d82920632eba112b968e49d588d02a2 upstream.

Before commit e494f6a72839 ("[SCSI] improved eh timeout handler") it did not really matter whether or not abort handlers like srp_abort() called .scsi_done() when returning another value than SUCCESS. Since that commit however this matters. Hence only call .scsi_done() when returning SUCCESS.

Signed-off-by Bart Van Assche <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/ulp/srp/ib_srp.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/infiniband/ulp/srp/ib_srp.c +5 -3

@@ -2626,9 +2626,11 @@ static int srp_abort(struct scsi_cmnd *s
 		ret = FAST_IO_FAIL;
 	else
 		ret = FAILED;
-	srp_free_req(ch, req, scmnd, 0);
-	scmnd->result = DID_ABORT << 16;
-	scmnd->scsi_done(scmnd);
+	if (ret == SUCCESS) {
+		srp_free_req(ch, req, scmnd, 0);
+		scmnd->result = DID_ABORT << 16;
+		scmnd->scsi_done(scmnd);
+	}
 
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #46 lore raw

PATCH 43/95 IB/srp: Fix completion vector assignment algorithm

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

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

From: Bart Van Assche <[email protected]>

commit 3a148896b24adf8688dc0c59af54531931677a40 upstream.

Ensure that cv_end is equal to ibdev->num_comp_vectors for the NUMA node with the highest index. This patch improves spreading of RDMA channels over completion vectors and thereby improves performance, especially on systems with only a single NUMA node. This patch drops support for the comp_vector login parameter by ignoring the value of that parameter since I have not found a good way to combine support for that parameter and automatic spreading of RDMA channels over completion vectors.

Fixes d92c0da71a35 ("IB/srp: Add multichannel support")

Reported-by Alexander Schmid <[email protected]>

Signed-off-by Bart Van Assche <[email protected]>

Cc Alexander Schmid <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/ulp/srp/ib_srp.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

drivers/infiniband/ulp/srp/ib_srp.c +4 -6

@@ -3397,12 +3397,10 @@ static ssize_t srp_create_target(struct
 				      num_online_nodes());
 		const int ch_end = ((node_idx + 1) * target->ch_count /
 				    num_online_nodes());
-		const int cv_start = (node_idx * ibdev->num_comp_vectors /
-				      num_online_nodes() + target->comp_vector)
-				     % ibdev->num_comp_vectors;
-		const int cv_end = ((node_idx + 1) * ibdev->num_comp_vectors /
-				    num_online_nodes() + target->comp_vector)
-				   % ibdev->num_comp_vectors;
+		const int cv_start = node_idx * ibdev->num_comp_vectors /
+				     num_online_nodes();
+		const int cv_end = (node_idx + 1) * ibdev->num_comp_vectors /
+				   num_online_nodes();
 		int cpu_idx = 0;
 
 		for_each_online_cpu(cpu) {

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #47 lore raw

PATCH 44/95 dmaengine: at_xdmac: fix rare residue corruption

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

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

From: Maxime Jayat <[email protected]>

commit c5637476bbf9bb86c7f0413b8f4822a73d8d2d07 upstream.

Despite the efforts made to correctly read the NDA and CUBC registers, the order in which the registers are read could sometimes lead to an inconsistent state.

Re-using the timeline from the comments, this following timing of registers reads could lead to reading NDA with value "@desc2" and CUBC with value "MAX desc1":

INITD -------- ------------

              |____________________|
       _______________________  _______________
 NDA       @desc2             \/   @desc3
       _______________________/\_______________
       __________  ___________  _______________

CUBC 0 \/ MAX desc1 \/ MAX desc2
__________/\___________/\_______________
| | | |
Events:(1)(2) (3)(4)

(1) check_nda = @desc2
(2) initd = 1
(3) cur_ubc = MAX desc1
(4) cur_nda = @desc2

This is allowed by the condition ((check_nda == cur_nda) && initd), despite cur_ubc and cur_nda being in the precise state we don't want.

This error leads to incorrect residue computation.

Fix it by inversing the order in which CUBC and INITD are read. This makes sure that NDA and CUBC are always read together either _before_ INITD goes to 0 or _after_ it is back at 1.
The case where NDA is read before INITD is at 0 and CUBC is read after INITD is back at 1 will be rejected by check_nda and cur_nda being different.

Fixes 53398f488821 ("dmaengine: at_xdmac: fix residue corruption")

Signed-off-by Maxime Jayat <[email protected]>

Acked-by Ludovic Desroches <[email protected]>

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

drivers/dma/at_xdmac.c +2 -2

@@ -1473,10 +1473,10 @@ at_xdmac_tx_status(struct dma_chan *chan
 	for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
 		check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffffffc;
 		rmb();
-		initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & AT_XDMAC_CC_INITD);
-		rmb();
 		cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
 		rmb();
+		initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & AT_XDMAC_CC_INITD);
+		rmb();
 		cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffffffc;
 		rmb();

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #48 lore raw

PATCH 45/95 libnvdimm, namespace: use a safe lookup for dimm device name

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

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

From: Dan Williams <[email protected]>

commit 4f8672201b7e7ed4f5f6c3cf6dcd080648580582 upstream.

The following NULL dereference results from incorrectly assuming that ndd is valid in this print:

  struct nvdimm_drvdata *ndd = to_ndd(&nd_region->mapping[i]);

/*
* Give up if we don't find an instance of a uuid at each
* position (from 0 to nd_region->ndr_mappings - 1), or if we
* find a dimm with two instances of the same uuid. */
dev_err(&nd_region->dev, "%s missing label for %pUb\n",

                  dev_name(ndd->dev), nd_label->uuid);

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
 IP: nd_region_register_namespaces+0xd67/0x13c0 [libnvdimm]
 PGD 0 P4D 0
 Oops: 0000 [#1] SMP PTI
 CPU: 43 PID: 673 Comm: kworker/u609:10 Not tainted 4.16.0-rc4+ #1
 [..]
 RIP: 0010:nd_region_register_namespaces+0xd67/0x13c0 [libnvdimm]
 [..]
 Call Trace:
  ? devres_add+0x2f/0x40
  ? devm_kmalloc+0x52/0x60
  ? nd_region_activate+0x9c/0x320 [libnvdimm]
  nd_region_probe+0x94/0x260 [libnvdimm]
  ? kernfs_add_one+0xe4/0x130
  nvdimm_bus_probe+0x63/0x100 [libnvdimm]

Switch to using the nvdimm device directly.

Fixes 0e3b0d123c8f ("libnvdimm, namespace: allow multiple pmem...")

Reported-by Dave Jiang <[email protected]>

Signed-off-by Dan Williams <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

drivers/nvdimm/namespace_devs.c +2 -2

@@ -1747,7 +1747,7 @@ struct device *create_namespace_pmem(str
 	}
 
 	if (i < nd_region->ndr_mappings) {
-		struct nvdimm_drvdata *ndd = to_ndd(&nd_region->mapping[i]);
+		struct nvdimm *nvdimm = nd_region->mapping[i].nvdimm;
 
 		/*
 		 * Give up if we don't find an instance of a uuid at each

@@ -1755,7 +1755,7 @@ struct device *create_namespace_pmem(str
 		 * find a dimm with two instances of the same uuid.
 		 */
 		dev_err(&nd_region->dev, "%s missing label for %pUb\n",
-				dev_name(ndd->dev), nd_label->uuid);
+				nvdimm_name(nvdimm), nd_label->uuid);
 		rc = -EINVAL;
 		goto err;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #49 lore raw

PATCH 46/95 nfit, address-range-scrub: fix scrub in-progress reporting

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

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

From: Dan Williams <[email protected]>

commit 78727137fdf49edf9f731bde79d7189067b4047a upstream.

There is a small window whereby ARS scan requests can schedule work that userspace will miss when polling scrub_show. Hold the init_mutex lock over calls to report the status to close this potential escape. Also, make sure that requests to cancel the ARS workqueue are treated as an idle event.

Cc Vishal Verma <[email protected]>

Fixes 37b137ff8c83 ("nfit, libnvdimm: allow an ARS scrub...")

Reviewed-by Dave Jiang <[email protected]>

Signed-off-by Dan Williams <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/nfit/core.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/acpi/nfit/core.c +4 -1

@@ -967,8 +967,11 @@ static ssize_t scrub_show(struct device
 	if (nd_desc) {
 		struct acpi_nfit_desc *acpi_desc = to_acpi_desc(nd_desc);
 
+		mutex_lock(&acpi_desc->init_mutex);
 		rc = sprintf(buf, "%d%s", acpi_desc->scrub_count,
-				(work_busy(&acpi_desc->work)) ? "+\n" : "\n");
+				work_busy(&acpi_desc->work)
+				&& !acpi_desc->cancel ? "+\n" : "\n");
+		mutex_unlock(&acpi_desc->init_mutex);
 	}
 	device_unlock(dev);
 	return rc;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #50 lore raw

PATCH 47/95 um: Compile with modern headers

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

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

From: Jason A. Donenfeld <[email protected]>

commit 530ba6c7cb3c22435a4d26de47037bb6f86a5329 upstream.

Recent libcs have gotten a bit more strict, so we actually need to include the right headers and use the right types. This enables UML to compile again.

Signed-off-by Jason A. Donenfeld <[email protected]>

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/um/os-Linux/file.c   |    1 +
 arch/um/os-Linux/signal.c |    1 +
 arch/x86/um/stub_segv.c   |    1 +
 3 files changed, 3 insertions(+)

arch/um/os-Linux/file.c +1 -0

@@ -12,6 +12,7 @@
 #include <sys/mount.h>
 #include <sys/socket.h>
 #include <sys/stat.h>
+#include <sys/sysmacros.h>
 #include <sys/un.h>
 #include <sys/types.h>
 #include <os.h>

arch/um/os-Linux/signal.c +1 -0

@@ -16,6 +16,7 @@
 #include <os.h>
 #include <sysdep/mcontext.h>
 #include <um_malloc.h>
+#include <sys/ucontext.h>
 
 void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
 	[SIGTRAP]	= relay_signal,

arch/x86/um/stub_segv.c +1 -0

@@ -6,6 +6,7 @@
 #include <sysdep/stub.h>
 #include <sysdep/faultinfo.h>
 #include <sysdep/mcontext.h>
+#include <sys/ucontext.h>
 
 void __attribute__ ((__section__ (".__syscall_stub")))
 stub_segv_handler(int sig, siginfo_t *info, void *p)

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #51 lore raw

PATCH 48/95 um: Use POSIX ucontext_t instead of struct ucontext

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

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

From: Krzysztof Mazur <[email protected]>

commit 4d1a535b8ec5e74b42dfd9dc809142653b2597f6 upstream.

glibc 2.26 removed the 'struct ucontext' to "improve" POSIX compliance and break programs, including User Mode Linux. Fix User Mode Linux by using POSIX ucontext_t.

This fixes:

arch/um/os-Linux/signal.c: In function 'hard_handler':
arch/um/os-Linux/signal.c:163:22: error: dereferencing pointer to incomplete type 'struct ucontext'
mcontext_t *mc = &uc->uc_mcontext;
arch/x86/um/stub_segv.c: In function 'stub_segv_handler':
arch/x86/um/stub_segv.c:16:13: error: dereferencing pointer to incomplete type 'struct ucontext'

          &uc->uc_mcontext);

Signed-off-by Krzysztof Mazur <[email protected]>

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/um/os-Linux/signal.c |    2 +-
 arch/x86/um/stub_segv.c   |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/um/os-Linux/signal.c +1 -1

@@ -160,7 +160,7 @@ static void (*handlers[_NSIG])(int sig,
 
 static void hard_handler(int sig, siginfo_t *si, void *p)
 {
-	struct ucontext *uc = p;
+	ucontext_t *uc = p;
 	mcontext_t *mc = &uc->uc_mcontext;
 	unsigned long pending = 1UL << sig;

arch/x86/um/stub_segv.c +1 -1

@@ -11,7 +11,7 @@
 void __attribute__ ((__section__ (".__syscall_stub")))
 stub_segv_handler(int sig, siginfo_t *info, void *p)
 {
-	struct ucontext *uc = p;
+	ucontext_t *uc = p;
 
 	GET_FAULTINFO_FROM_MC(*((struct faultinfo *) STUB_DATA),
 			      &uc->uc_mcontext);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #52 lore raw

PATCH 49/95 iommu/vt-d: Fix a potential memory leak

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

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

From: Lu Baolu <[email protected]>

commit bbe4b3af9d9e3172fb9aa1f8dcdfaedcb381fc64 upstream.

A memory block was allocated in intel_svm_bind_mm() but never freed in a failure path. This patch fixes this by free it to avoid memory leakage.

Cc Ashok Raj <[email protected]>

Cc Jacob Pan <[email protected]>

Cc <[email protected]> # v4.4+

Signed-off-by Lu Baolu <[email protected]>

Fixes 2f26e0a9c9860 ('iommu/vt-d: Add basic SVM PASID support')

Signed-off-by Joerg Roedel <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iommu/intel-svm.c |    1 +
 1 file changed, 1 insertion(+)

drivers/iommu/intel-svm.c +1 -0

@@ -389,6 +389,7 @@ int intel_svm_bind_mm(struct device *dev
 				pasid_max - 1, GFP_KERNEL);
 		if (ret < 0) {
 			kfree(svm);
+			kfree(sdev);
 			goto out;
 		}
 		svm->pasid = ret;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #53 lore raw

PATCH 50/95 mmc: jz4740: Fix race condition in IRQ mask update

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

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

From: Alex Smith <[email protected]>

commit a04f0017c22453613d5f423326b190c61e3b4f98 upstream.

A spinlock is held while updating the internal copy of the IRQ mask, but not while writing it to the actual IMASK register. After the lock is released, an IRQ can occur before the IMASK register is written. If handling this IRQ causes the mask to be changed, when the handler returns back to the middle of the first mask update, a stale value will be written to the mask register.

If this causes an IRQ to become unmasked that cannot have its status cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ, then we can end up stuck with the same IRQ repeatedly being fired but not handled. Normally the MMC IRQ handler attempts to clear any unexpected IRQs by writing IREG, but for those that cannot be cleared in this way then the IRQ will just repeatedly fire.

This was resulting in lockups after a while of using Wi-Fi on the CI20 (GitHub issue #19).

Resolve by holding the spinlock until after the IMASK register has been updated.

Link https://github.com/MIPS/CI20_linux/issues/19

Fixes 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.")

Tested-by Mathieu Malaterre <[email protected]>

Signed-off-by Alex Smith <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/host/jz4740_mmc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mmc/host/jz4740_mmc.c +1 -1

@@ -368,9 +368,9 @@ static void jz4740_mmc_set_irq_enabled(s
 		host->irq_mask &= ~irq;
 	else
 		host->irq_mask |= irq;
-	spin_unlock_irqrestore(&host->lock, flags);
 
 	writew(host->irq_mask, host->base + JZ_REG_MMC_IMASK);
+	spin_unlock_irqrestore(&host->lock, flags);
 }
 
 static void jz4740_mmc_clock_enable(struct jz4740_mmc_host *host,

Greg Kroah-Hartman

author maintainer

2018-04-22 14:13 UTC #54 lore raw

PATCH 51/95 clk: mvebu: armada-38x: add support for 1866MHz variants

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

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

From: Ralph Sennhauser <[email protected]>

commit 9593f4f56cf5d1c443f66660a0c7f01de38f979d upstream.

The Linksys WRT3200ACM CPU is clocked at 1866MHz. Add 1866MHz to the list of supported CPU frequencies. Also update multiplier and divisor for the l2clk and ddrclk.

Noticed by the following warning:

[    0.000000] Selected CPU frequency (16) unsupported

Signed-off-by Ralph Sennhauser <[email protected]>

Reviewed-by Gregory CLEMENT <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/mvebu/armada-38x.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/clk/mvebu/armada-38x.c +4 -3

@@ -49,7 +49,8 @@ static const u32 armada_38x_cpu_frequenc
 	0, 0, 0, 0,
 	1066 * 1000 * 1000, 0, 0, 0,
 	1332 * 1000 * 1000, 0, 0, 0,
-	1600 * 1000 * 1000,
+	1600 * 1000 * 1000, 0, 0, 0,
+	1866 * 1000 * 1000,
 };
 
 static u32 __init armada_38x_get_cpu_freq(void __iomem *sar)

@@ -79,7 +80,7 @@ static const int armada_38x_cpu_l2_ratio
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
-	{0, 1}, {0, 1}, {0, 1}, {0, 1},
+	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},

@@ -90,7 +91,7 @@ static const int armada_38x_cpu_ddr_rati
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
-	{0, 1}, {0, 1}, {0, 1}, {0, 1},
+	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},

Greg Kroah-Hartman

author maintainer

2018-04-22 14:13 UTC #55 lore raw

PATCH 52/95 clk: mvebu: armada-38x: add support for missing clocks

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

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

From: Richard Genoud <[email protected]>

commit 6a4a4595804548e173f0763a0e7274a3521c59a9 upstream.

Clearfog boards can come with a CPU clocked at 1600MHz (commercial) or 1333MHz (industrial).

They have also some dip-switches to select a different clock (666, 800, 1066, 1200).

The funny thing is that the recovery button is on the MPP34 fq selector. So, when booting an industrial board with this button down, the frequency 666MHz is selected (and the kernel didn't boot).

This patch add all the missing clocks.

The only mode I didn't test is 2GHz (uboot found 4294MHz instead :/ ).

Fixes 0e85aeced4d6 ("clk: mvebu: add clock support for Armada 380/385")

Cc <[email protected]> # 3.16.x: 9593f4f56cf5: clk: mvebu: armada-38x: add support for 1866MHz variants

Cc <[email protected]> # 3.16.x

Signed-off-by Richard Genoud <[email protected]>

Acked-by Gregory CLEMENT <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/mvebu/armada-38x.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

drivers/clk/mvebu/armada-38x.c +7 -7

@@ -46,11 +46,11 @@ static u32 __init armada_38x_get_tclk_fr
 }
 
 static const u32 armada_38x_cpu_frequencies[] __initconst = {
-	0, 0, 0, 0,
-	1066 * 1000 * 1000, 0, 0, 0,
+	666 * 1000 * 1000,  0, 800 * 1000 * 1000, 0,
+	1066 * 1000 * 1000, 0, 1200 * 1000 * 1000, 0,
 	1332 * 1000 * 1000, 0, 0, 0,
 	1600 * 1000 * 1000, 0, 0, 0,
-	1866 * 1000 * 1000,
+	1866 * 1000 * 1000, 0, 0, 2000 * 1000 * 1000,
 };
 
 static u32 __init armada_38x_get_cpu_freq(void __iomem *sar)

@@ -76,11 +76,11 @@ static const struct coreclk_ratio armada
 };
 
 static const int armada_38x_cpu_l2_ratios[32][2] __initconst = {
-	{0, 1}, {0, 1}, {0, 1}, {0, 1},
-	{1, 2}, {0, 1}, {0, 1}, {0, 1},
-	{1, 2}, {0, 1}, {0, 1}, {0, 1},
+	{1, 2}, {0, 1}, {1, 2}, {0, 1},
+	{1, 2}, {0, 1}, {1, 2}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
+	{1, 2}, {0, 1}, {0, 1}, {1, 2},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},

@@ -91,7 +91,7 @@ static const int armada_38x_cpu_ddr_rati
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
 	{1, 2}, {0, 1}, {0, 1}, {0, 1},
-	{1, 2}, {0, 1}, {0, 1}, {0, 1},
+	{1, 2}, {0, 1}, {0, 1}, {7, 15},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},
 	{0, 1}, {0, 1}, {0, 1}, {0, 1},

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #56 lore raw

PATCH 53/95 clk: fix false-positive Wmaybe-uninitialized warning

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

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

From: Arnd Bergmann <[email protected]>

commit ce33f284935e08229046b30635e6aadcbab02b53 upstream.

When we build this driver with on x86-32, gcc produces a false-positive warning:

drivers/clk/renesas/clk-sh73a0.c: In function 'sh73a0_cpg_clocks_init':
drivers/clk/renesas/clk-sh73a0.c:155:10: error: 'parent_name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
return clk_register_fixed_factor(NULL, name, parent_name, 0,

We can work around that warning by adding a fake initialization, I tried and failed to come up with any better workaround. This is currently one of few remaining warnings for a 4.14.y randconfig build, so it would be good to also have it backported at least to that version. Older versions have more randconfig warnings, so we might not care.

I had not noticed this earlier, because one patch in my randconfig test tree removes the '-ffreestanding' option on x86-32, and that avoids the warning. The -ffreestanding flag was originally global but moved into arch/i386 by Andi Kleen in commit 6edfba1b33c7 ("[PATCH] x86_64:
Don't define string functions to builtin") as a 'temporary workaround'.

Like many temporary hacks, this turned out to be rather long-lived, from all I can tell we still need a simple fix to asm/string_32.h before it can be removed, but I'm not sure about how to best do that.

Cc Andi Kleen <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

Acked-by Geert Uytterhoeven <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/renesas/clk-sh73a0.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/clk/renesas/clk-sh73a0.c +3 -3

@@ -46,7 +46,7 @@ struct div4_clk {
 	unsigned int shift;
 };
 
-static struct div4_clk div4_clks[] = {
+static const struct div4_clk div4_clks[] = {
 	{ "zg", "pll0", CPG_FRQCRA, 16 },
 	{ "m3", "pll1", CPG_FRQCRA, 12 },
 	{ "b",  "pll1", CPG_FRQCRA,  8 },

@@ -79,7 +79,7 @@ sh73a0_cpg_register_clock(struct device_
 {
 	const struct clk_div_table *table = NULL;
 	unsigned int shift, reg, width;
-	const char *parent_name;
+	const char *parent_name = NULL;
 	unsigned int mult = 1;
 	unsigned int div = 1;

@@ -135,7 +135,7 @@ sh73a0_cpg_register_clock(struct device_
 		shift = 24;
 		width = 5;
 	} else {
-		struct div4_clk *c;
+		const struct div4_clk *c;
 
 		for (c = div4_clks; c->name; c++) {
 			if (!strcmp(name, c->name)) {

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #57 lore raw

PATCH 54/95 clk: bcm2835: De-assert/assert PLL reset signal when appropriate

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

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

From: Boris Brezillon <[email protected]>

commit 753872373b599384ac7df809aa61ea12d1c4d5d1 upstream.

In order to enable a PLL, not only the PLL has to be powered up and locked, but you also have to de-assert the reset signal. The last part was missing. Add it so PLLs that were not enabled by the FW/bootloader can be enabled from Linux.

Fixes 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")

Signed-off-by Boris Brezillon <[email protected]>

Reviewed-by Eric Anholt <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/bcm/clk-bcm2835.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/clk/bcm/clk-bcm2835.c +5 -3

@@ -545,9 +545,7 @@ static void bcm2835_pll_off(struct clk_h
 	const struct bcm2835_pll_data *data = pll->data;
 
 	spin_lock(&cprman->regs_lock);
-	cprman_write(cprman, data->cm_ctrl_reg,
-		     cprman_read(cprman, data->cm_ctrl_reg) |
-		     CM_PLL_ANARST);
+	cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
 	cprman_write(cprman, data->a2w_ctrl_reg,
 		     cprman_read(cprman, data->a2w_ctrl_reg) |
 		     A2W_PLL_CTRL_PWRDN);

@@ -583,6 +581,10 @@ static int bcm2835_pll_on(struct clk_hw
 		cpu_relax();
 	}
 
+	cprman_write(cprman, data->a2w_ctrl_reg,
+		     cprman_read(cprman, data->a2w_ctrl_reg) |
+		     A2W_PLL_CTRL_PRST_DISABLE);
+
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #58 lore raw

PATCH 55/95 pwm: rcar: Fix a condition to prevent mismatch value setting to duty

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

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

From: Ryo Kodama <[email protected]>

commit 6225f9c64b40bc8a22503e9cda70f55d7a9dd3c6 upstream.

This patch fixes an issue that is possible to set mismatch value to duty for R-Car PWM if we input the following commands:

 # cd /sys/class/pwm/<pwmchip>/
 # echo 0 > export
 # cd pwm0
 # echo 30 > period
 # echo 30 > duty_cycle
 # echo 0 > duty_cycle
 # cat duty_cycle
 0
 # echo 1 > enable
 --> Then, the actual duty_cycle is 30, not 0.

So, this patch adds a condition into rcar_pwm_config() to fix this issue.

Signed-off-by Ryo Kodama <[email protected]>

[shimoda: revise the commit log and add Fixes and Cc tags]

Fixes ed6c1476bf7f ("pwm: Add support for R-Car PWM Timer")

Cc Cc: <[email protected]> # v4.4+

Signed-off-by Yoshihiro Shimoda <[email protected]>

Signed-off-by Thierry Reding <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/pwm/pwm-rcar.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/pwm/pwm-rcar.c +6 -2

@@ -156,8 +156,12 @@ static int rcar_pwm_config(struct pwm_ch
 	if (div < 0)
 		return div;
 
-	/* Let the core driver set pwm->period if disabled and duty_ns == 0 */
-	if (!pwm_is_enabled(pwm) && !duty_ns)
+	/*
+	 * Let the core driver set pwm->period if disabled and duty_ns == 0.
+	 * But, this driver should prevent to set the new duty_ns if current
+	 * duty_cycle is not set
+	 */
+	if (!pwm_is_enabled(pwm) && !duty_ns && !pwm->state.duty_cycle)
 		return 0;
 
 	rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #59 lore raw

PATCH 56/95 thermal: imx: Fix race condition in imx_thermal_probe()

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

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

From: Mikhail Lappo <[email protected]>

commit cf1ba1d73a33944d8c1a75370a35434bf146b8a7 upstream.

When device boots with T > T_trip_1 and requests interrupt, the race condition takes place. The interrupt comes before THERMAL_DEVICE_ENABLED is set. This leads to an attempt to reading sensor value from irq and disabling the sensor, based on the data->mode field, which expected to be THERMAL_DEVICE_ENABLED, but still stays as THERMAL_DEVICE_DISABLED. Afher this issue sensor is never re-enabled, as the driver state is wrong.

Fix this problem by setting the 'data' members prior to requesting the interrupts.

Fixes 37713a1e8e4c ("thermal: imx: implement thermal alarm interrupt handling")

Signed-off-by Mikhail Lappo <[email protected]>

Signed-off-by Fabio Estevam <[email protected]>

Reviewed-by Philipp Zabel <[email protected]>

Acked-by Dong Aisheng <[email protected]>

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thermal/imx_thermal.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/thermal/imx_thermal.c +3 -3

@@ -587,6 +587,9 @@ static int imx_thermal_probe(struct plat
 	regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_POWER_DOWN);
 	regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_MEASURE_TEMP);
 
+	data->irq_enabled = true;
+	data->mode = THERMAL_DEVICE_ENABLED;
+
 	ret = devm_request_threaded_irq(&pdev->dev, data->irq,
 			imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
 			0, "imx_thermal", data);

@@ -598,9 +601,6 @@ static int imx_thermal_probe(struct plat
 		return ret;
 	}
 
-	data->irq_enabled = true;
-	data->mode = THERMAL_DEVICE_ENABLED;
-
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #60 lore raw

PATCH 57/95 dt-bindings: clock: mediatek: add binding for fixed-factor clock axisel_d4

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

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

From: Sean Wang <[email protected]>

commit 55a5fcafe3a94e8a0777bb993d09107d362258d2 upstream.

Just add binding for a fixed-factor clock axisel_d4, which would be referenced by PWM devices on MT7623 or MT2701 SoC.

Fixes 1de9b21633d6 ("clk: mediatek: Add dt-bindings for MT2701 clocks")

Signed-off-by Sean Wang <[email protected]>

Reviewed-by Rob Herring <[email protected]>

Cc Mark Rutland <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/dt-bindings/clock/mt2701-clk.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

include/dt-bindings/clock/mt2701-clk.h +2 -1

@@ -176,7 +176,8 @@
 #define CLK_TOP_AUD_EXT1			156
 #define CLK_TOP_AUD_EXT2			157
 #define CLK_TOP_NFI1X_PAD			158
-#define CLK_TOP_NR				159
+#define CLK_TOP_AXISEL_D4			159
+#define CLK_TOP_NR				160
 
 /* APMIXEDSYS */

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #61 lore raw

PATCH 58/95 watchdog: f71808e_wdt: Fix WD_EN register read

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

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

From: Igor Pylypiv <[email protected]>

commit 977f6f68331f94bb72ad84ee96b7b87ce737d89d upstream.

F71808FG_FLAG_WD_EN defines bit position, not a bitmask

Signed-off-by Igor Pylypiv <[email protected]>

Reviewed-by Guenter Roeck <[email protected]>

Signed-off-by Guenter Roeck <[email protected]>

Signed-off-by Wim Van Sebroeck <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/watchdog/f71808e_wdt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/watchdog/f71808e_wdt.c +1 -1

@@ -496,7 +496,7 @@ static bool watchdog_is_running(void)
 
 	is_running = (superio_inb(watchdog.sioaddr, SIO_REG_ENABLE) & BIT(0))
 		&& (superio_inb(watchdog.sioaddr, F71808FG_REG_WDT_CONF)
-			& F71808FG_FLAG_WD_EN);
+			& BIT(F71808FG_FLAG_WD_EN));
 
 	superio_exit(watchdog.sioaddr);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #62 lore raw

PATCH 59/95 vfio/pci: Virtualize Maximum Read Request Size

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

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

From: Alex Williamson <[email protected]>

commit cf0d53ba4947aad6e471491d5b20a567cbe92e56 upstream.

MRRS defines the maximum read request size a device is allowed to make. Drivers will often increase this to allow more data transfer with a single request. Completions to this request are bound by the MPS setting for the bus. Aside from device quirks (none known), it doesn't seem to make sense to set an MRRS value less than MPS, yet this is a likely scenario given that user drivers do not have a system-wide view of the PCI topology. Virtualize MRRS such that the user can set MRRS >= MPS, but use MPS as the floor value that we'll write to hardware.

Signed-off-by Alex Williamson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/vfio/pci/vfio_pci_config.c |   29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

drivers/vfio/pci/vfio_pci_config.c +26 -3

@@ -810,6 +810,7 @@ static int vfio_exp_config_write(struct
 {
 	__le16 *ctrl = (__le16 *)(vdev->vconfig + pos -
 				  offset + PCI_EXP_DEVCTL);
+	int readrq = le16_to_cpu(*ctrl) & PCI_EXP_DEVCTL_READRQ;
 
 	count = vfio_default_config_write(vdev, pos, count, perm, offset, val);
 	if (count < 0)

@@ -835,6 +836,27 @@ static int vfio_exp_config_write(struct
 			pci_try_reset_function(vdev->pdev);
 	}
 
+	/*
+	 * MPS is virtualized to the user, writes do not change the physical
+	 * register since determining a proper MPS value requires a system wide
+	 * device view.  The MRRS is largely independent of MPS, but since the
+	 * user does not have that system-wide view, they might set a safe, but
+	 * inefficiently low value.  Here we allow writes through to hardware,
+	 * but we set the floor to the physical device MPS setting, so that
+	 * we can at least use full TLPs, as defined by the MPS value.
+	 *
+	 * NB, if any devices actually depend on an artificially low MRRS
+	 * setting, this will need to be revisited, perhaps with a quirk
+	 * though pcie_set_readrq().
+	 */
+	if (readrq != (le16_to_cpu(*ctrl) & PCI_EXP_DEVCTL_READRQ)) {
+		readrq = 128 <<
+			((le16_to_cpu(*ctrl) & PCI_EXP_DEVCTL_READRQ) >> 12);
+		readrq = max(readrq, pcie_get_mps(vdev->pdev));
+
+		pcie_set_readrq(vdev->pdev, readrq);
+	}
+
 	return count;
 }

@@ -853,11 +875,12 @@ static int __init init_pci_cap_exp_perm(
 	 * Allow writes to device control fields, except devctl_phantom,
 	 * which could confuse IOMMU, MPS, which can break communication
 	 * with other physical devices, and the ARI bit in devctl2, which
-	 * is set at probe time.  FLR gets virtualized via our writefn.
+	 * is set at probe time.  FLR and MRRS get virtualized via our
+	 * writefn.
 	 */
 	p_setw(perm, PCI_EXP_DEVCTL,
-	       PCI_EXP_DEVCTL_BCR_FLR | PCI_EXP_DEVCTL_PAYLOAD,
-	       ~PCI_EXP_DEVCTL_PHANTOM);
+	       PCI_EXP_DEVCTL_BCR_FLR | PCI_EXP_DEVCTL_PAYLOAD |
+	       PCI_EXP_DEVCTL_READRQ, ~PCI_EXP_DEVCTL_PHANTOM);
 	p_setw(perm, PCI_EXP_DEVCTL2, NO_VIRT, ~PCI_EXP_DEVCTL2_ARI);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #63 lore raw

PATCH 60/95 ALSA: pcm: Use ERESTARTSYS instead of EINTR in OSS emulation

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

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

From: Takashi Iwai <[email protected]>

commit c64ed5dd9feba193c76eb460b451225ac2a0d87b upstream.

Fix the last standing EINTR in the whole subsystem. Use more correct ERESTARTSYS for pending signals.

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

sound/core/oss/pcm_oss.c +1 -1

@@ -853,7 +853,7 @@ static int snd_pcm_oss_change_params(str
 		if (!(mutex_trylock(&runtime->oss.params_lock)))
 			return -EAGAIN;
 	} else if (mutex_lock_interruptible(&runtime->oss.params_lock))
-		return -EINTR;
+		return -ERESTARTSYS;
 	sw_params = kzalloc(sizeof(*sw_params), GFP_KERNEL);
 	params = kmalloc(sizeof(*params), GFP_KERNEL);
 	sparams = kmalloc(sizeof(*sparams), GFP_KERNEL);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #64 lore raw

PATCH 61/95 ALSA: pcm: Avoid potential races between OSS ioctls and read/write

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

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

From: Takashi Iwai <[email protected]>

commit 02a5d6925cd34c3b774bdb8eefb057c40a30e870 upstream.

Although we apply the params_lock mutex to the whole read and write operations as well as snd_pcm_oss_change_params(), we may still face some races.

First off, the params_lock is taken inside the read and write loop. This is intentional for avoiding the too long locking, but it allows the in-between parameter change, which might lead to invalid pointers. We check the readiness of the stream and set up via snd_pcm_oss_make_ready() at the beginning of read and write, but it's called only once, by assuming that it remains ready in the rest.

Second, many ioctls that may change the actual parameters (i.e. setting runtime->oss.params=1) aren't protected, hence they can be processed in a half-baked state.

This patch is an attempt to plug these holes. The stream readiness check is moved inside the read/write inner loop, so that the stream is always set up in a proper state before further processing. Also, each ioctl that may change the parameter is wrapped with the params_lock for avoiding the races.

The issues were triggered by syzkaller in a few different scenarios, particularly the one below appearing as GPF in loopback_pos_update.

Reported-by [email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/oss/pcm_oss.c |  134 +++++++++++++++++++++++++++++++++++++----------
 1 file changed, 106 insertions(+), 28 deletions(-)

sound/core/oss/pcm_oss.c +106 ~~-28~~

@@ -834,8 +834,8 @@ static int choose_rate(struct snd_pcm_su
 	return snd_pcm_hw_param_near(substream, params, SNDRV_PCM_HW_PARAM_RATE, best_rate, NULL);
 }
 
-static int snd_pcm_oss_change_params(struct snd_pcm_substream *substream,
-				     bool trylock)
+/* call with params_lock held */
+static int snd_pcm_oss_change_params_locked(struct snd_pcm_substream *substream)
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct snd_pcm_hw_params *params, *sparams;

@@ -849,11 +849,8 @@ static int snd_pcm_oss_change_params(str
 	struct snd_mask sformat_mask;
 	struct snd_mask mask;
 
-	if (trylock) {
-		if (!(mutex_trylock(&runtime->oss.params_lock)))
-			return -EAGAIN;
-	} else if (mutex_lock_interruptible(&runtime->oss.params_lock))
-		return -ERESTARTSYS;
+	if (!runtime->oss.params)
+		return 0;
 	sw_params = kzalloc(sizeof(*sw_params), GFP_KERNEL);
 	params = kmalloc(sizeof(*params), GFP_KERNEL);
 	sparams = kmalloc(sizeof(*sparams), GFP_KERNEL);

@@ -1079,6 +1076,23 @@ failure:
 	kfree(sw_params);
 	kfree(params);
 	kfree(sparams);
+	return err;
+}
+
+/* this one takes the lock by itself */
+static int snd_pcm_oss_change_params(struct snd_pcm_substream *substream,
+				     bool trylock)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	int err;
+
+	if (trylock) {
+		if (!(mutex_trylock(&runtime->oss.params_lock)))
+			return -EAGAIN;
+	} else if (mutex_lock_interruptible(&runtime->oss.params_lock))
+		return -ERESTARTSYS;
+
+	err = snd_pcm_oss_change_params_locked(substream);
 	mutex_unlock(&runtime->oss.params_lock);
 	return err;
 }

@@ -1107,11 +1121,14 @@ static int snd_pcm_oss_get_active_substr
 	return 0;
 }
 
+/* call with params_lock held */
 static int snd_pcm_oss_prepare(struct snd_pcm_substream *substream)
 {
 	int err;
 	struct snd_pcm_runtime *runtime = substream->runtime;
 
+	if (!runtime->oss.prepare)
+		return 0;
 	err = snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_PREPARE, NULL);
 	if (err < 0) {
 		pcm_dbg(substream->pcm,

@@ -1131,8 +1148,6 @@ static int snd_pcm_oss_make_ready(struct
 	struct snd_pcm_runtime *runtime;
 	int err;
 
-	if (substream == NULL)
-		return 0;
 	runtime = substream->runtime;
 	if (runtime->oss.params) {
 		err = snd_pcm_oss_change_params(substream, false);

@@ -1140,6 +1155,29 @@ static int snd_pcm_oss_make_ready(struct
 			return err;
 	}
 	if (runtime->oss.prepare) {
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
+		err = snd_pcm_oss_prepare(substream);
+		mutex_unlock(&runtime->oss.params_lock);
+		if (err < 0)
+			return err;
+	}
+	return 0;
+}
+
+/* call with params_lock held */
+static int snd_pcm_oss_make_ready_locked(struct snd_pcm_substream *substream)
+{
+	struct snd_pcm_runtime *runtime;
+	int err;
+
+	runtime = substream->runtime;
+	if (runtime->oss.params) {
+		err = snd_pcm_oss_change_params_locked(substream);
+		if (err < 0)
+			return err;
+	}
+	if (runtime->oss.prepare) {
 		err = snd_pcm_oss_prepare(substream);
 		if (err < 0)
 			return err;

@@ -1367,13 +1405,14 @@ static ssize_t snd_pcm_oss_write1(struct
 	if (atomic_read(&substream->mmap_count))
 		return -ENXIO;
 
-	if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
-		return tmp;
 	while (bytes > 0) {
 		if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
 			tmp = -ERESTARTSYS;
 			break;
 		}
+		tmp = snd_pcm_oss_make_ready_locked(substream);
+		if (tmp < 0)
+			goto err;
 		if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
 			tmp = bytes;
 			if (tmp + runtime->oss.buffer_used > runtime->oss.period_bytes)

@@ -1474,13 +1513,14 @@ static ssize_t snd_pcm_oss_read1(struct
 	if (atomic_read(&substream->mmap_count))
 		return -ENXIO;
 
-	if ((tmp = snd_pcm_oss_make_ready(substream)) < 0)
-		return tmp;
 	while (bytes > 0) {
 		if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
 			tmp = -ERESTARTSYS;
 			break;
 		}
+		tmp = snd_pcm_oss_make_ready_locked(substream);
+		if (tmp < 0)
+			goto err;
 		if (bytes < runtime->oss.period_bytes || runtime->oss.buffer_used > 0) {
 			if (runtime->oss.buffer_used == 0) {
 				tmp = snd_pcm_oss_read2(substream, runtime->oss.buffer, runtime->oss.period_bytes, 1);

@@ -1536,10 +1576,12 @@ static int snd_pcm_oss_reset(struct snd_
 			continue;
 		runtime = substream->runtime;
 		snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_DROP, NULL);
+		mutex_lock(&runtime->oss.params_lock);
 		runtime->oss.prepare = 1;
 		runtime->oss.buffer_used = 0;
 		runtime->oss.prev_hw_ptr_period = 0;
 		runtime->oss.period_ptr = 0;
+		mutex_unlock(&runtime->oss.params_lock);
 	}
 	return 0;
 }

@@ -1625,9 +1667,10 @@ static int snd_pcm_oss_sync(struct snd_p
 			goto __direct;
 		if ((err = snd_pcm_oss_make_ready(substream)) < 0)
 			return err;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
 		format = snd_pcm_oss_format_from(runtime->oss.format);
 		width = snd_pcm_format_physical_width(format);
-		mutex_lock(&runtime->oss.params_lock);
 		if (runtime->oss.buffer_used > 0) {
 #ifdef OSS_DEBUG
 			pcm_dbg(substream->pcm, "sync: buffer_used\n");

@@ -1695,7 +1738,9 @@ static int snd_pcm_oss_sync(struct snd_p
 		substream->f_flags = saved_f_flags;
 		if (err < 0)
 			return err;
+		mutex_lock(&runtime->oss.params_lock);
 		runtime->oss.prepare = 1;
+		mutex_unlock(&runtime->oss.params_lock);
 	}
 
 	substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_CAPTURE];

@@ -1706,8 +1751,10 @@ static int snd_pcm_oss_sync(struct snd_p
 		err = snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_DROP, NULL);
 		if (err < 0)
 			return err;
+		mutex_lock(&runtime->oss.params_lock);
 		runtime->oss.buffer_used = 0;
 		runtime->oss.prepare = 1;
+		mutex_unlock(&runtime->oss.params_lock);
 	}
 	return 0;
 }

@@ -1726,10 +1773,13 @@ static int snd_pcm_oss_set_rate(struct s
 			rate = 1000;
 		else if (rate > 192000)
 			rate = 192000;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
 		if (runtime->oss.rate != rate) {
 			runtime->oss.params = 1;
 			runtime->oss.rate = rate;
 		}
+		mutex_unlock(&runtime->oss.params_lock);
 	}
 	return snd_pcm_oss_get_rate(pcm_oss_file);
 }

@@ -1757,10 +1807,13 @@ static int snd_pcm_oss_set_channels(stru
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
 		if (runtime->oss.channels != channels) {
 			runtime->oss.params = 1;
 			runtime->oss.channels = channels;
 		}
+		mutex_unlock(&runtime->oss.params_lock);
 	}
 	return snd_pcm_oss_get_channels(pcm_oss_file);
 }

@@ -1846,10 +1899,13 @@ static int snd_pcm_oss_set_format(struct
 			if (substream == NULL)
 				continue;
 			runtime = substream->runtime;
+			if (mutex_lock_interruptible(&runtime->oss.params_lock))
+				return -ERESTARTSYS;
 			if (runtime->oss.format != format) {
 				runtime->oss.params = 1;
 				runtime->oss.format = format;
 			}
+			mutex_unlock(&runtime->oss.params_lock);
 		}
 	}
 	return snd_pcm_oss_get_format(pcm_oss_file);

@@ -1869,8 +1925,6 @@ static int snd_pcm_oss_set_subdivide1(st
 {
 	struct snd_pcm_runtime *runtime;
 
-	if (substream == NULL)
-		return 0;
 	runtime = substream->runtime;
 	if (subdivide == 0) {
 		subdivide = runtime->oss.subdivision;

@@ -1894,9 +1948,16 @@ static int snd_pcm_oss_set_subdivide(str
 
 	for (idx = 1; idx >= 0; --idx) {
 		struct snd_pcm_substream *substream = pcm_oss_file->streams[idx];
+		struct snd_pcm_runtime *runtime;
+
 		if (substream == NULL)
 			continue;
-		if ((err = snd_pcm_oss_set_subdivide1(substream, subdivide)) < 0)
+		runtime = substream->runtime;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
+		err = snd_pcm_oss_set_subdivide1(substream, subdivide);
+		mutex_unlock(&runtime->oss.params_lock);
+		if (err < 0)
 			return err;
 	}
 	return err;

@@ -1906,8 +1967,6 @@ static int snd_pcm_oss_set_fragment1(str
 {
 	struct snd_pcm_runtime *runtime;
 
-	if (substream == NULL)
-		return 0;
 	runtime = substream->runtime;
 	if (runtime->oss.subdivision || runtime->oss.fragshift)
 		return -EINVAL;

@@ -1927,9 +1986,16 @@ static int snd_pcm_oss_set_fragment(stru
 
 	for (idx = 1; idx >= 0; --idx) {
 		struct snd_pcm_substream *substream = pcm_oss_file->streams[idx];
+		struct snd_pcm_runtime *runtime;
+
 		if (substream == NULL)
 			continue;
-		if ((err = snd_pcm_oss_set_fragment1(substream, val)) < 0)
+		runtime = substream->runtime;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
+		err = snd_pcm_oss_set_fragment1(substream, val);
+		mutex_unlock(&runtime->oss.params_lock);
+		if (err < 0)
 			return err;
 	}
 	return err;

@@ -2013,6 +2079,9 @@ static int snd_pcm_oss_set_trigger(struc
 	}
       	if (psubstream) {
       		runtime = psubstream->runtime;
+		cmd = 0;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
 		if (trigger & PCM_ENABLE_OUTPUT) {
 			if (runtime->oss.trigger)
 				goto _skip1;

@@ -2030,13 +2099,19 @@ static int snd_pcm_oss_set_trigger(struc
 			cmd = SNDRV_PCM_IOCTL_DROP;
 			runtime->oss.prepare = 1;
 		}
-		err = snd_pcm_kernel_ioctl(psubstream, cmd, NULL);
-		if (err < 0)
-			return err;
-	}
  _skip1:
+		mutex_unlock(&runtime->oss.params_lock);
+		if (cmd) {
+			err = snd_pcm_kernel_ioctl(psubstream, cmd, NULL);
+			if (err < 0)
+				return err;
+		}
+	}
 	if (csubstream) {
       		runtime = csubstream->runtime;
+		cmd = 0;
+		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+			return -ERESTARTSYS;
 		if (trigger & PCM_ENABLE_INPUT) {
 			if (runtime->oss.trigger)
 				goto _skip2;

@@ -2051,11 +2126,14 @@ static int snd_pcm_oss_set_trigger(struc
 			cmd = SNDRV_PCM_IOCTL_DROP;
 			runtime->oss.prepare = 1;
 		}
-		err = snd_pcm_kernel_ioctl(csubstream, cmd, NULL);
-		if (err < 0)
-			return err;
-	}
  _skip2:
+		mutex_unlock(&runtime->oss.params_lock);
+		if (cmd) {
+			err = snd_pcm_kernel_ioctl(csubstream, cmd, NULL);
+			if (err < 0)
+				return err;
+		}
+	}
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #65 lore raw

PATCH 62/95 ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams

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

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

From: Takashi Iwai <[email protected]>

commit 40cab6e88cb0b6c56d3f30b7491a20e803f948f6 upstream.

OSS PCM stream management isn't modal but it allows ioctls issued at any time for changing the parameters. In the previous hardening patch ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write"), we covered these races and prevent the corruption by protecting the concurrent accesses via params_lock mutex. However, this means that some ioctls that try to change the stream parameter (e.g. channels or format) would be blocked until the read/write finishes, and it may take really long.

Basically changing the parameter while reading/writing is an invalid operation, hence it's even more user-friendly from the API POV if it returns -EBUSY in such a situation.

This patch adds such checks in the relevant ioctls with the addition of read/write access refcount.

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/sound/pcm_oss.h  |    1 +
 sound/core/oss/pcm_oss.c |   36 +++++++++++++++++++++++++++---------
 2 files changed, 28 insertions(+), 9 deletions(-)

include/sound/pcm_oss.h +1 -0

@@ -57,6 +57,7 @@ struct snd_pcm_oss_runtime {
 	char *buffer;				/* vmallocated period */
 	size_t buffer_used;			/* used length from period buffer */
 	struct mutex params_lock;
+	atomic_t rw_ref;		/* concurrent read/write accesses */
 #ifdef CONFIG_SND_PCM_OSS_PLUGINS
 	struct snd_pcm_plugin *plugin_first;
 	struct snd_pcm_plugin *plugin_last;

sound/core/oss/pcm_oss.c +27 -9

@@ -1405,6 +1405,7 @@ static ssize_t snd_pcm_oss_write1(struct
 	if (atomic_read(&substream->mmap_count))
 		return -ENXIO;
 
+	atomic_inc(&runtime->oss.rw_ref);
 	while (bytes > 0) {
 		if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
 			tmp = -ERESTARTSYS;

@@ -1468,6 +1469,7 @@ static ssize_t snd_pcm_oss_write1(struct
 		}
 		tmp = 0;
 	}
+	atomic_dec(&runtime->oss.rw_ref);
 	return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
 }

@@ -1513,6 +1515,7 @@ static ssize_t snd_pcm_oss_read1(struct
 	if (atomic_read(&substream->mmap_count))
 		return -ENXIO;
 
+	atomic_inc(&runtime->oss.rw_ref);
 	while (bytes > 0) {
 		if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
 			tmp = -ERESTARTSYS;

@@ -1561,6 +1564,7 @@ static ssize_t snd_pcm_oss_read1(struct
 		}
 		tmp = 0;
 	}
+	atomic_dec(&runtime->oss.rw_ref);
 	return xfer > 0 ? (snd_pcm_sframes_t)xfer : tmp;
 }

@@ -1667,8 +1671,11 @@ static int snd_pcm_oss_sync(struct snd_p
 			goto __direct;
 		if ((err = snd_pcm_oss_make_ready(substream)) < 0)
 			return err;
-		if (mutex_lock_interruptible(&runtime->oss.params_lock))
+		atomic_inc(&runtime->oss.rw_ref);
+		if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
+			atomic_dec(&runtime->oss.rw_ref);
 			return -ERESTARTSYS;
+		}
 		format = snd_pcm_oss_format_from(runtime->oss.format);
 		width = snd_pcm_format_physical_width(format);
 		if (runtime->oss.buffer_used > 0) {

@@ -1680,10 +1687,8 @@ static int snd_pcm_oss_sync(struct snd_p
 						   runtime->oss.buffer + runtime->oss.buffer_used,
 						   size);
 			err = snd_pcm_oss_sync1(substream, runtime->oss.period_bytes);
-			if (err < 0) {
-				mutex_unlock(&runtime->oss.params_lock);
-				return err;
-			}
+			if (err < 0)
+				goto unlock;
 		} else if (runtime->oss.period_ptr > 0) {
 #ifdef OSS_DEBUG
 			pcm_dbg(substream->pcm, "sync: period_ptr\n");

@@ -1693,10 +1698,8 @@ static int snd_pcm_oss_sync(struct snd_p
 						   runtime->oss.buffer,
 						   size * 8 / width);
 			err = snd_pcm_oss_sync1(substream, size);
-			if (err < 0) {
-				mutex_unlock(&runtime->oss.params_lock);
-				return err;
-			}
+			if (err < 0)
+				goto unlock;
 		}
 		/*
 		 * The ALSA's period might be a bit large than OSS one.

@@ -1727,7 +1730,11 @@ static int snd_pcm_oss_sync(struct snd_p
 				snd_pcm_lib_writev(substream, buffers, size);
 			}
 		}
+unlock:
 		mutex_unlock(&runtime->oss.params_lock);
+		atomic_dec(&runtime->oss.rw_ref);
+		if (err < 0)
+			return err;
 		/*
 		 * finish sync: drain the buffer
 		 */

@@ -1775,6 +1782,8 @@ static int snd_pcm_oss_set_rate(struct s
 			rate = 192000;
 		if (mutex_lock_interruptible(&runtime->oss.params_lock))
 			return -ERESTARTSYS;
+		if (atomic_read(&runtime->oss.rw_ref))
+			return -EBUSY;
 		if (runtime->oss.rate != rate) {
 			runtime->oss.params = 1;
 			runtime->oss.rate = rate;

@@ -1809,6 +1818,8 @@ static int snd_pcm_oss_set_channels(stru
 		runtime = substream->runtime;
 		if (mutex_lock_interruptible(&runtime->oss.params_lock))
 			return -ERESTARTSYS;
+		if (atomic_read(&runtime->oss.rw_ref))
+			return -EBUSY;
 		if (runtime->oss.channels != channels) {
 			runtime->oss.params = 1;
 			runtime->oss.channels = channels;

@@ -1899,6 +1910,8 @@ static int snd_pcm_oss_set_format(struct
 			if (substream == NULL)
 				continue;
 			runtime = substream->runtime;
+			if (atomic_read(&runtime->oss.rw_ref))
+				return -EBUSY;
 			if (mutex_lock_interruptible(&runtime->oss.params_lock))
 				return -ERESTARTSYS;
 			if (runtime->oss.format != format) {

@@ -1953,6 +1966,8 @@ static int snd_pcm_oss_set_subdivide(str
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;
+		if (atomic_read(&runtime->oss.rw_ref))
+			return -EBUSY;
 		if (mutex_lock_interruptible(&runtime->oss.params_lock))
 			return -ERESTARTSYS;
 		err = snd_pcm_oss_set_subdivide1(substream, subdivide);

@@ -1991,6 +2006,8 @@ static int snd_pcm_oss_set_fragment(stru
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;
+		if (atomic_read(&runtime->oss.rw_ref))
+			return -EBUSY;
 		if (mutex_lock_interruptible(&runtime->oss.params_lock))
 			return -ERESTARTSYS;
 		err = snd_pcm_oss_set_fragment1(substream, val);

@@ -2385,6 +2402,7 @@ static void snd_pcm_oss_init_substream(s
 	runtime->oss.maxfrags = 0;
 	runtime->oss.subdivision = 0;
 	substream->pcm_release = snd_pcm_oss_release_substream;
+	atomic_set(&runtime->oss.rw_ref, 0);
 }
 
 static int snd_pcm_oss_release_file(struct snd_pcm_oss_file *pcm_oss_file)

Greg Kroah-Hartman

author maintainer

2018-04-22 14:15 UTC #66 lore raw

PATCH 63/95 ALSA: pcm: Fix mutex unbalance in OSS emulation ioctls

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

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

From: Takashi Iwai <[email protected]>

commit f6d297df4dd47ef949540e4a201230d0c5308325 upstream.

The previous fix 40cab6e88cb0 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams") introduced some mutex unbalance; the check of runtime->oss.rw_ref was inserted in a wrong place after the mutex lock.

This patch fixes the inconsistency by rewriting with the helper functions to lock/unlock parameters with the stream check.

Fixes 40cab6e88cb0 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams")

Reported-by Dan Carpenter <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/oss/pcm_oss.c |   67 +++++++++++++++++++++++++++++------------------
 1 file changed, 42 insertions(+), 25 deletions(-)

sound/core/oss/pcm_oss.c +42 ~~-25~~

@@ -834,6 +834,23 @@ static int choose_rate(struct snd_pcm_su
 	return snd_pcm_hw_param_near(substream, params, SNDRV_PCM_HW_PARAM_RATE, best_rate, NULL);
 }
 
+/* parameter locking: returns immediately if tried during streaming */
+static int lock_params(struct snd_pcm_runtime *runtime)
+{
+	if (mutex_lock_interruptible(&runtime->oss.params_lock))
+		return -ERESTARTSYS;
+	if (atomic_read(&runtime->oss.rw_ref)) {
+		mutex_unlock(&runtime->oss.params_lock);
+		return -EBUSY;
+	}
+	return 0;
+}
+
+static void unlock_params(struct snd_pcm_runtime *runtime)
+{
+	mutex_unlock(&runtime->oss.params_lock);
+}
+
 /* call with params_lock held */
 static int snd_pcm_oss_change_params_locked(struct snd_pcm_substream *substream)
 {

@@ -1773,6 +1790,8 @@ static int snd_pcm_oss_set_rate(struct s
 	for (idx = 1; idx >= 0; --idx) {
 		struct snd_pcm_substream *substream = pcm_oss_file->streams[idx];
 		struct snd_pcm_runtime *runtime;
+		int err;
+
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;

@@ -1780,15 +1799,14 @@ static int snd_pcm_oss_set_rate(struct s
 			rate = 1000;
 		else if (rate > 192000)
 			rate = 192000;
-		if (mutex_lock_interruptible(&runtime->oss.params_lock))
-			return -ERESTARTSYS;
-		if (atomic_read(&runtime->oss.rw_ref))
-			return -EBUSY;
+		err = lock_params(runtime);
+		if (err < 0)
+			return err;
 		if (runtime->oss.rate != rate) {
 			runtime->oss.params = 1;
 			runtime->oss.rate = rate;
 		}
-		mutex_unlock(&runtime->oss.params_lock);
+		unlock_params(runtime);
 	}
 	return snd_pcm_oss_get_rate(pcm_oss_file);
 }

@@ -1813,18 +1831,19 @@ static int snd_pcm_oss_set_channels(stru
 	for (idx = 1; idx >= 0; --idx) {
 		struct snd_pcm_substream *substream = pcm_oss_file->streams[idx];
 		struct snd_pcm_runtime *runtime;
+		int err;
+
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;
-		if (mutex_lock_interruptible(&runtime->oss.params_lock))
-			return -ERESTARTSYS;
-		if (atomic_read(&runtime->oss.rw_ref))
-			return -EBUSY;
+		err = lock_params(runtime);
+		if (err < 0)
+			return err;
 		if (runtime->oss.channels != channels) {
 			runtime->oss.params = 1;
 			runtime->oss.channels = channels;
 		}
-		mutex_unlock(&runtime->oss.params_lock);
+		unlock_params(runtime);
 	}
 	return snd_pcm_oss_get_channels(pcm_oss_file);
 }

@@ -1897,6 +1916,7 @@ static int snd_pcm_oss_get_formats(struc
 static int snd_pcm_oss_set_format(struct snd_pcm_oss_file *pcm_oss_file, int format)
 {
 	int formats, idx;
+	int err;
 	
 	if (format != AFMT_QUERY) {
 		formats = snd_pcm_oss_get_formats(pcm_oss_file);

@@ -1910,15 +1930,14 @@ static int snd_pcm_oss_set_format(struct
 			if (substream == NULL)
 				continue;
 			runtime = substream->runtime;
-			if (atomic_read(&runtime->oss.rw_ref))
-				return -EBUSY;
-			if (mutex_lock_interruptible(&runtime->oss.params_lock))
-				return -ERESTARTSYS;
+			err = lock_params(runtime);
+			if (err < 0)
+				return err;
 			if (runtime->oss.format != format) {
 				runtime->oss.params = 1;
 				runtime->oss.format = format;
 			}
-			mutex_unlock(&runtime->oss.params_lock);
+			unlock_params(runtime);
 		}
 	}
 	return snd_pcm_oss_get_format(pcm_oss_file);

@@ -1966,12 +1985,11 @@ static int snd_pcm_oss_set_subdivide(str
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;
-		if (atomic_read(&runtime->oss.rw_ref))
-			return -EBUSY;
-		if (mutex_lock_interruptible(&runtime->oss.params_lock))
-			return -ERESTARTSYS;
+		err = lock_params(runtime);
+		if (err < 0)
+			return err;
 		err = snd_pcm_oss_set_subdivide1(substream, subdivide);
-		mutex_unlock(&runtime->oss.params_lock);
+		unlock_params(runtime);
 		if (err < 0)
 			return err;
 	}

@@ -2006,12 +2024,11 @@ static int snd_pcm_oss_set_fragment(stru
 		if (substream == NULL)
 			continue;
 		runtime = substream->runtime;
-		if (atomic_read(&runtime->oss.rw_ref))
-			return -EBUSY;
-		if (mutex_lock_interruptible(&runtime->oss.params_lock))
-			return -ERESTARTSYS;
+		err = lock_params(runtime);
+		if (err < 0)
+			return err;
 		err = snd_pcm_oss_set_fragment1(substream, val);
-		mutex_unlock(&runtime->oss.params_lock);
+		unlock_params(runtime);
 		if (err < 0)
 			return err;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #67 lore raw

PATCH 64/95 ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation

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

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

From: Takashi Iwai <[email protected]>

commit e15dc99dbb9cf99f6432e8e3c0b3a8f7a3403a86 upstream.

The commit 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") split the PCM preparation code to a locked version, and it added a sanity check of runtime->oss.prepare flag along with the change. This leaded to an endless loop when the stream gets XRUN: namely, snd_pcm_oss_write3() and co call snd_pcm_oss_prepare() without setting runtime->oss.prepare flag and the loop continues until the PCM state reaches to another one.

As the function is supposed to execute the preparation unconditionally, drop the invalid state check there.

The bug was triggered by syzkaller.

Fixes 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")

Reported-by [email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/oss/pcm_oss.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

sound/core/oss/pcm_oss.c +3 -2

@@ -1139,13 +1139,14 @@ static int snd_pcm_oss_get_active_substr
 }
 
 /* call with params_lock held */
+/* NOTE: this always call PREPARE unconditionally no matter whether
+ * runtime->oss.prepare is set or not
+ */
 static int snd_pcm_oss_prepare(struct snd_pcm_substream *substream)
 {
 	int err;
 	struct snd_pcm_runtime *runtime = substream->runtime;
 
-	if (!runtime->oss.prepare)
-		return 0;
 	err = snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_PREPARE, NULL);
 	if (err < 0) {
 		pcm_dbg(substream->pcm,

Greg Kroah-Hartman

author maintainer

2018-04-22 14:15 UTC #68 lore raw

PATCH 65/95 ext4: dont allow r/w mounts if metadata blocks overlap the superblock

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

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

From: Theodore Ts'o <[email protected]>

commit 18db4b4e6fc31eda838dd1c1296d67dbcb3dc957 upstream.

If some metadata block, such as an allocation bitmap, overlaps the superblock, it's very likely that if the file system is mounted read/write, the results will not be pretty. So disallow r/w mounts for file systems corrupted in this particular way.

Backport notes:
3.18.y is missing bc98a42c1f7d ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)") and e462ec50cb5f ("VFS: Differentiate mount flags (MS_*) from internal superblock flags") so we simply use the sb MS_RDONLY check from pre bc98a42c1f7d in place of the sb_rdonly function used in the upstream variant of the patch.

Signed-off-by Harsh Shandilya <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/super.c |    6 ++++++
 1 file changed, 6 insertions(+)

fs/ext4/super.c +6 -0

@@ -2260,6 +2260,8 @@ static int ext4_check_descriptors(struct
 			ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
 				 "Block bitmap for group %u overlaps "
 				 "superblock", i);
+			if (!(sb->s_flags & MS_RDONLY))
+				return 0;
 		}
 		if (block_bitmap < first_block || block_bitmap > last_block) {
 			ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "

@@ -2272,6 +2274,8 @@ static int ext4_check_descriptors(struct
 			ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
 				 "Inode bitmap for group %u overlaps "
 				 "superblock", i);
+			if (!(sb->s_flags & MS_RDONLY))
+				return 0;
 		}
 		if (inode_bitmap < first_block || inode_bitmap > last_block) {
 			ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "

@@ -2284,6 +2288,8 @@ static int ext4_check_descriptors(struct
 			ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
 				 "Inode table for group %u overlaps "
 				 "superblock", i);
+			if (!(sb->s_flags & MS_RDONLY))
+				return 0;
 		}
 		if (inode_table < first_block ||
 		    inode_table + sbi->s_itb_per_group - 1 > last_block) {

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #69 lore raw

PATCH 66/95 drm/amdgpu: Add an ATPX quirk for hybrid laptop

Bug https://bugs.freedesktop.org/show_bug.cgi?id=104064

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

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

From: Alex Deucher <[email protected]>

commit 13b40935cf64f59b93cf1c716a2033488e5a228c upstream.

_PR3 doesn't seem to work properly, use ATPX instead.

Reviewed-by Huang Rui <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +1 -0

@@ -569,6 +569,7 @@ static const struct amdgpu_px_quirk amdg
 	{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
 	{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
 	{ 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
+	{ 0x1002, 0x67DF, 0x1028, 0x0774, AMDGPU_PX_QUIRK_FORCE_ATPX },
 	{ 0, 0, 0, 0, 0 },
 };

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #70 lore raw

PATCH 67/95 drm/amdgpu: Fix always_valid bos multiple LRU insertions.

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

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

From: Bas Nieuwenhuizen <[email protected]>

commit a20ee0b1f8b42e2568f3a4408003d22b2dfcc706 upstream.

If these bos are evicted and are in the validated list things blow up, so do not put them in there. Notably, that tries to add the bo to the LRU twice, which results in a BUG_ON in ttm_bo.c.

While for the bo_list an alternative would be to not allow always valid bos in there, that does not work for the user fence.

v2: Fixed whitespace issue pointed out by checkpatch.pl

Signed-off-by Bas Nieuwenhuizen <[email protected]>

Reviewed-by Christian König <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |    6 ++++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c      |    2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c +4 -2

@@ -201,8 +201,10 @@ void amdgpu_bo_list_get_list(struct amdg
 	for (i = 0; i < list->num_entries; i++) {
 		unsigned priority = list->array[i].priority;
 
-		list_add_tail(&list->array[i].tv.head,
-			      &bucket[priority]);
+		if (!list->array[i].robj->parent)
+			list_add_tail(&list->array[i].tv.head,
+				      &bucket[priority]);
+
 		list->array[i].user_pages = NULL;
 	}

drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +1 -1

@@ -519,7 +519,7 @@ static int amdgpu_cs_parser_bos(struct a
 	INIT_LIST_HEAD(&duplicates);
 	amdgpu_vm_get_pd_bo(&fpriv->vm, &p->validated, &p->vm_pd);
 
-	if (p->uf_entry.robj)
+	if (p->uf_entry.robj && !p->uf_entry.robj->parent)
 		list_add(&p->uf_entry.tv.head, &p->validated);
 
 	if (need_mmap_lock)

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #71 lore raw

PATCH 68/95 drm/amdgpu: Fix PCIe lane width calculation

Bug https://bugs.freedesktop.org/show_bug.cgi?id=102553

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

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

From: Alex Deucher <[email protected]>

commit 41212e2fe72b26ded7ed78224d9eab720c2891e2 upstream.

The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere. Port of the radeon fix to amdgpu.

Acked-by Christian König <[email protected]>

Acked-by Chunming Zhou <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/amdgpu/si_dpm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/amd/amdgpu/si_dpm.c +2 -2

@@ -6449,9 +6449,9 @@ static void si_set_pcie_lane_width_in_sm
 {
 	u32 lane_width;
 	u32 new_lane_width =
-		(amdgpu_new_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT;
+		((amdgpu_new_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT) + 1;
 	u32 current_lane_width =
-		(amdgpu_current_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT;
+		((amdgpu_current_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT) + 1;
 
 	if (new_lane_width != current_lane_width) {
 		amdgpu_set_pcie_lanes(adev, new_lane_width);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #72 lore raw

PATCH 69/95 drm/rockchip: Clear all interrupts before requesting the IRQ

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

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

From: Marc Zyngier <[email protected]>

commit 5f9e93fed4d45e9a8f84728aff1a8f2ab8922902 upstream.

Calling request_irq() followed by disable_irq() is usually a bad idea, specially if the interrupt can be pending, and you're not yet in a position to handle it.

This is exactly what happens on my kevin system when rebooting in a second kernel using kexec: Some interrupt is left pending from the previous kernel, and we take it too early, before disable_irq() could do anything.

Let's clear the pending interrupts as we initialize the HW, and move the interrupt request after that point. This ensures that we're in a sane state when the interrupt is requested.

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Marc Zyngier <[email protected]>

[adapted to recent rockchip-drm changes]

Signed-off-by Heiko Stuebner <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

drivers/gpu/drm/rockchip/rockchip_drm_vop.c +12 ~~-11~~

@@ -1386,6 +1386,9 @@ static int vop_initial(struct vop *vop)
 	usleep_range(10, 20);
 	reset_control_deassert(ahb_rst);
 
+	VOP_INTR_SET_TYPE(vop, clear, INTR_MASK, 1);
+	VOP_INTR_SET_TYPE(vop, enable, INTR_MASK, 0);
+
 	memcpy(vop->regsbak, vop->regs, vop->len);
 
 	for (i = 0; i < vop_data->table_size; i++)

@@ -1541,17 +1544,9 @@ static int vop_bind(struct device *dev,
 
 	mutex_init(&vop->vsync_mutex);
 
-	ret = devm_request_irq(dev, vop->irq, vop_isr,
-			       IRQF_SHARED, dev_name(dev), vop);
-	if (ret)
-		return ret;
-
-	/* IRQ is initially disabled; it gets enabled in power_on */
-	disable_irq(vop->irq);
-
 	ret = vop_create_crtc(vop);
 	if (ret)
-		goto err_enable_irq;
+		return ret;
 
 	pm_runtime_enable(&pdev->dev);

@@ -1561,13 +1556,19 @@ static int vop_bind(struct device *dev,
 		goto err_disable_pm_runtime;
 	}
 
+	ret = devm_request_irq(dev, vop->irq, vop_isr,
+			       IRQF_SHARED, dev_name(dev), vop);
+	if (ret)
+		goto err_disable_pm_runtime;
+
+	/* IRQ is initially disabled; it gets enabled in power_on */
+	disable_irq(vop->irq);
+
 	return 0;
 
 err_disable_pm_runtime:
 	pm_runtime_disable(&pdev->dev);
 	vop_destroy_crtc(vop);
-err_enable_irq:
-	enable_irq(vop->irq); /* To balance out the disable_irq above */
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #73 lore raw

PATCH 70/95 drm/radeon: Fix PCIe lane width calculation

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

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

From: Paul Parsons <[email protected]>

commit 85e290d92b4b794d0c758c53007eb4248d385386 upstream.

Two years ago I tried an AMD Radeon E8860 embedded GPU with the drm driver. The dmesg output included driver warnings about an invalid PCIe lane width. Tracking the problem back led to si_set_pcie_lane_width_in_smc(). The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere. Applying the increment silenced the warnings.
The code has not changed since, so either my analysis was incorrect or the bug has gone unnoticed. Hence submitting this as an RFC.

Acked-by Christian König <[email protected]>

Acked-by Chunming Zhou <[email protected]>

Signed-off-by Paul Parsons <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/radeon/si_dpm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/radeon/si_dpm.c +2 -2

@@ -5969,9 +5969,9 @@ static void si_set_pcie_lane_width_in_sm
 {
 	u32 lane_width;
 	u32 new_lane_width =
-		(radeon_new_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT;
+		((radeon_new_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT) + 1;
 	u32 current_lane_width =
-		(radeon_current_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT;
+		((radeon_current_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT) + 1;
 
 	if (new_lane_width != current_lane_width) {
 		radeon_set_pcie_lanes(rdev, new_lane_width);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #74 lore raw

PATCH 71/95 ALSA: line6: Use correct endpoint type for midi output

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

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

From: Fabián Inostroza <[email protected]>

commit 7ecb46e9ee9af18e304eb9e7d6804c59a408e846 upstream.

Sending MIDI messages to a PODxt through the USB connection shows "usb_submit_urb failed" in dmesg and the message is not received by the POD.

The error is caused because in the funcion send_midi_async() in midi.c there is a call to usb_sndbulkpipe() for endpoint 3 OUT, but the PODxt USB descriptor shows that this endpoint it's an interrupt endpoint.

Patch tested with PODxt only.

[ The bug has been present from the very beginning in the staging
driver time, but Fixes below points to the commit moving to sound/ directory so that the fix can be cleanly applied -- tiwai ]

Fixes 61864d844c29 ("ALSA: move line6 usb driver into sound/usb")

Signed-off-by Fabián Inostroza <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/usb/line6/midi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/usb/line6/midi.c +1 -1

@@ -125,7 +125,7 @@ static int send_midi_async(struct usb_li
 	}
 
 	usb_fill_int_urb(urb, line6->usbdev,
-			 usb_sndbulkpipe(line6->usbdev,
+			 usb_sndintpipe(line6->usbdev,
 					 line6->properties->ep_ctrl_w),
 			 transfer_buffer, length, midi_sent, line6,
 			 line6->interval);

Greg Kroah-Hartman

author maintainer

2018-04-22 14:13 UTC #75 lore raw

PATCH 72/95 ALSA: rawmidi: Fix missing input substream checks in compat ioctls

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

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

From: Takashi Iwai <[email protected]>

commit 8a56ef4f3ffba9ebf4967b61ef600b0a7ba10f11 upstream.

Some rawmidi compat ioctls lack of the input substream checks (although they do check only for rfile->output). This many eventually lead to an Oops as NULL substream is passed to the rawmidi core functions.

Fix it by adding the proper checks before each function call.

The bug was spotted by syzkaller.

Reported-by [email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/rawmidi_compat.c |   18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

sound/core/rawmidi_compat.c +12 -6

@@ -36,8 +36,6 @@ static int snd_rawmidi_ioctl_params_comp
 	struct snd_rawmidi_params params;
 	unsigned int val;
 
-	if (rfile->output == NULL)
-		return -EINVAL;
 	if (get_user(params.stream, &src->stream) ||
 	    get_user(params.buffer_size, &src->buffer_size) ||
 	    get_user(params.avail_min, &src->avail_min) ||

@@ -46,8 +44,12 @@ static int snd_rawmidi_ioctl_params_comp
 	params.no_active_sensing = val;
 	switch (params.stream) {
 	case SNDRV_RAWMIDI_STREAM_OUTPUT:
+		if (!rfile->output)
+			return -EINVAL;
 		return snd_rawmidi_output_params(rfile->output, &params);
 	case SNDRV_RAWMIDI_STREAM_INPUT:
+		if (!rfile->input)
+			return -EINVAL;
 		return snd_rawmidi_input_params(rfile->input, &params);
 	}
 	return -EINVAL;

@@ -67,16 +69,18 @@ static int snd_rawmidi_ioctl_status_comp
 	int err;
 	struct snd_rawmidi_status status;
 
-	if (rfile->output == NULL)
-		return -EINVAL;
 	if (get_user(status.stream, &src->stream))
 		return -EFAULT;
 
 	switch (status.stream) {
 	case SNDRV_RAWMIDI_STREAM_OUTPUT:
+		if (!rfile->output)
+			return -EINVAL;
 		err = snd_rawmidi_output_status(rfile->output, &status);
 		break;
 	case SNDRV_RAWMIDI_STREAM_INPUT:
+		if (!rfile->input)
+			return -EINVAL;
 		err = snd_rawmidi_input_status(rfile->input, &status);
 		break;
 	default:

@@ -112,16 +116,18 @@ static int snd_rawmidi_ioctl_status_x32(
 	int err;
 	struct snd_rawmidi_status status;
 
-	if (rfile->output == NULL)
-		return -EINVAL;
 	if (get_user(status.stream, &src->stream))
 		return -EFAULT;
 
 	switch (status.stream) {
 	case SNDRV_RAWMIDI_STREAM_OUTPUT:
+		if (!rfile->output)
+			return -EINVAL;
 		err = snd_rawmidi_output_status(rfile->output, &status);
 		break;
 	case SNDRV_RAWMIDI_STREAM_INPUT:
+		if (!rfile->input)
+			return -EINVAL;
 		err = snd_rawmidi_input_status(rfile->input, &status);
 		break;
 	default:

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #76 lore raw

PATCH 73/95 ALSA: hda - New VIA controller suppor no-snoop path

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

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

From: David Wang <[email protected]>

commit af52f9982e410edac21ca4b49563053ffc9da1eb upstream.

This patch is used to tell kernel that new VIA HDAC controller also support no-snoop path.

[ minor coding style fix by tiwai ]

Signed-off-by David Wang <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/hda_intel.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/pci/hda/hda_intel.c +2 -1

@@ -1514,7 +1514,8 @@ static void azx_check_snoop_available(st
 		 */
 		u8 val;
 		pci_read_config_byte(chip->pci, 0x42, &val);
-		if (!(val & 0x80) && chip->pci->revision == 0x30)
+		if (!(val & 0x80) && (chip->pci->revision == 0x30 ||
+				      chip->pci->revision == 0x20))
 			snoop = false;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #77 lore raw

PATCH 74/95 random: fix crng_ready() test

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

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

From: Theodore Ts'o <[email protected]>

commit 43838a23a05fbd13e47d750d3dfd77001536dd33 upstream.

The crng_init variable has three states:

0: The CRNG is not initialized at all
1: The CRNG has a small amount of entropy, hopefully good enough for
early-boot, non-cryptographical use cases
2: The CRNG is fully initialized and we are sure it is safe for
cryptographic use cases.

The crng_ready() function should only return true once we are in the last state. This addresses CVE-2018-1108.

Reported-by Jann Horn <[email protected]>

Fixes e192be9d9a30 ("random: replace non-blocking pool...")

Cc [email protected] # 4.8+

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/char/random.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/char/random.c +5 -5

@@ -434,7 +434,7 @@ struct crng_state primary_crng = {
  * its value (from 0->1->2).
  */
 static int crng_init = 0;
-#define crng_ready() (likely(crng_init > 0))
+#define crng_ready() (likely(crng_init > 1))
 static int crng_init_cnt = 0;
 #define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)
 static void _extract_crng(struct crng_state *crng,

@@ -800,7 +800,7 @@ static int crng_fast_load(const char *cp
 
 	if (!spin_trylock_irqsave(&primary_crng.lock, flags))
 		return 0;
-	if (crng_ready()) {
+	if (crng_init != 0) {
 		spin_unlock_irqrestore(&primary_crng.lock, flags);
 		return 0;
 	}

@@ -872,7 +872,7 @@ static void _extract_crng(struct crng_st
 {
 	unsigned long v, flags;
 
-	if (crng_init > 1 &&
+	if (crng_ready() &&
 	    time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL))
 		crng_reseed(crng, crng == &primary_crng ? &input_pool : NULL);
 	spin_lock_irqsave(&crng->lock, flags);

@@ -1153,7 +1153,7 @@ void add_interrupt_randomness(int irq, i
 	fast_mix(fast_pool);
 	add_interrupt_bench(cycles);
 
-	if (!crng_ready()) {
+	if (unlikely(crng_init == 0)) {
 		if ((fast_pool->count >= 64) &&
 		    crng_fast_load((char *) fast_pool->pool,
 				   sizeof(fast_pool->pool))) {

@@ -2148,7 +2148,7 @@ void add_hwgenerator_randomness(const ch
 {
 	struct entropy_store *poolp = &input_pool;
 
-	if (!crng_ready()) {
+	if (unlikely(crng_init == 0)) {
 		crng_fast_load(buffer, count);
 		return;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #78 lore raw

PATCH 75/95 random: set up the NUMA crng instances after the CRNG is fully initialized

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

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

From: Theodore Ts'o <[email protected]>

commit 8ef35c866f8862df074a49a93b0309725812dea8 upstream.

Until the primary_crng is fully initialized, don't initialize the NUMA crng nodes. Otherwise users of /dev/urandom on NUMA systems before the CRNG is fully initialized can get very bad quality randomness. Of course everyone should move to getrandom(2) where this won't be an issue, but there's a lot of legacy code out there. This related to CVE-2018-1108.

Reported-by Jann Horn <[email protected]>

Fixes 1e7f583af67b ("random: make /dev/urandom scalable for silly...")

Cc [email protected] # 4.8+

In reply to Theodore Y. Ts'o

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/char/random.c |   46 +++++++++++++++++++++++++++-------------------
 1 file changed, 27 insertions(+), 19 deletions(-)

drivers/char/random.c +27 ~~-19~~

@@ -818,6 +818,32 @@ static int crng_fast_load(const char *cp
 	return 1;
 }
 
+#ifdef CONFIG_NUMA
+static void numa_crng_init(void)
+{
+	int i;
+	struct crng_state *crng;
+	struct crng_state **pool;
+
+	pool = kcalloc(nr_node_ids, sizeof(*pool), GFP_KERNEL|__GFP_NOFAIL);
+	for_each_online_node(i) {
+		crng = kmalloc_node(sizeof(struct crng_state),
+				    GFP_KERNEL | __GFP_NOFAIL, i);
+		spin_lock_init(&crng->lock);
+		crng_initialize(crng);
+		pool[i] = crng;
+	}
+	mb();
+	if (cmpxchg(&crng_node_pool, NULL, pool)) {
+		for_each_node(i)
+			kfree(pool[i]);
+		kfree(pool);
+	}
+}
+#else
+static void numa_crng_init(void) {}
+#endif
+
 static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
 {
 	unsigned long	flags;

@@ -847,6 +873,7 @@ static void crng_reseed(struct crng_stat
 	memzero_explicit(&buf, sizeof(buf));
 	crng->init_time = jiffies;
 	if (crng == &primary_crng && crng_init < 2) {
+		numa_crng_init();
 		crng_init = 2;
 		process_random_ready_list();
 		wake_up_interruptible(&crng_init_wait);

@@ -1659,28 +1686,9 @@ static void init_std_data(struct entropy
  */
 static int rand_initialize(void)
 {
-#ifdef CONFIG_NUMA
-	int i;
-	struct crng_state *crng;
-	struct crng_state **pool;
-#endif
-
 	init_std_data(&input_pool);
 	init_std_data(&blocking_pool);
 	crng_initialize(&primary_crng);
-
-#ifdef CONFIG_NUMA
-	pool = kcalloc(nr_node_ids, sizeof(*pool), GFP_KERNEL|__GFP_NOFAIL);
-	for_each_online_node(i) {
-		crng = kmalloc_node(sizeof(struct crng_state),
-				    GFP_KERNEL | __GFP_NOFAIL, i);
-		spin_lock_init(&crng->lock);
-		crng_initialize(crng);
-		pool[i] = crng;
-	}
-	mb();
-	crng_node_pool = pool;
-#endif
 	return 0;
 }
 early_initcall(rand_initialize);

Ben Hutchings

2018-04-22 22:29 UTC #79 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 15 lines · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 8ef35c866f8862df074a49a93b0309725812dea8 upstream.
Until the primary_crng is fully initialized, don't initialize the NUMA crng nodes. Otherwise users of /dev/urandom on NUMA systems before the CRNG is fully initialized can get very bad quality randomness. Of course everyone should move to getrandom(2) where this won't be an issue, but there's a lot of legacy code out there. This related to CVE-2018-1108.

Quoted 5 lines

Reported-by Jann Horn <[email protected]>
Fixes 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc [email protected] # 4.8+
Signed-off-by Theodore Ts'o <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>

In 4.9 (and probably older branches too) this leads to a deadlock:

crng_reseed(primary_crng, ...) takes primary_crng.lock -> numa_rcng_init()
-> crng_initialize()

      -> get_random_bytes()
         -> extract_crng()
            -> _extract_crng(primary_crng, ...) tries to take primary_crng.lock

I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.

Ben.

Quoted 78 lines

---
 drivers/char/random.c |   46 +++++++++++++++++++++++++++-------------------
 1 file changed, 27 insertions(+), 19 deletions(-)

drivers/char/random.c +27 ~~-19~~

@@ -818,6 +818,32 @@ static int crng_fast_load(const char *cp
 	return 1;
 }
 
+#ifdef CONFIG_NUMA
+static void numa_crng_init(void)
+{
+	int i;
+	struct crng_state *crng;
+	struct crng_state **pool;
+
+	pool = kcalloc(nr_node_ids, sizeof(*pool), GFP_KERNEL|__GFP_NOFAIL);
+	for_each_online_node(i) {
+		crng = kmalloc_node(sizeof(struct crng_state),
+				    GFP_KERNEL | __GFP_NOFAIL, i);
+		spin_lock_init(&crng->lock);
+		crng_initialize(crng);
+		pool[i] = crng;
+	}
+	mb();
+	if (cmpxchg(&crng_node_pool, NULL, pool)) {
+		for_each_node(i)
+			kfree(pool[i]);
+		kfree(pool);
+	}
+}
+#else
+static void numa_crng_init(void) {}
+#endif
+
 static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
 {
 	unsigned long	flags;

@@ -847,6 +873,7 @@ static void crng_reseed(struct crng_stat
 	memzero_explicit(&buf, sizeof(buf));
 	crng->init_time = jiffies;
 	if (crng == &primary_crng && crng_init < 2) {
+		numa_crng_init();
 		crng_init = 2;
 		process_random_ready_list();
 		wake_up_interruptible(&crng_init_wait);

@@ -1659,28 +1686,9 @@ static void init_std_data(struct entropy
  */
 static int rand_initialize(void)
 {
-#ifdef CONFIG_NUMA
-	int i;
-	struct crng_state *crng;
-	struct crng_state **pool;
-#endif
-
 	init_std_data(&input_pool);
 	init_std_data(&blocking_pool);
 	crng_initialize(&primary_crng);
-
-#ifdef CONFIG_NUMA
-	pool = kcalloc(nr_node_ids, sizeof(*pool), GFP_KERNEL|__GFP_NOFAIL);
-	for_each_online_node(i) {
-		crng = kmalloc_node(sizeof(struct crng_state),
-				    GFP_KERNEL | __GFP_NOFAIL, i);
-		spin_lock_init(&crng->lock);
-		crng_initialize(crng);
-		pool[i] = crng;
-	}
-	mb();
-	crng_node_pool = pool;
-#endif
 	return 0;
 }
 early_initcall(rand_initialize);

Signature · 3 lines

Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.

Greg Kroah-Hartman

author maintainer

2018-04-23 07:15 UTC #80 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 27 lines · Ben Hutchings

Quoted 15 lines · Greg Kroah-Hartman
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 8ef35c866f8862df074a49a93b0309725812dea8 upstream.
Until the primary_crng is fully initialized, don't initialize the NUMA crng nodes. Otherwise users of /dev/urandom on NUMA systems before the CRNG is fully initialized can get very bad quality randomness. Of course everyone should move to getrandom(2) where this won't be an issue, but there's a lot of legacy code out there. This related to CVE-2018-1108.
Quoted 5 lines
Reported-by Jann Horn <[email protected]>
Fixes 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc [email protected] # 4.8+
Signed-off-by Theodore Ts'o <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
In 4.9 (and probably older branches too) this leads to a deadlock:
crng_reseed(primary_crng, ...) takes primary_crng.lock -> numa_rcng_init()
-> crng_initialize()

Quoted 7 lines

      -> get_random_bytes()
         -> extract_crng()
            -> _extract_crng(primary_crng, ...) tries to take primary_crng.lock
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.

According to Tetsuo Handa, it's also causing problems in mainline :(

Ted, any thoughts as to what to do here?

thanks,

greg k-h

Tetsuo Handa

2018-04-23 10:21 UTC #81 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 7 lines · Greg Kroah-Hartman

Quoted 3 lines
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.
According to Tetsuo Handa, it's also causing problems in mainline :(
Ted, any thoughts as to what to do here?

(Resending because Webmail post was rejected by both stable ML and linux-kernel ML.)

Subject: random: GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context

Hello.

Commit 8ef35c866f8862df ("random: set up the NUMA crng instances after the CRNG is fully initialized") is causing sleep inside atomic warning due to GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context. Though it unlikely sleeps because there will be enough free memory at boot up...

Please don't backport that patch now.

[    9.712722] BUG: sleeping function called from invalid context at mm/slab.h:421
[    9.715231] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/2
[    9.717396] INFO: lockdep is turned off.
[    9.718717] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.17.0-rc1+ #480
[    9.720857] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[    9.724328] Call Trace:
[    9.725176]  <IRQ>
[    9.725880]  dump_stack+0xb1/0xfc
[    9.727003]  ___might_sleep+0x23e/0x270
[    9.728285]  __might_sleep+0x45/0x80
[    9.729479]  __kmalloc+0x284/0x3e0
[    9.730642]  ? crng_reseed+0x122/0x320
[    9.731876]  crng_reseed+0x122/0x320
[    9.733078]  credit_entropy_bits+0x2f6/0x370
[    9.734503]  ? add_timer_randomness+0xb8/0xd0
[    9.735880]  add_timer_randomness+0xb8/0xd0
[    9.737201]  add_disk_randomness+0x32/0x170
[    9.738666]  scsi_end_request+0x182/0x210
[    9.740004]  scsi_io_completion+0x2cd/0x620
[    9.741448]  scsi_finish_command+0xf3/0x170
[    9.742844]  scsi_softirq_done+0x12b/0x170
[    9.744209]  blk_done_softirq+0xb2/0xd0
[    9.745501]  __do_softirq+0xcf/0x49b
[    9.746726]  irq_exit+0xbc/0xd0
[    9.747785]  smp_call_function_single_interrupt+0x17a/0x270
[    9.749603]  call_function_single_interrupt+0xf/0x20
[    9.751240]  </IRQ>
[    9.751970] RIP: 0010:native_safe_halt+0x6/0x10
[    9.753467] RSP: 0018:ffff88011963fe78 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff04
[    9.755922] RAX: ffff880119626380 RBX: ffff880119626380 RCX: 0000000000000000
[    9.758362] RDX: ffff880119626380 RSI: 0000000000000001 RDI: ffff880119626380
[    9.760743] RBP: ffff88011963fe78 R08: 0000000000000000 R09: 0000000000000000
[    9.763068] R10: 0000000000000001 R11: ffff88011a4a3693 R12: 0000000000000002
[    9.765382] R13: 0000000000000000 R14: 0000000000000000 R15: ffff880119626380
[    9.767709]  ? trace_hardirqs_on+0xd/0x10
[    9.769044]  default_idle+0x2c/0x1a0
[    9.770333]  arch_cpu_idle+0x10/0x20
[    9.771526]  default_idle_call+0x1e/0x40
[    9.772833]  do_idle+0x196/0x2a0
[    9.773923]  ? complete+0x48/0x50
[    9.775068]  cpu_startup_entry+0x5f/0x62
[    9.776392]  start_secondary+0x1a3/0x1f0
[    9.777697]  secondary_startup_64+0xa5/0xb0
[    9.779101] random: crng init done

# ./scripts/faddr2line vmlinux crng_reseed+0x122/0x320
crng_reseed+0x122/0x320:
kmalloc_array at include/linux/slab.h:631
626     {
627             if (size != 0 && n > SIZE_MAX / size)
628                     return NULL;
629             if (__builtin_constant_p(n) && __builtin_constant_p(size))
630                     return kmalloc(n * size, flags);
631             return __kmalloc(n * size, flags);
632     }
633
634     /**
635      * kcalloc - allocate memory for an array. The memory is set to zero.
636      * @n: number of elements.
(inlined by) kcalloc at include/linux/slab.h:642
637      * @size: element size.
638      * @flags: the type of memory to allocate (see kmalloc).
639      */
640     static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
641     {
642             return kmalloc_array(n, size, flags | __GFP_ZERO);
643     }
644
645     /*
646      * kmalloc_track_caller is a special version of kmalloc that records the
647      * calling function of the routine calling it for slab leak tracking instead
(inlined by) numa_crng_init at drivers/char/random.c:798
793     {
794             int i;
795             struct crng_state *crng;
796             struct crng_state **pool;
797
798             pool = kcalloc(nr_node_ids, sizeof(*pool), GFP_KERNEL|__GFP_NOFAIL);
799             for_each_online_node(i) {
800                     crng = kmalloc_node(sizeof(struct crng_state),
801                                         GFP_KERNEL | __GFP_NOFAIL, i);
802                     spin_lock_init(&crng->lock);
803                     crng_initialize(crng);
(inlined by) crng_reseed at drivers/char/random.c:923
918             memzero_explicit(&buf, sizeof(buf));
919             crng->init_time = jiffies;
920             spin_unlock_irqrestore(&crng->lock, flags);
921             if (crng == &primary_crng && crng_init < 2) {
922                     invalidate_batched_entropy();
923                     numa_crng_init();
924                     crng_init = 2;
925                     process_random_ready_list();
926                     wake_up_interruptible(&crng_init_wait);
927                     pr_notice("random: crng init done\n");
928             }

Theodore Y. Ts'o

2018-04-23 15:56 UTC #82 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 13 lines · Tetsuo Handa

Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.
According to Tetsuo Handa, it's also causing problems in mainline :(
Ted, any thoughts as to what to do here?
(Resending because Webmail post was rejected by both stable ML and linux-kernel ML.)
Subject: random: GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context

Quoted 8 lines

Hello.
Commit 8ef35c866f8862df ("random: set up the NUMA crng instances after the CRNG is fully initialized") is causing sleep inside atomic warning due to GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context. Though it unlikely sleeps because there will be enough free memory at boot up...
Please don't backport that patch now.

Yes, please hold off on this in the stable queues as well. What we'll probably need to do is call defer the processing to a workqueue in the CONFIG_NUMA case.

- Ted

Greg KH

author maintainer

2018-04-23 18:01 UTC #83 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 21 lines · Theodore Y. Ts'o

Quoted 20 lines · Tetsuo Handa
Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.
According to Tetsuo Handa, it's also causing problems in mainline :(
Ted, any thoughts as to what to do here?
(Resending because Webmail post was rejected by both stable ML and linux-kernel ML.)
Subject: random: GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context
Hello.
Commit 8ef35c866f8862df ("random: set up the NUMA crng instances after the CRNG is fully initialized") is causing sleep inside atomic warning due to GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context. Though it unlikely sleeps because there will be enough free memory at boot up...

Quoted 5 lines

Quoted 1 line
Please don't backport that patch now.
Yes, please hold off on this in the stable queues as well. What we'll probably need to do is call defer the processing to a workqueue in the CONFIG_NUMA case.

I've dropped this patch from 4.16.y, 4.14.y, and 4.9.y for now.

thanks,

greg k-h

Ingo Molnar

2018-04-26 06:04 UTC #84 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 21 lines · Theodore Y. Ts'o

Quoted 20 lines · Tetsuo Handa
Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.
According to Tetsuo Handa, it's also causing problems in mainline :(
Ted, any thoughts as to what to do here?
(Resending because Webmail post was rejected by both stable ML and linux-kernel ML.)
Subject: random: GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context
Hello.
Commit 8ef35c866f8862df ("random: set up the NUMA crng instances after the CRNG is fully initialized") is causing sleep inside atomic warning due to GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context. Though it unlikely sleeps because there will be enough free memory at boot up...

Quoted 5 lines

Quoted 1 line
Please don't backport that patch now.
Yes, please hold off on this in the stable queues as well. What we'll probably need to do is call defer the processing to a workqueue in the CONFIG_NUMA case.

What's the resolution here? It's still triggering upstream as well, as of 69bfd470f462:

[    8.881634] dracut: Switching root

[    8.994899] ================================
[    8.999338] WARNING: inconsistent lock state
[    9.003760] 4.17.0-rc2-00151-g43ae031-dirty #1 Not tainted
[    9.009389] --------------------------------
[    9.013803] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[    9.019956] swapper/2/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[    9.025244]         (ptrval) (fs_reclaim){?.+.}, at: fs_reclaim_acquire.part.87+0x5/0x30
[    9.033598] {HARDIRQ-ON-W} state was registered at:
[    9.038628]   fs_reclaim_acquire.part.87+0x29/0x30
[    9.043568]   kmem_cache_alloc_trace+0x2c/0x240
[    9.048248]   alloc_workqueue_attrs+0x29/0x60
[    9.052755]   workqueue_init+0x4a/0x2e4
[    9.056741]   kernel_init_freeable+0x108/0x286
[    9.061335]   kernel_init+0xa/0x110
[    9.064974]   ret_from_fork+0x27/0x50

....

Is there a fix or a revert that can be tested?

Thanks,

Ingo

Tetsuo Handa

2018-04-26 06:46 UTC #85 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 21 lines · Ingo Molnar

What\'s the resolution here? It\'s still triggering upstream as well, as of 69bfd470f462:

[    8.881634] dracut: Switching root

[    8.994899] ================================
[    8.999338] WARNING: inconsistent lock state
[    9.003760] 4.17.0-rc2-00151-g43ae031-dirty #1 Not tainted
[    9.009389] --------------------------------
[    9.013803] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[    9.019956] swapper/2/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[    9.025244]         (ptrval) (fs_reclaim){?.+.}, at: fs_reclaim_acquire.part.87+0x5/0x30
[    9.033598] {HARDIRQ-ON-W} state was registered at:
[    9.038628]   fs_reclaim_acquire.part.87+0x29/0x30
[    9.043568]   kmem_cache_alloc_trace+0x2c/0x240
[    9.048248]   alloc_workqueue_attrs+0x29/0x60
[    9.052755]   workqueue_init+0x4a/0x2e4
[    9.056741]   kernel_init_freeable+0x108/0x286
[    9.061335]   kernel_init+0xa/0x110
[    9.064974]   ret_from_fork+0x27/0x50

Quoted 3 lines

....
Is there a fix or a revert that can be tested?

Yes, you can test a fix at http://lkml.kernel.org/r/[email protected] .

I thought that that fix still causes a problem. But it seems that I made a quick judgment. I can no longer reproduce the problem with that fix.

Tetsuo Handa

2018-04-26 06:54 UTC #86 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

In reply to Ingo Molnar

Oh, pull request was already sent. Should be merged shortly.

https://marc.info/?l=linux-kernel&m=152472466201090&w=2

Theodore Y. Ts'o

2018-04-26 17:29 UTC #87 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 3 lines · Tetsuo Handa

Oh, pull request was already sent. Should be merged shortly.
https://marc.info/?l=linux-kernel&m=152472466201090&w=2

More testing, either before or after merging, would be greatly appreciated. One of the challenges is that there are a lot of systems out there with different amounts of boot entropy available. So this pull request was needed to help deal with issues on crazy big machines (CONFIG_NUMA) and crazy small laptops (old/small chromebooks repurposed to support Ubuntu and small ARM systems) --- neither of which I had access to when I was putting together the fixes to the random driver.

So any feedback before 4.17 gets released would be really helpful!

Thanks!!

- Ted

Ingo Molnar

2018-04-27 09:44 UTC #88 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 14 lines · Theodore Y. Ts'o

Quoted 3 lines · Tetsuo Handa
Oh, pull request was already sent. Should be merged shortly.
https://marc.info/?l=linux-kernel&m=152472466201090&w=2
More testing, either before or after merging, would be greatly appreciated. One of the challenges is that there are a lot of systems out there with different amounts of boot entropy available. So this pull request was needed to help deal with issues on crazy big machines (CONFIG_NUMA) and crazy small laptops (old/small chromebooks repurposed to support Ubuntu and small ARM systems) --- neither of which I had access to when I was putting together the fixes to the random driver.

Quoted 3 lines

So any feedback before 4.17 gets released would be really helpful!
Thanks!!

I tested this upstream commit:

665fa0000aed: Merge tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random

... and the bug is fixed here too, my test machine is back to 'perfect'.

Thanks!

Ingo

Salvatore Bonaccorso

2018-04-23 07:21 UTC #89 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

In reply to Ben Hutchings

Quoted 27 lines · Ben Hutchings

Quoted 15 lines · Greg Kroah-Hartman
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 8ef35c866f8862df074a49a93b0309725812dea8 upstream.
Until the primary_crng is fully initialized, don't initialize the NUMA crng nodes. Otherwise users of /dev/urandom on NUMA systems before the CRNG is fully initialized can get very bad quality randomness. Of course everyone should move to getrandom(2) where this won't be an issue, but there's a lot of legacy code out there. This related to CVE-2018-1108.
Quoted 5 lines
Reported-by Jann Horn <[email protected]>
Fixes 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc [email protected] # 4.8+
Signed-off-by Theodore Ts'o <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
In 4.9 (and probably older branches too) this leads to a deadlock:
crng_reseed(primary_crng, ...) takes primary_crng.lock -> numa_rcng_init()
-> crng_initialize()

Quoted 7 lines

      -> get_random_bytes()
         -> extract_crng()
            -> _extract_crng(primary_crng, ...) tries to take primary_crng.lock
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.

That is, the following test patch on top of the 4.9-stable review queue seem to resolve the issue. The commit message of the original commit 4a072c71f49b0a0e495ea13423bdb850da73c58c would though not match anymore.

Regards,
Salvatore

From: "Jason A. Donenfeld" <[email protected]>
Date: Thu, 15 Jun 2017 00:45:26 +0200
Subject: random: silence compiler warnings and fix race
Origin: https://git.kernel.org/linus/4a072c71f49b0a0e495ea13423bdb850da73c58c

Odd versions of gcc for the sh4 architecture will actually warn about flags being used while uninitialized, so we set them to zero. Non crazy gccs will optimize that out again, so it doesn't make a difference.

Next, over aggressive gccs could inline the expression that defines use_lock, which could then introduce a race resulting in a lock imbalance. By using READ_ONCE, we prevent that fate. Finally, we make that assignment const, so that gcc can still optimize a nice amount.

Finally, we fix a potential deadlock between primary_crng.lock and batched_entropy_reset_lock, where they could be called in opposite order. Moving the call to invalidate_batched_entropy to outside the lock rectifies this issue.

Fixes b169c13de473a85b3c859bb36216a4cb5f00a54a

Signed-off-by Jason A. Donenfeld <[email protected]>

[Salvatore Bonaccorso: backport to 4.9: context changes, only apply change to address potential deadlock]

---
 drivers/char/random.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/char/random.c +2 -2

Index: linux-stable/drivers/char/random.c
===================================================================
@@ -810,12 +810,12 @@ static int crng_fast_load(const char *cp
 		p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
 		cp++; crng_init_cnt++; len--;
 	}
+	spin_unlock_irqrestore(&primary_crng.lock, flags);
 	if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
 		crng_init = 1;
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: fast init done\n");
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
 	return 1;
 }

@@ -873,6 +873,7 @@ static void crng_reseed(struct crng_stat
 	}
 	memzero_explicit(&buf, sizeof(buf));
 	crng->init_time = jiffies;
+	spin_unlock_irqrestore(&crng->lock, flags);
 	if (crng == &primary_crng && crng_init < 2) {
 		numa_crng_init();
 		crng_init = 2;

@@ -880,7 +881,6 @@ static void crng_reseed(struct crng_stat
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: crng init done\n");
 	}
-	spin_unlock_irqrestore(&crng->lock, flags);
 }
 
 static inline void maybe_reseed_primary_crng(void)

Greg Kroah-Hartman

author maintainer

2018-04-23 18:12 UTC #90 lore raw

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 102 lines · Salvatore Bonaccorso

Hi
Quoted 27 lines · Ben Hutchings
Quoted 15 lines · Greg Kroah-Hartman
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 8ef35c866f8862df074a49a93b0309725812dea8 upstream.
Until the primary_crng is fully initialized, don't initialize the NUMA crng nodes. Otherwise users of /dev/urandom on NUMA systems before the CRNG is fully initialized can get very bad quality randomness. Of course everyone should move to getrandom(2) where this won't be an issue, but there's a lot of legacy code out there. This related to CVE-2018-1108.
Quoted 5 lines
Reported-by Jann Horn <[email protected]>
Fixes 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc [email protected] # 4.8+
Signed-off-by Theodore Ts'o <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
In 4.9 (and probably older branches too) this leads to a deadlock:
crng_reseed(primary_crng, ...) takes primary_crng.lock -> numa_rcng_init()
-> crng_initialize()
Quoted 7 lines
      -> get_random_bytes()
         -> extract_crng()
            -> _extract_crng(primary_crng, ...) tries to take primary_crng.lock
I think this can be fixed by backporting commit 4a072c71f49b "random: silence compiler warnings and fix race" but I'm not sure whether that depends on other changes.
That is, the following test patch on top of the 4.9-stable review queue seem to resolve the issue. The commit message of the original commit 4a072c71f49b0a0e495ea13423bdb850da73c58c would though not match anymore.
Regards,
Salvatore
From: "Jason A. Donenfeld" <[email protected]>
Date: Thu, 15 Jun 2017 00:45:26 +0200
Subject: random: silence compiler warnings and fix race
Origin: https://git.kernel.org/linus/4a072c71f49b0a0e495ea13423bdb850da73c58c
Odd versions of gcc for the sh4 architecture will actually warn about flags being used while uninitialized, so we set them to zero. Non crazy gccs will optimize that out again, so it doesn't make a difference.
Next, over aggressive gccs could inline the expression that defines use_lock, which could then introduce a race resulting in a lock imbalance. By using READ_ONCE, we prevent that fate. Finally, we make that assignment const, so that gcc can still optimize a nice amount.
Finally, we fix a potential deadlock between primary_crng.lock and batched_entropy_reset_lock, where they could be called in opposite order. Moving the call to invalidate_batched_entropy to outside the lock rectifies this issue.
Fixes b169c13de473a85b3c859bb36216a4cb5f00a54a
Signed-off-by Jason A. Donenfeld <[email protected]>
Signed-off-by Theodore Ts'o <[email protected]>
Cc [email protected]
[Salvatore Bonaccorso: backport to 4.9: context changes, only apply change to address potential deadlock]
---
 drivers/char/random.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-stable/drivers/char/random.c
===================================================================
drivers/char/random.c +2 -1
@@ -810,12 +810,12 @@ static int crng_fast_load(const char *cp
 		p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
 		cp++; crng_init_cnt++; len--;
 	}
+	spin_unlock_irqrestore(&primary_crng.lock, flags);
 	if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
 		crng_init = 1;
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: fast init done\n");
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
 	return 1;
 }
 
@@ -873,6 +873,7 @@ static void crng_reseed(struct crng_stat
 	}
 	memzero_explicit(&buf, sizeof(buf));
 	crng->init_time = jiffies;
+	spin_unlock_irqrestore(&crng->lock, flags);
 	if (crng == &primary_crng && crng_init < 2) {
 		numa_crng_init();
 		crng_init = 2;

drivers/char/random.c static void crng_reseed(struct crng_stat · line 886

Quoted 7 lines

drivers/char/random.c +0 -1

@@ -880,7 +881,6 @@ static void crng_reseed(struct crng_stat
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: crng init done\n");
 	}
-	spin_unlock_irqrestore(&crng->lock, flags);
 }
 
 static inline void maybe_reseed_primary_crng(void)

As this depends on other patches, that are not in 4.9, I don't think this will solve the problem correctly. I've dropped the offending patch for now, hopefully that should be good for the moment.

thanks,

greg k-h

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #91 lore raw

PATCH 76/95 random: crng_reseed() should lock the crng instance that it is modifying

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

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

From: Theodore Ts'o <[email protected]>

commit 0bb29a849a6433b72e249eea7695477b02056e94 upstream.

Reported-by Jann Horn <[email protected]>

Fixes 1e7f583af67b ("random: make /dev/urandom scalable for silly...")

Cc [email protected] # 4.8+

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

drivers/char/random.c +2 -2

@@ -862,7 +862,7 @@ static void crng_reseed(struct crng_stat
 		_crng_backtrack_protect(&primary_crng, buf.block,
 					CHACHA20_KEY_SIZE);
 	}
-	spin_lock_irqsave(&primary_crng.lock, flags);
+	spin_lock_irqsave(&crng->lock, flags);
 	for (i = 0; i < 8; i++) {
 		unsigned long	rv;
 		if (!arch_get_random_seed_long(&rv) &&

@@ -879,7 +879,7 @@ static void crng_reseed(struct crng_stat
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: crng init done\n");
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
+	spin_unlock_irqrestore(&crng->lock, flags);
 }
 
 static inline void maybe_reseed_primary_crng(void)

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #92 lore raw

PATCH 77/95 random: add new ioctl RNDRESEEDCRNG

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

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

From: Theodore Ts'o <[email protected]>

commit d848e5f8e1ebdb227d045db55fe4f825e82965fa upstream.

Add a new ioctl which forces the the crng to be reseeded.

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/char/random.c       |   13 ++++++++++++-
 include/uapi/linux/random.h |    3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

drivers/char/random.c +12 -1

@@ -436,6 +436,7 @@ struct crng_state primary_crng = {
 static int crng_init = 0;
 #define crng_ready() (likely(crng_init > 1))
 static int crng_init_cnt = 0;
+static unsigned long crng_global_init_time = 0;
 #define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)
 static void _extract_crng(struct crng_state *crng,
 			  __u8 out[CHACHA20_BLOCK_SIZE]);

@@ -900,7 +901,8 @@ static void _extract_crng(struct crng_st
 	unsigned long v, flags;
 
 	if (crng_ready() &&
-	    time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL))
+	    (time_after(crng_global_init_time, crng->init_time) ||
+	     time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL)))
 		crng_reseed(crng, crng == &primary_crng ? &input_pool : NULL);
 	spin_lock_irqsave(&crng->lock, flags);
 	if (arch_get_random_long(&v))

@@ -1689,6 +1691,7 @@ static int rand_initialize(void)
 	init_std_data(&input_pool);
 	init_std_data(&blocking_pool);
 	crng_initialize(&primary_crng);
+	crng_global_init_time = jiffies;
 	return 0;
 }
 early_initcall(rand_initialize);

@@ -1862,6 +1865,14 @@ static long random_ioctl(struct file *f,
 		input_pool.entropy_count = 0;
 		blocking_pool.entropy_count = 0;
 		return 0;
+	case RNDRESEEDCRNG:
+		if (!capable(CAP_SYS_ADMIN))
+			return -EPERM;
+		if (crng_init < 2)
+			return -ENODATA;
+		crng_reseed(&primary_crng, NULL);
+		crng_global_init_time = jiffies - 1;
+		return 0;
 	default:
 		return -EINVAL;
 	}

include/uapi/linux/random.h +3 -0

@@ -34,6 +34,9 @@
 /* Clear the entropy pool and associated counters.  (Superuser only.) */
 #define RNDCLEARPOOL	_IO( 'R', 0x06 )
 
+/* Reseed CRNG.  (Superuser only.) */
+#define RNDRESEEDCRNG	_IO( 'R', 0x07 )
+
 struct rand_pool_info {
 	int	entropy_count;
 	int	buf_size;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #93 lore raw

PATCH 78/95 HID: hidraw: Fix crash on HIDIOCGFEATURE with a destroyed device

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

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

From: Rodrigo Rivas Costa <[email protected]>

commit a955358d54695e4ad9f7d6489a7ac4d69a8fc711 upstream.

Doing ioctl(HIDIOCGFEATURE) in a tight loop on a hidraw device and then disconnecting the device, or unloading the driver, can cause a NULL pointer dereference.

When a hidraw device is destroyed it sets 0 to dev->exist. Most functions check 'dev->exist' before doing its work, but hidraw_get_report() was missing that check.

Signed-off-by Rodrigo Rivas Costa <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hidraw.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/hid/hidraw.c +5 -0

@@ -192,6 +192,11 @@ static ssize_t hidraw_get_report(struct
 	int ret = 0, len;
 	unsigned char report_number;
 
+	if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
+		ret = -ENODEV;
+		goto out;
+	}
+
 	dev = hidraw_table[minor]->hid;
 
 	if (!dev->ll_driver->raw_request) {

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #94 lore raw

PATCH 79/95 MIPS: uaccess: Add micromips clobbers to bzero invocation

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

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

From: Matt Redfearn <[email protected]>

commit b3d7e55c3f886493235bfee08e1e5a4a27cbcce8 upstream.

The micromips implementation of bzero additionally clobbers registers t7 & t8. Specify this in the clobbers list when invoking bzero.

Fixes 26c5e07d1478 ("MIPS: microMIPS: Optimise 'memset' core library function.")

Reported-by James Hogan <[email protected]>

Cc Ralf Baechle <[email protected]>

Cc <[email protected]> # 3.10+

Patchwork: https://patchwork.linux-mips.org/patch/19110/

Signed-off-by James Hogan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/include/asm/uaccess.h |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

arch/mips/include/asm/uaccess.h +9 -2

@@ -1257,6 +1257,13 @@ __clear_user(void __user *addr, __kernel
 {
 	__kernel_size_t res;
 
+#ifdef CONFIG_CPU_MICROMIPS
+/* micromips memset / bzero also clobbers t7 & t8 */
+#define bzero_clobbers "$4", "$5", "$6", __UA_t0, __UA_t1, "$15", "$24", "$31"
+#else
+#define bzero_clobbers "$4", "$5", "$6", __UA_t0, __UA_t1, "$31"
+#endif /* CONFIG_CPU_MICROMIPS */
+
 	if (eva_kernel_access()) {
 		__asm__ __volatile__(
 			"move\t$4, %1\n\t"

@@ -1266,7 +1273,7 @@ __clear_user(void __user *addr, __kernel
 			"move\t%0, $6"
 			: "=r" (res)
 			: "r" (addr), "r" (size)
-			: "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
+			: bzero_clobbers);
 	} else {
 		might_fault();
 		__asm__ __volatile__(

@@ -1277,7 +1284,7 @@ __clear_user(void __user *addr, __kernel
 			"move\t%0, $6"
 			: "=r" (res)
 			: "r" (addr), "r" (size)
-			: "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
+			: bzero_clobbers);
 	}
 
 	return res;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #95 lore raw

PATCH 80/95 MIPS: memset.S: EVA & fault support for small_memset

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

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

From: Matt Redfearn <[email protected]>

commit 8a8158c85e1e774a44fbe81106fa41138580dfd1 upstream.

The MIPS kernel memset / bzero implementation includes a small_memset branch which is used when the region to be set is smaller than a long (4 bytes on 32bit, 8 bytes on 64bit). The current small_memset implementation uses a simple store byte loop to write the destination. There are 2 issues with this implementation:

1. When EVA mode is active, user and kernel address spaces may overlap. Currently the use of the sb instruction means kernel mode addressing is always used and an intended write to userspace may actually overwrite some critical kernel data.

2. If the write triggers a page fault, for example by calling __clear_user(NULL, 2), instead of gracefully handling the fault, an OOPS is triggered.

Fix these issues by replacing the sb instruction with the EX() macro, which will emit EVA compatible instuctions as required. Additionally implement a fault fixup for small_memset which sets a2 to the number of bytes that could not be cleared (as defined by __clear_user).

Reported-by Chuanhua Lei <[email protected]>

Cc Ralf Baechle <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/18975/

Signed-off-by James Hogan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/lib/memset.S |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/mips/lib/memset.S +6 -1

@@ -218,7 +218,7 @@
 1:	PTR_ADDIU	a0, 1			/* fill bytewise */
 	R10KCBARRIER(0(ra))
 	bne		t1, a0, 1b
-	sb		a1, -1(a0)
+	 EX(sb, a1, -1(a0), .Lsmall_fixup\@)
 
 2:	jr		ra			/* done */
 	move		a2, zero

@@ -259,6 +259,11 @@
 	jr		ra
 	andi		v1, a2, STORMASK
 
+.Lsmall_fixup\@:
+	PTR_SUBU	a2, t1, a0
+	jr		ra
+	 PTR_ADDIU	a2, 1
+
 	.endm
 
 /*

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #96 lore raw

PATCH 81/95 MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

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

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

From: Matt Redfearn <[email protected]>

commit daf70d89f80c6e1772233da9e020114b1254e7e0 upstream.

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the memset_partial block, the value loaded into a2 on return is meaningless.

The label .Lpartial_fixup\@ is jumped to on page fault. In order to work out how many bytes failed to copy, the exception handler should find how many bytes left in the partial block (andi a2, STORMASK), add that to the partial block end address (a2), and subtract the faulting address to get the remainder. Currently it incorrectly subtracts the partial block start address (t1), which has additionally been clobbered to generate a jump target in memset_partial. Fix this by adding the block end address instead.

This issue was found with the following test code:

      int j, k;
      for (j = 0; j < 512; j++) {
        if ((k = clear_user(NULL, j)) != j) {
           pr_err("clear_user (NULL %d) returned %d\n", j, k);
        }
      }

Which now passes on Creator Ci40 (MIPS32) and Cavium Octeon II (MIPS64).

Cc Ralf Baechle <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/19108/

Signed-off-by James Hogan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/lib/memset.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/lib/memset.S +1 -1

@@ -251,7 +251,7 @@
 	PTR_L		t0, TI_TASK($28)
 	andi		a2, STORMASK
 	LONG_L		t0, THREAD_BUADDR(t0)
-	LONG_ADDU	a2, t1
+	LONG_ADDU	a2, a0
 	jr		ra
 	LONG_SUBU	a2, t0

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #97 lore raw

PATCH 82/95 MIPS: memset.S: Fix clobber of v1 in last_fixup

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

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

From: Matt Redfearn <[email protected]>

commit c96eebf07692e53bf4dd5987510d8b550e793598 upstream.

The label .Llast_fixup\@ is jumped to on page fault within the final byte set loop of memset (on < MIPSR6 architectures). For some reason, in this fault handler, the v1 register is randomly set to a2 & STORMASK. This clobbers v1 for the calling function. This can be observed with the following test code:

static int __init __attribute__((optimize("O0"))) test_clear_user(void) {
register int t asm("v1");
char *test;
int j, k;

  pr_info("\n\n\nTesting clear_user\n");
  test = vmalloc(PAGE_SIZE);

  for (j = 256; j < 512; j++) {
    t = 0xa5a5a5a5;
    if ((k = clear_user(test + PAGE_SIZE - 256, j)) != j - 256) {
        pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 256, j, k);
    }
    if (t != 0xa5a5a5a5) {
       pr_err("v1 was clobbered to 0x%x!\n", t);
    }
  }

return 0;
}
late_initcall(test_clear_user);

Which demonstrates that v1 is indeed clobbered (MIPS64):

Testing clear_user
v1 was clobbered to 0x1!
v1 was clobbered to 0x2!
v1 was clobbered to 0x3!
v1 was clobbered to 0x4!
v1 was clobbered to 0x5!
v1 was clobbered to 0x6!
v1 was clobbered to 0x7!

Since the number of bytes that could not be set is already contained in a2, the andi placing a value in v1 is not necessary and actively harmful in clobbering v1.

Reported-by James Hogan <[email protected]>

Cc Ralf Baechle <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/19109/

Signed-off-by James Hogan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/lib/memset.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/lib/memset.S +1 -1

@@ -257,7 +257,7 @@
 
 .Llast_fixup\@:
 	jr		ra
-	andi		v1, a2, STORMASK
+	 nop
 
 .Lsmall_fixup\@:
 	PTR_SUBU	a2, t1, a0

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #98 lore raw

PATCH 83/95 powerpc/eeh: Fix enabling bridge MMIO windows

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

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

From: Michael Neuling <[email protected]>

commit 13a83eac373c49c0a081cbcd137e79210fe78acd upstream.

On boot we save the configuration space of PCIe bridges. We do this so when we get an EEH event and everything gets reset that we can restore them.

Unfortunately we save this state before we've enabled the MMIO space on the bridges. Hence if we have to reset the bridge when we come back MMIO is not enabled and we end up taking an PE freeze when the driver starts accessing again.

This patch forces the memory/MMIO and bus mastering on when restoring bridges on EEH. Ideally we'd do this correctly by saving the configuration space writes later, but that will have to come later in a larger EEH rewrite. For now we have this simple fix.

The original bug can be triggered on a boston machine by doing:
echo 0x8000000000000000 > /sys/kernel/debug/powerpc/PCI0001/err_injct_outbound
On boston, this PHB has a PCIe switch on it. Without this patch, you'll see two EEH events, 1 expected and 1 the failure we are fixing here. The second EEH event causes the anything under the PHB to disappear (i.e. the i40e eth).

With this patch, only 1 EEH event occurs and devices properly recover.

Fixes 652defed4875 ("powerpc/eeh: Check PCIe link after reset")

Cc [email protected] # v3.11+

Reported-by Pridhiviraj Paidipeddi <[email protected]>

Signed-off-by Michael Neuling <[email protected]>

Acked-by Russell Currey <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/eeh_pe.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/powerpc/kernel/eeh_pe.c +2 -1

@@ -795,7 +795,8 @@ static void eeh_restore_bridge_bars(stru
 	eeh_ops->write_config(pdn, 15*4, 4, edev->config_space[15]);
 
 	/* PCI Command: 0x4 */
-	eeh_ops->write_config(pdn, PCI_COMMAND, 4, edev->config_space[1]);
+	eeh_ops->write_config(pdn, PCI_COMMAND, 4, edev->config_space[1] |
+			      PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
 
 	/* Check the PCIe link is ready */
 	eeh_bridge_check_link(edev);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #99 lore raw

PATCH 84/95 powerpc/lib: Fix off-by-one in alternate feature patching

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

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

From: Michael Ellerman <[email protected]>

commit b8858581febb050688e276b956796bc4a78299ed upstream.

When we patch an alternate feature section, we have to adjust any relative branches that branch out of the alternate section.

But currently we have a bug if we have a branch that points to past the last instruction of the alternate section, eg:

FTR_SECTION_ELSE
1: b 2f

         or      6,6,6

2:
ALT_FTR_SECTION_END(...)
nop

This will result in a relative branch at 1 with a target that equals the end of the alternate section.

That branch does not need adjusting when it's moved to the non-else location. Currently we do adjust it, resulting in a branch that goes off into the link-time location of the else section, which is junk.

The fix is to not patch branches that have a target == end of the alternate section.

Fixes d20fe50a7b3c ("KVM: PPC: Book3S HV: Branch inside feature section")

Fixes 9b1a735de64c ("powerpc: Add logic to patch alternative feature sections")

Cc [email protected] # v2.6.27+

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/lib/feature-fixups.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/lib/feature-fixups.c +1 -1

@@ -55,7 +55,7 @@ static int patch_alt_instruction(unsigne
 		unsigned int *target = (unsigned int *)branch_target(src);
 
 		/* Branch within the section doesn't need translating */
-		if (target < alt_start || target >= alt_end) {
+		if (target < alt_start || target > alt_end) {
 			instr = translate_branch(dest, src);
 			if (!instr)
 				return 1;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #100 lore raw

PATCH 85/95 udf: Fix leak of UTF-16 surrogates into encoded strings

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

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

From: Jan Kara <[email protected]>

commit 44f06ba8297c7e9dfd0e49b40cbe119113cca094 upstream.

OSTA UDF specification does not mention whether the CS0 charset in case of two bytes per character encoding should be treated in UTF-16 or UCS-2. The sample code in the standard does not treat UTF-16 surrogates in any special way but on systems such as Windows which work in UTF-16 internally, filenames would be treated as being in UTF-16 effectively. In Linux it is more difficult to handle characters outside of Base Multilingual plane (beyond 0xffff) as NLS framework works with 2-byte characters only. Just make sure we don't leak UTF-16 surrogates into the resulting string when loading names from the filesystem for now.

CC [email protected] # >= v4.6

Reported-by Mingye Wang <[email protected]>

Signed-off-by Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/udf/unicode.c |    6 ++++++
 1 file changed, 6 insertions(+)

fs/udf/unicode.c +6 -0

@@ -28,6 +28,9 @@
 
 #include "udf_sb.h"
 
+#define SURROGATE_MASK 0xfffff800
+#define SURROGATE_PAIR 0x0000d800
+
 static int udf_uni2char_utf8(wchar_t uni,
 			     unsigned char *out,
 			     int boundlen)

@@ -37,6 +40,9 @@ static int udf_uni2char_utf8(wchar_t uni
 	if (boundlen <= 0)
 		return -ENAMETOOLONG;
 
+	if ((uni & SURROGATE_MASK) == SURROGATE_PAIR)
+		return -EINVAL;
+
 	if (uni < 0x80) {
 		out[u_len++] = (unsigned char)uni;
 	} else if (uni < 0x800) {

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #101 lore raw

PATCH 86/95 jffs2_kill_sb(): deal with failed allocations

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

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

From: Al Viro <[email protected]>

commit c66b23c2840446a82c389e4cb1a12eb2a71fa2e4 upstream.

jffs2_fill_super() might fail to allocate jffs2_sb_info; jffs2_kill_sb() must survive that.

Signed-off-by Al Viro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/jffs2/super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/jffs2/super.c +1 -1

@@ -342,7 +342,7 @@ static void jffs2_put_super (struct supe
 static void jffs2_kill_sb(struct super_block *sb)
 {
 	struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
-	if (!(sb->s_flags & MS_RDONLY))
+	if (c && !(sb->s_flags & MS_RDONLY))
 		jffs2_stop_garbage_collect_thread(c);
 	kill_mtd_super(sb);
 	kfree(c);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #102 lore raw

PATCH 87/95 hypfs_kill_super(): deal with failed allocations

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

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

From: Al Viro <[email protected]>

commit a24cd490739586a7d2da3549a1844e1d7c4f4fc4 upstream.

hypfs_fill_super() might fail to allocate sbi; hypfs_kill_super() should not oops on that.

Signed-off-by Al Viro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/hypfs/inode.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/s390/hypfs/inode.c +1 -1

@@ -318,7 +318,7 @@ static void hypfs_kill_super(struct supe
 
 	if (sb->s_root)
 		hypfs_delete_tree(sb->s_root);
-	if (sb_info->update_file)
+	if (sb_info && sb_info->update_file)
 		hypfs_remove(sb_info->update_file);
 	kfree(sb->s_fs_info);
 	sb->s_fs_info = NULL;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #103 lore raw

PATCH 88/95 orangefs_kill_sb(): deal with allocation failures

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

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

From: Al Viro <[email protected]>

commit 659038428cb43a66e3eff71e2c845c9de3611a98 upstream.

orangefs_fill_sb() might've failed to allocate ORANGEFS_SB(s); don't oops in that case.

Signed-off-by Al Viro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/orangefs/super.c |    5 +++++
 1 file changed, 5 insertions(+)

fs/orangefs/super.c +5 -0

@@ -559,6 +559,11 @@ void orangefs_kill_sb(struct super_block
 	/* provided sb cleanup */
 	kill_anon_super(sb);
 
+	if (!ORANGEFS_SB(sb)) {
+		mutex_lock(&orangefs_request_mutex);
+		mutex_unlock(&orangefs_request_mutex);
+		return;
+	}
 	/*
 	 * issue the unmount to userspace to tell it to remove the
 	 * dynamic mount info it has for this superblock

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #104 lore raw

PATCH 89/95 rpc_pipefs: fix double-dput()

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

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

From: Al Viro <[email protected]>

commit 4a3877c4cedd95543f8726b0a98743ed8db0c0fb upstream.

if we ever hit rpc_gssd_dummy_depopulate() dentry passed to it has refcount equal to 1. __rpc_rmpipe() drops it and dput() done after that hits an already freed dentry.

Signed-off-by Al Viro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/sunrpc/rpc_pipe.c |    1 +
 1 file changed, 1 insertion(+)

net/sunrpc/rpc_pipe.c +1 -0

@@ -1375,6 +1375,7 @@ rpc_gssd_dummy_depopulate(struct dentry
 	struct dentry *clnt_dir = pipe_dentry->d_parent;
 	struct dentry *gssd_dir = clnt_dir->d_parent;
 
+	dget(pipe_dentry);
 	__rpc_rmpipe(d_inode(clnt_dir), pipe_dentry);
 	__rpc_depopulate(clnt_dir, gssd_dummy_info_file, 0, 1);
 	__rpc_depopulate(gssd_dir, gssd_dummy_clnt_dir, 0, 1);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:53 UTC #105 lore raw

PATCH 90/95 Dont leak MNT_INTERNAL away from internal mounts

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

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

From: Al Viro <[email protected]>

commit 16a34adb9392b2fe4195267475ab5b472e55292c upstream.

We want it only for the stuff created by SB_KERNMOUNT mounts, *not* for their copies. As it is, creating a deep stack of bindings of /proc/*/ns/* somewhere in a new namespace and exiting yields a stack overflow.

Reported-by Alexander Aring <[email protected]>

Bisected-by Kirill Tkhai <[email protected]>

Tested-by Kirill Tkhai <[email protected]>

Tested-by Alexander Aring <[email protected]>

Signed-off-by Al Viro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/namespace.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/namespace.c +2 -1

@@ -1033,7 +1033,8 @@ static struct mount *clone_mnt(struct mo
 			goto out_free;
 	}
 
-	mnt->mnt.mnt_flags = old->mnt.mnt_flags & ~(MNT_WRITE_HOLD|MNT_MARKED);
+	mnt->mnt.mnt_flags = old->mnt.mnt_flags;
+	mnt->mnt.mnt_flags &= ~(MNT_WRITE_HOLD|MNT_MARKED|MNT_INTERNAL);
 	/* Don't allow unprivileged users to change mount flags */
 	if (flag & CL_UNPRIVILEGED) {
 		mnt->mnt.mnt_flags |= MNT_LOCK_ATIME;

Greg Kroah-Hartman

author maintainer

2018-04-22 13:54 UTC #106 lore raw

PATCH 91/95 autofs: mount point create should honour passed in mode

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

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

From: Ian Kent <[email protected]>

commit 1e6306652ba18723015d1b4967fe9de55f042499 upstream.

The autofs file system mkdir inode operation blindly sets the created directory mode to S_IFDIR | 0555, ingoring the passed in mode, which can cause selinux dac_override denials.

But the function also checks if the caller is the daemon (as no-one else should be able to do anything here) so there's no point in not honouring the passed in mode, allowing the daemon to set appropriate mode when required.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ian Kent <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/autofs4/root.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/autofs4/root.c +1 -1

@@ -746,7 +746,7 @@ static int autofs4_dir_mkdir(struct inod
 
 	autofs4_del_active(dentry);
 
-	inode = autofs4_get_inode(dir->i_sb, S_IFDIR | 0555);
+	inode = autofs4_get_inode(dir->i_sb, S_IFDIR | mode);
 	if (!inode)
 		return -ENOMEM;
 	d_add(dentry, inode);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:54 UTC #107 lore raw

PATCH 92/95 mm/filemap.c: fix NULL pointer in page_cache_tree_insert()

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

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

From: Matthew Wilcox <[email protected]>

commit abc1be13fd113ddef5e2d807a466286b864caed3 upstream.

f2fs specifies the __GFP_ZERO flag for allocating some of its pages. Unfortunately, the page cache also uses the mapping's GFP flags for allocating radix tree nodes. It always masked off the __GFP_HIGHMEM flag, and masks off __GFP_ZERO in some paths, but not all. That causes radix tree nodes to be allocated with a NULL list_head, which causes backtraces like:

  __list_del_entry+0x30/0xd0
  list_lru_del+0xac/0x1ac
  page_cache_tree_insert+0xd8/0x110

The __GFP_DMA and __GFP_DMA32 flags would also be able to sneak through if they are ever used. Fix them all by using GFP_RECLAIM_MASK at the innermost location, and remove it from earlier in the callchain.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 449dd6984d0e ("mm: keep page cache radix tree nodes in check")

Signed-off-by Matthew Wilcox <[email protected]>

Reported-by Chris Fries <[email protected]>

Debugged-by Minchan Kim <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Acked-by Michal Hocko <[email protected]>

Reviewed-by Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 mm/filemap.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

mm/filemap.c +4 -5

@@ -616,7 +616,7 @@ int replace_page_cache_page(struct page
 	VM_BUG_ON_PAGE(!PageLocked(new), new);
 	VM_BUG_ON_PAGE(new->mapping, new);
 
-	error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
+	error = radix_tree_preload(gfp_mask & GFP_RECLAIM_MASK);
 	if (!error) {
 		struct address_space *mapping = old->mapping;
 		void (*freepage)(struct page *);

@@ -672,7 +672,7 @@ static int __add_to_page_cache_locked(st
 			return error;
 	}
 
-	error = radix_tree_maybe_preload(gfp_mask & ~__GFP_HIGHMEM);
+	error = radix_tree_maybe_preload(gfp_mask & GFP_RECLAIM_MASK);
 	if (error) {
 		if (!huge)
 			mem_cgroup_cancel_charge(page, memcg, false);

@@ -1247,8 +1247,7 @@ no_page:
 		if (fgp_flags & FGP_ACCESSED)
 			__SetPageReferenced(page);
 
-		err = add_to_page_cache_lru(page, mapping, offset,
-				gfp_mask & GFP_RECLAIM_MASK);
+		err = add_to_page_cache_lru(page, mapping, offset, gfp_mask);
 		if (unlikely(err)) {
 			put_page(page);
 			page = NULL;

@@ -1996,7 +1995,7 @@ static int page_cache_read(struct file *
 		if (!page)
 			return -ENOMEM;
 
-		ret = add_to_page_cache_lru(page, mapping, offset, gfp_mask & GFP_KERNEL);
+		ret = add_to_page_cache_lru(page, mapping, offset, gfp_mask);
 		if (ret == 0)
 			ret = mapping->a_ops->readpage(file, page);
 		else if (ret == -EEXIST)

Greg Kroah-Hartman

author maintainer

2018-04-22 14:15 UTC #108 lore raw

PATCH 93/95 fanotify: fix logic of events on child

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

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

From: Amir Goldstein <[email protected]>

commit 54a307ba8d3cd00a3902337ffaae28f436eeb1a4 upstream.

When event on child inodes are sent to the parent inode mark and parent inode mark was not marked with FAN_EVENT_ON_CHILD, the event will not be delivered to the listener process. However, if the same process also has a mount mark, the event to the parent inode will be delivered regadless of the mount mark mask.

This behavior is incorrect in the case where the mount mark mask does not contain the specific event type. For example, the process adds a mark on a directory with mask FAN_MODIFY (without FAN_EVENT_ON_CHILD) and a mount mark with mask FAN_CLOSE_NOWRITE (without FAN_ONDIR).

A modify event on a file inside that directory (and inside that mount) should not create a FAN_MODIFY event, because neither of the marks requested to get that event on the file.

Fixes 1968f5eed54c ("fanotify: use both marks when possible")

Cc stable <[email protected]>

Signed-off-by Amir Goldstein <[email protected]>

Signed-off-by Jan Kara <[email protected]>

[natechancellor: Fix small conflict due to lack of 3cd5eca8d7a2f]

Signed-off-by Nathan Chancellor <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/notify/fanotify/fanotify.c |   34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

fs/notify/fanotify/fanotify.c +15 ~~-19~~

@@ -92,7 +92,7 @@ static bool fanotify_should_send_event(s
 				       u32 event_mask,
 				       void *data, int data_type)
 {
-	__u32 marks_mask, marks_ignored_mask;
+	__u32 marks_mask = 0, marks_ignored_mask = 0;
 	struct path *path = data;
 
 	pr_debug("%s: inode_mark=%p vfsmnt_mark=%p mask=%x data=%p"

@@ -108,24 +108,20 @@ static bool fanotify_should_send_event(s
 	    !d_can_lookup(path->dentry))
 		return false;
 
-	if (inode_mark && vfsmnt_mark) {
-		marks_mask = (vfsmnt_mark->mask | inode_mark->mask);
-		marks_ignored_mask = (vfsmnt_mark->ignored_mask | inode_mark->ignored_mask);
-	} else if (inode_mark) {
-		/*
-		 * if the event is for a child and this inode doesn't care about
-		 * events on the child, don't send it!
-		 */
-		if ((event_mask & FS_EVENT_ON_CHILD) &&
-		    !(inode_mark->mask & FS_EVENT_ON_CHILD))
-			return false;
-		marks_mask = inode_mark->mask;
-		marks_ignored_mask = inode_mark->ignored_mask;
-	} else if (vfsmnt_mark) {
-		marks_mask = vfsmnt_mark->mask;
-		marks_ignored_mask = vfsmnt_mark->ignored_mask;
-	} else {
-		BUG();
+	/*
+	 * if the event is for a child and this inode doesn't care about
+	 * events on the child, don't send it!
+	 */
+	if (inode_mark &&
+	    (!(event_mask & FS_EVENT_ON_CHILD) ||
+	     (inode_mark->mask & FS_EVENT_ON_CHILD))) {
+		marks_mask |= inode_mark->mask;
+		marks_ignored_mask |= inode_mark->ignored_mask;
+	}
+
+	if (vfsmnt_mark) {
+		marks_mask |= vfsmnt_mark->mask;
+		marks_ignored_mask |= vfsmnt_mark->ignored_mask;
 	}
 
 	if (d_is_dir(path->dentry) &&

Greg Kroah-Hartman

author maintainer

2018-04-22 13:54 UTC #109 lore raw

PATCH 94/95 writeback: safer lock nesting

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

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

From: Greg Thelen <[email protected]>

commit 2e898e4c0a3897ccd434adac5abb8330194f527b upstream.

lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if the page's memcg is undergoing move accounting, which occurs when a process leaves its memcg for a new one that has memory.move_charge_at_immigrate set.

unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if the given inode is switching writeback domains. Switches occur when enough writes are issued from a new domain.

This existing pattern is thus suspicious:

    lock_page_memcg(page);
    unlocked_inode_to_wb_begin(inode, &locked);
    ...
    unlocked_inode_to_wb_end(inode, locked);
    unlock_page_memcg(page);

If both inode switch and process memcg migration are both in-flight then unlocked_inode_to_wb_end() will unconditionally enable interrupts while still holding the lock_page_memcg() irq spinlock. This suggests the possibility of deadlock if an interrupt occurs before unlock_page_memcg().

truncate
__cancel_dirty_page
lock_page_memcg
unlocked_inode_to_wb_begin unlocked_inode_to_wb_end
<interrupts mistakenly enabled>
<interrupt> end_page_writeback test_clear_page_writeback lock_page_memcg <deadlock>
unlock_page_memcg

Due to configuration limitations this deadlock is not currently possible because we don't mix cgroup writeback (a cgroupv2 feature) and memory.move_charge_at_immigrate (a cgroupv1 feature).

If the kernel is hacked to always claim inode switching and memcg moving_account, then this script triggers lockup in less than a minute:

cd /mnt/cgroup/memory
mkdir a b
echo 1 > a/memory.move_charge_at_immigrate
echo 1 > b/memory.move_charge_at_immigrate
(
echo $BASHPID > a/cgroup.procs
while true; do
dd if=/dev/zero of=/mnt/big bs=1M count=256
done
) &
while true; do
sync
done &
sleep 1h &
SLEEP=$!
while true; do
echo $SLEEP > a/cgroup.procs
echo $SLEEP > b/cgroup.procs
done

The deadlock does not seem possible, so it's debatable if there's any reason to modify the kernel. I suggest we should to prevent future surprises. And Wang Long said "this deadlock occurs three times in our environment", so there's more reason to apply this, even to stable. Stable 4.4 has minor conflicts applying this patch. For a clean 4.4 patch see "[PATCH for-4.4] writeback: safer lock nesting"
https://lkml.org/lkml/2018/4/11/146

Wang Long said "this deadlock occurs three times in our environment"

[[email protected]: v4]

Link http://lkml.kernel.org/r/[email protected] open here

[[email protected]: comment tweaks, struct initialization simplification]

Change-Id Ibb773e8045852978f6207074491d262f1b3fb613

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates")

Signed-off-by Greg Thelen <[email protected]>

Reported-by Wang Long <[email protected]>

Acked-by Wang Long <[email protected]>

Acked-by Michal Hocko <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc Tejun Heo <[email protected]>

Cc Nicholas Piggin <[email protected]>

Cc <[email protected]> [v4.2+]

[natechancellor: Adjust context due to lack of b93b016313b3b]

Signed-off-by Nathan Chancellor <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/fs-writeback.c                |    7 ++++---
 include/linux/backing-dev-defs.h |    5 +++++
 include/linux/backing-dev.h      |   30 ++++++++++++++++--------------
 mm/page-writeback.c              |   18 +++++++++---------
 4 files changed, 34 insertions(+), 26 deletions(-)

fs/fs-writeback.c +4 -3

@@ -745,11 +745,12 @@ int inode_congested(struct inode *inode,
 	 */
 	if (inode && inode_to_wb_is_valid(inode)) {
 		struct bdi_writeback *wb;
-		bool locked, congested;
+		struct wb_lock_cookie lock_cookie = {};
+		bool congested;
 
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &lock_cookie);
 		congested = wb_congested(wb, cong_bits);
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &lock_cookie);
 		return congested;
 	}

include/linux/backing-dev-defs.h +5 -0

@@ -191,6 +191,11 @@ static inline void set_bdi_congested(str
 	set_wb_congested(bdi->wb.congested, sync);
 }
 
+struct wb_lock_cookie {
+	bool locked;
+	unsigned long flags;
+};
+
 #ifdef CONFIG_CGROUP_WRITEBACK
 
 /**

include/linux/backing-dev.h +16 ~~-14~~

@@ -366,7 +366,7 @@ static inline struct bdi_writeback *inod
 /**
  * unlocked_inode_to_wb_begin - begin unlocked inode wb access transaction
  * @inode: target inode
- * @lockedp: temp bool output param, to be passed to the end function
+ * @cookie: output param, to be passed to the end function
  *
  * The caller wants to access the wb associated with @inode but isn't
  * holding inode->i_lock, mapping->tree_lock or wb->list_lock.  This

@@ -374,12 +374,12 @@ static inline struct bdi_writeback *inod
  * association doesn't change until the transaction is finished with
  * unlocked_inode_to_wb_end().
  *
- * The caller must call unlocked_inode_to_wb_end() with *@lockdep
- * afterwards and can't sleep during transaction.  IRQ may or may not be
- * disabled on return.
+ * The caller must call unlocked_inode_to_wb_end() with *@cookie afterwards and
+ * can't sleep during the transaction.  IRQs may or may not be disabled on
+ * return.
  */
 static inline struct bdi_writeback *
-unlocked_inode_to_wb_begin(struct inode *inode, bool *lockedp)
+unlocked_inode_to_wb_begin(struct inode *inode, struct wb_lock_cookie *cookie)
 {
 	rcu_read_lock();

@@ -387,10 +387,10 @@ unlocked_inode_to_wb_begin(struct inode
 	 * Paired with store_release in inode_switch_wb_work_fn() and
 	 * ensures that we see the new wb if we see cleared I_WB_SWITCH.
 	 */
-	*lockedp = smp_load_acquire(&inode->i_state) & I_WB_SWITCH;
+	cookie->locked = smp_load_acquire(&inode->i_state) & I_WB_SWITCH;
 
-	if (unlikely(*lockedp))
-		spin_lock_irq(&inode->i_mapping->tree_lock);
+	if (unlikely(cookie->locked))
+		spin_lock_irqsave(&inode->i_mapping->tree_lock, cookie->flags);
 
 	/*
 	 * Protected by either !I_WB_SWITCH + rcu_read_lock() or tree_lock.

@@ -402,12 +402,13 @@ unlocked_inode_to_wb_begin(struct inode
 /**
  * unlocked_inode_to_wb_end - end inode wb access transaction
  * @inode: target inode
- * @locked: *@lockedp from unlocked_inode_to_wb_begin()
+ * @cookie: @cookie from unlocked_inode_to_wb_begin()
  */
-static inline void unlocked_inode_to_wb_end(struct inode *inode, bool locked)
+static inline void unlocked_inode_to_wb_end(struct inode *inode,
+					    struct wb_lock_cookie *cookie)
 {
-	if (unlikely(locked))
-		spin_unlock_irq(&inode->i_mapping->tree_lock);
+	if (unlikely(cookie->locked))
+		spin_unlock_irqrestore(&inode->i_mapping->tree_lock, cookie->flags);
 
 	rcu_read_unlock();
 }

@@ -454,12 +455,13 @@ static inline struct bdi_writeback *inod
 }
 
 static inline struct bdi_writeback *
-unlocked_inode_to_wb_begin(struct inode *inode, bool *lockedp)
+unlocked_inode_to_wb_begin(struct inode *inode, struct wb_lock_cookie *cookie)
 {
 	return inode_to_wb(inode);
 }
 
-static inline void unlocked_inode_to_wb_end(struct inode *inode, bool locked)
+static inline void unlocked_inode_to_wb_end(struct inode *inode,
+					    struct wb_lock_cookie *cookie)
 {
 }

mm/page-writeback.c +9 -9

@@ -2506,13 +2506,13 @@ void account_page_redirty(struct page *p
 	if (mapping && mapping_cap_account_dirty(mapping)) {
 		struct inode *inode = mapping->host;
 		struct bdi_writeback *wb;
-		bool locked;
+		struct wb_lock_cookie cookie = {};
 
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 		current->nr_dirtied--;
 		dec_node_page_state(page, NR_DIRTIED);
 		dec_wb_stat(wb, WB_DIRTIED);
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &cookie);
 	}
 }
 EXPORT_SYMBOL(account_page_redirty);

@@ -2618,15 +2618,15 @@ void cancel_dirty_page(struct page *page
 	if (mapping_cap_account_dirty(mapping)) {
 		struct inode *inode = mapping->host;
 		struct bdi_writeback *wb;
-		bool locked;
+		struct wb_lock_cookie cookie = {};
 
 		lock_page_memcg(page);
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 
 		if (TestClearPageDirty(page))
 			account_page_cleaned(page, mapping, wb);
 
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &cookie);
 		unlock_page_memcg(page);
 	} else {
 		ClearPageDirty(page);

@@ -2658,7 +2658,7 @@ int clear_page_dirty_for_io(struct page
 	if (mapping && mapping_cap_account_dirty(mapping)) {
 		struct inode *inode = mapping->host;
 		struct bdi_writeback *wb;
-		bool locked;
+		struct wb_lock_cookie cookie = {};
 
 		/*
 		 * Yes, Virginia, this is indeed insane.

@@ -2695,7 +2695,7 @@ int clear_page_dirty_for_io(struct page
 		 * always locked coming in here, so we get the desired
 		 * exclusion.
 		 */
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 		if (TestClearPageDirty(page)) {
 			mem_cgroup_dec_page_stat(page, MEM_CGROUP_STAT_DIRTY);
 			dec_node_page_state(page, NR_FILE_DIRTY);

@@ -2703,7 +2703,7 @@ int clear_page_dirty_for_io(struct page
 			dec_wb_stat(wb, WB_RECLAIMABLE);
 			ret = 1;
 		}
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &cookie);
 		return ret;
 	}
 	return TestClearPageDirty(page);

Greg Kroah-Hartman

author maintainer

2018-04-22 13:54 UTC #110 lore raw

PATCH 95/95 block/mq: fix potential deadlock during cpu hotplug

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

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

From: Wanpeng Li <[email protected]>

commit 51d638b1f56a0bfd9219800620994794a1a2b219 upstream.

This can be triggered by hot-unplug one cpu.

======================================================
[ INFO: possible circular locking dependency detected ]
4.11.0+ #17 Not tainted
-------------------------------------------------------
step_after_susp/2640 is trying to acquire lock:
(all_q_mutex){+.+...}, at: [<ffffffffb33f95b8>] blk_mq_queue_reinit_work+0x18/0x110

but task is already holding lock:
(cpu_hotplug.lock){+.+.+.}, at: [<ffffffffb306d04f>] cpu_hotplug_begin+0x7f/0xe0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (cpu_hotplug.lock){+.+.+.}:

        lock_acquire+0x11c/0x230
        __mutex_lock+0x92/0x990
        mutex_lock_nested+0x1b/0x20
        get_online_cpus+0x64/0x80
        blk_mq_init_allocated_queue+0x3a0/0x4e0
        blk_mq_init_queue+0x3a/0x60
        loop_add+0xe5/0x280
        loop_init+0x124/0x177
        do_one_initcall+0x53/0x1c0
        kernel_init_freeable+0x1e3/0x27f
        kernel_init+0xe/0x100
        ret_from_fork+0x31/0x40

-> #0 (all_q_mutex){+.+...}:

        __lock_acquire+0x189a/0x18a0
        lock_acquire+0x11c/0x230
        __mutex_lock+0x92/0x990
        mutex_lock_nested+0x1b/0x20
        blk_mq_queue_reinit_work+0x18/0x110
        blk_mq_queue_reinit_dead+0x1c/0x20
        cpuhp_invoke_callback+0x1f2/0x810
        cpuhp_down_callbacks+0x42/0x80
        _cpu_down+0xb2/0xe0
        freeze_secondary_cpus+0xb6/0x390
        suspend_devices_and_enter+0x3b3/0xa40
        pm_suspend+0x129/0x490
        state_store+0x82/0xf0
        kobj_attr_store+0xf/0x20
        sysfs_kf_write+0x45/0x60
        kernfs_fop_write+0x135/0x1c0
        __vfs_write+0x37/0x160
        vfs_write+0xcd/0x1d0
        SyS_write+0x58/0xc0
        do_syscall_64+0x8f/0x710
        return_from_SYSCALL_64+0x0/0x7a

other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(cpu_hotplug.lock);
                                lock(all_q_mutex);
                                lock(cpu_hotplug.lock);

lock(all_q_mutex);

*** DEADLOCK ***

8 locks held by step_after_susp/2640:

  #0:  (sb_writers#6){.+.+.+}, at: [<ffffffffb3244aed>] vfs_write+0x1ad/0x1d0
  #1:  (&of->mutex){+.+.+.}, at: [<ffffffffb32d3a51>] kernfs_fop_write+0x101/0x1c0
  #2:  (s_active#166){.+.+.+}, at: [<ffffffffb32d3a59>] kernfs_fop_write+0x109/0x1c0
  #3:  (pm_mutex){+.+...}, at: [<ffffffffb30d2ecd>] pm_suspend+0x21d/0x490
  #4:  (acpi_scan_lock){+.+.+.}, at: [<ffffffffb34dc3d7>] acpi_scan_lock_acquire+0x17/0x20
  #5:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffffb306d6d7>] freeze_secondary_cpus+0x27/0x390
  #6:  (cpu_hotplug.dep_map){++++++}, at: [<ffffffffb306cfd5>] cpu_hotplug_begin+0x5/0xe0
  #7:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffffb306d04f>] cpu_hotplug_begin+0x7f/0xe0

 stack backtrace:
 CPU: 3 PID: 2640 Comm: step_after_susp Not tainted 4.11.0+ #17
 Hardware name: Dell Inc. OptiPlex 7040/0JCTF8, BIOS 1.4.9 09/12/2016
 Call Trace:
  dump_stack+0x99/0xce
  print_circular_bug+0x1fa/0x270
  __lock_acquire+0x189a/0x18a0
  lock_acquire+0x11c/0x230
  ? lock_acquire+0x11c/0x230
  ? blk_mq_queue_reinit_work+0x18/0x110
  ? blk_mq_queue_reinit_work+0x18/0x110
  __mutex_lock+0x92/0x990
  ? blk_mq_queue_reinit_work+0x18/0x110
  ? kmem_cache_free+0x2cb/0x330
  ? anon_transport_class_unregister+0x20/0x20
  ? blk_mq_queue_reinit_work+0x110/0x110
  mutex_lock_nested+0x1b/0x20
  ? mutex_lock_nested+0x1b/0x20
  blk_mq_queue_reinit_work+0x18/0x110
  blk_mq_queue_reinit_dead+0x1c/0x20
  cpuhp_invoke_callback+0x1f2/0x810
  ? __flow_cache_shrink+0x160/0x160
  cpuhp_down_callbacks+0x42/0x80
  _cpu_down+0xb2/0xe0
  freeze_secondary_cpus+0xb6/0x390
  suspend_devices_and_enter+0x3b3/0xa40
  ? rcu_read_lock_sched_held+0x79/0x80
  pm_suspend+0x129/0x490
  state_store+0x82/0xf0
  kobj_attr_store+0xf/0x20
  sysfs_kf_write+0x45/0x60
  kernfs_fop_write+0x135/0x1c0
  __vfs_write+0x37/0x160
  ? rcu_read_lock_sched_held+0x79/0x80
  ? rcu_sync_lockdep_assert+0x2f/0x60
  ? __sb_start_write+0xd9/0x1c0
  ? vfs_write+0x1ad/0x1d0
  vfs_write+0xcd/0x1d0
  SyS_write+0x58/0xc0
  ? rcu_read_lock_sched_held+0x79/0x80
  do_syscall_64+0x8f/0x710
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  entry_SYSCALL64_slow_path+0x25/0x25

The cpu hotplug path will hold cpu_hotplug.lock and then reinit all exiting queues for blk mq w/ all_q_mutex, however, blk_mq_init_allocated_queue() will contend these two locks in the inversion order. This is due to commit eabe06595d62 (blk/mq: Cure cpu hotplug lock inversion), it fixes a cpu hotplug lock inversion issue because of hotplug rework, however the hotplug rework is still work-in-progress and lives in a -tip branch and mainline cannot yet trigger that splat. The commit breaks the linus's tree in the merge window, so this patch reverts the lock order and avoids to splat linus's tree.

Cc Jens Axboe <[email protected]>

Cc Peter Zijlstra (Intel) <[email protected]>

Cc Thomas Gleixner <[email protected]>

Signed-off-by Wanpeng Li <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Cc Thierry Escande <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 block/blk-mq.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

block/blk-mq.c +2 -2

@@ -2019,15 +2019,15 @@ struct request_queue *blk_mq_init_alloca
 
 	blk_mq_init_cpu_queues(q, set->nr_hw_queues);
 
-	mutex_lock(&all_q_mutex);
 	get_online_cpus();
+	mutex_lock(&all_q_mutex);
 
 	list_add_tail(&q->all_q_node, &all_q_list);
 	blk_mq_add_queue_tag_set(set, q);
 	blk_mq_map_swqueue(q, cpu_online_mask);
 
-	put_online_cpus();
 	mutex_unlock(&all_q_mutex);
+	put_online_cpus();
 
 	return q;

Naresh Kamboju

2018-04-23 09:54 UTC #111 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 8 lines

        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.96-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.9.y
and the diffstat can be found below.
thanks,
greg k-h

Regression detected on arm64 devices Hikey and Juno. Boot pass on arm64 dragonboard 410c board and qemu arm64.

I have started bisecting this problem.

Boot log:
------------

[    5.521472] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    5.526923] ------------[ cut here ]------------
[    5.526940] WARNING: CPU: 0 PID: 1331 at /srv/oe/build/tmp-rpb-glibc/

work-shared/hikey/kernel-source/kernel/locking/lockdep.c:2879 lockdep_trace_alloc+0xc0/0xc8

[    5.526943] Modules linked in:
[    5.526946]  fuse
[    5.526958] CPU: 0 PID: 1331 Comm: systemd-cgroups Not tainted 4.9.96-rc1 #1
[    5.526960] Hardware name: HiKey Development Board (DT)
[    5.526963] task: ffff800074241600 task.stack: ffff8000739e8000
[    5.526968] PC is at lockdep_trace_alloc+0xc0/0xc8
[    5.526973] LR is at lockdep_trace_alloc+0xc0/0xc8

Details log can be found at,
https://lkft.validation.linaro.org/scheduler/job/192779#L3095
and
4.9.96-rc2
https://lkft.validation.linaro.org/scheduler/job/193871

Best regards
Naresh Kamboju

Guenter Roeck

2018-04-23 16:53 UTC #112 lore raw

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.

For v4.9.95-96-g54c571b:

Build results:

	total: 146 pass: 146 fail: 0
Qemu test results:
	total: 137 pass: 137 fail: 0

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

Guenter

Naresh Kamboju

2018-04-23 16:53 UTC #113 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 8 lines

        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.96-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.9.y
and the diffstat can be found below.
thanks,
greg k-h

Regression detected on arm64 devices Hikey and Juno.

Here is the list of bad commit patches to be reverted.
git bisect found first bad commit as "3"
but reverting 3 patch failed.
so i have to revert all four patches and boot test and the boot PASS on hikey.

1)
Theodore Ts'o <[email protected]>
random: add new ioctl RNDRESEEDCRNG
2)
Theodore Ts'o <[email protected]>
random: crng_reseed() should lock the crng instance that it is modifying
3)
Theodore Ts'o <[email protected]>
random: set up the NUMA crng instances after the CRNG is fully initialized
4)
Theodore Ts'o <[email protected]>
random: fix crng_ready() test

Additional details,
------------------------
Boot failed log details log can be found at,
https://lkft.validation.linaro.org/scheduler/job/193871#L3120

[    5.789114] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    5.794551] ------------[ cut here ]------------
[    5.799216] WARNING: CPU: 0 PID: 0 at /srv/oe/build/tmp-rpb-glibc/
work-shared/hikey/kernel-source/kernel/locking/lockdep.c:2879
lockdep_trace_alloc+0xc0/0xc8
[    5.813339] Modules linked in: fuse
[    5.816850]
[    5.818351] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.96-rc2 #1
[    5.824630] Hardware name: HiKey Development Board (DT)
[    5.829866] task: ffff000009104680 task.stack: ffff0000090f0000
[    5.835803] PC is at lockdep_trace_alloc+0xc0/0xc8
[    5.840605] LR is at lockdep_trace_alloc+0xc0/0xc8
[    5.845405] pc : [<ffff000008133778>] lr : [<ffff000008133778>]
pstate: 600001c5
[    5.852820] sp : ffff800077f02d60
[    5.856141] x29: ffff800077f02d60 x28: 0000000000007ffe
[    5.861472] x27: 0000000000004000 x26: ffff0000090fa508
[    5.866804] x25: 00000000000001c0 x24: ffff0000091ed000
[    5.872136] x23: ffff800005f03c80 x22: ffff00000867d864
[    5.877467] x21: 0000000000000008 x20: 00000000024088c0
[    5.882798] x19: 00000000000001c0 x18: 0000000000000010
[    5.888129] x17: 0000000000000007 x16: 0000000000000001
[    5.893460] x15: 0000000000000006 x14: ffff000089ebb12f
[    5.898791] x13: ffff000009ebb13d x12: ffff000009cb9930
[    5.904122] x11: ffff800077f02b40 x10: 000000000000017f
[    5.909454] x9 : 00000000ffffffd0 x8 : 0000000000000002
[    5.914785] x7 : ffff0000090f0000 x6 : ffff00000813de38
[    5.920117] x5 : 0000000000000000 x4 : 0000000000000001
[    5.925449] x3 : 0000000000000002 x2 : 000000000000000

Best regards
Naresh Kamboju

Greg Kroah-Hartman

author maintainer

2018-04-23 16:57 UTC #114 lore raw

Quoted 27 lines · Naresh Kamboju

Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.96-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
Regression detected on arm64 devices Hikey and Juno.
Here is the list of bad commit patches to be reverted.
git bisect found first bad commit as "3"
but reverting 3 patch failed.
so i have to revert all four patches and boot test and the boot PASS on hikey.

Quoted 9 lines

1)
Theodore Ts'o <[email protected]>
random: add new ioctl RNDRESEEDCRNG
2)
Theodore Ts'o <[email protected]>
random: crng_reseed() should lock the crng instance that it is modifying
3)
Theodore Ts'o <[email protected]>
random: set up the NUMA crng instances after the CRNG is fully initialized

This is the one I need to revert anyway.

Let me see if I can just drop that one and do a -rc3. Give me a few hours...

greg k-h

Greg Kroah-Hartman

author maintainer

2018-04-23 18:01 UTC #115 lore raw

Quoted 38 lines · Greg Kroah-Hartman

Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.96-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
Regression detected on arm64 devices Hikey and Juno.
Here is the list of bad commit patches to be reverted.
git bisect found first bad commit as "3"
but reverting 3 patch failed.
so i have to revert all four patches and boot test and the boot PASS on hikey.
Quoted 9 lines
1)
Theodore Ts'o <[email protected]>
random: add new ioctl RNDRESEEDCRNG
2)
Theodore Ts'o <[email protected]>
random: crng_reseed() should lock the crng instance that it is modifying
3)
Theodore Ts'o <[email protected]>
random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 4 lines

This is the one I need to revert anyway.
Let me see if I can just drop that one and do a -rc3. Give me a few hours...

Ok, I've dropped just patch 3 from 4.16.y, 4.14.y and 4.9.y and pushed out -rc3 versions of all of these. Let me know if that works or not for you.

thanks,

greg k-h

Dan Rue

2018-04-23 22:25 UTC #116 lore raw

Quoted 39 lines · Greg Kroah-Hartman

Quoted 38 lines · Greg Kroah-Hartman
Quoted 36 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.96-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
Regression detected on arm64 devices Hikey and Juno.
Here is the list of bad commit patches to be reverted.
git bisect found first bad commit as "3"
but reverting 3 patch failed.
so i have to revert all four patches and boot test and the boot PASS on hikey.
1)
Theodore Ts'o <[email protected]>
random: add new ioctl RNDRESEEDCRNG
2)
Theodore Ts'o <[email protected]>
random: crng_reseed() should lock the crng instance that it is modifying
3)
Theodore Ts'o <[email protected]>
random: set up the NUMA crng instances after the CRNG is fully initialized

Quoted 8 lines

Quoted 4 lines
This is the one I need to revert anyway.
Let me see if I can just drop that one and do a -rc3. Give me a few hours...
Ok, I've dropped just patch 3 from 4.16.y, 4.14.y and 4.9.y and pushed out -rc3 versions of all of these. Let me know if that works or not for you.

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

I made a few comments inline regarding the reported failures. Also, as this report is pushing 200 lines now with all of our tests and environments (about 8*22 test runs), I'm planning on making some changes in the next few weeks to make it more concise and useful. Any suggestions or feature requests are most welcome.

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

kernel: 4.9.96-rc3
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 8617c15e22fdfa0451d34bc07fb3f0fc85fbb310
git describe: v4.9.94-164-g8617c15e22fd
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.94-164-g8617c15e22fd

No regressions (compared to build v4.9.94-165-g54c571bb567c)

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

dragonboard-410c
* boot - pass: 20,
* kselftest - skip: 27, pass: 35, fail: 4
^ kselftest failures caused by kselftest upgrade to 4.16 (in all cases in this report)
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 19, fail: 2
^ this one is an intermittent failure specific to db410c.

* 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 - skip: 135, pass: 1015,
* ltp-timers-tests - pass: 13,

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 24, pass: 38, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* 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 - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 136, pass: 1014,
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 24, pass: 38, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* 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: 9,
* ltp-math-tests - pass: 11,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 135, pass: 1015,
* ltp-timers-tests - pass: 13,

qemu_arm
* boot - pass: 10, fail: 10
^ infrastructure issues
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 58,
* ltp-fs_bind-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-securebits-tests - pass: 4,
* ltp-timers-tests - pass: 13,

qemu_arm64
* boot - pass: 20,
* kselftest - skip: 27, pass: 37, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* 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: 9,
* ltp-math-tests - pass: 2,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,
* ltp-timers-tests - pass: 13,

qemu_x86_64
* boot - pass: 22,
* kselftest - skip: 13, pass: 4, fail: 2
* kselftest-vsyscall-mode-native - skip: 27, pass: 49, fail: 4
* kselftest-vsyscall-mode-none - skip: 27, pass: 49, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* 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: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 147, pass: 1003,
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 19, fail: 1
* kselftest - skip: 24, pass: 37, fail: 4
* libhugetlbfs - skip: 1, pass: 87,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 58,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* 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 - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 75, pass: 1075,
* ltp-timers-tests - pass: 13,

x86_64
* boot - pass: 22,
* kselftest - skip: 25, pass: 51, fail: 4
* kselftest-vsyscall-mode-native - skip: 25, pass: 50, fail: 5
* kselftest-vsyscall-mode-none - skip: 25, pass: 51, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 58,
* 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: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 116, pass: 1034,
* ltp-timers-tests - pass: 13,

Signature · 2 lines

Linaro QA (BETA)
https://qa-reports.linaro.org

Greg Kroah-Hartman

author maintainer

2018-04-24 07:26 UTC #117 lore raw

Quoted 45 lines · Dan Rue

Quoted 44 lines · Greg Kroah-Hartman
Quoted 42 lines · Greg Kroah-Hartman
Quoted 27 lines · Naresh Kamboju
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.96 release. There are 95 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 24 13:51:53 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.96-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
Regression detected on arm64 devices Hikey and Juno.
Here is the list of bad commit patches to be reverted.
git bisect found first bad commit as "3"
but reverting 3 patch failed.
so i have to revert all four patches and boot test and the boot PASS on hikey.
Quoted 9 lines
1)
Theodore Ts'o <[email protected]>
random: add new ioctl RNDRESEEDCRNG
2)
Theodore Ts'o <[email protected]>
random: crng_reseed() should lock the crng instance that it is modifying
3)
Theodore Ts'o <[email protected]>
random: set up the NUMA crng instances after the CRNG is fully initialized
This is the one I need to revert anyway.
Let me see if I can just drop that one and do a -rc3. Give me a few hours...

Quoted 6 lines

Quoted 3 lines
Ok, I've dropped just patch 3 from 4.16.y, 4.14.y and 4.9.y and pushed out -rc3 versions of all of these. Let me know if that works or not for you.
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Great!

Quoted 5 lines

I made a few comments inline regarding the reported failures. Also, as this report is pushing 200 lines now with all of our tests and environments (about 8*22 test runs), I'm planning on making some changes in the next few weeks to make it more concise and useful. Any suggestions or feature requests are most welcome.

How about only reporting problems? Having tests "pass" is the norm and should always happen, right? That would make the reports smaller.

thanks,

greg k-h

Dan Rue

2018-04-24 17:23 UTC #118 lore raw

Quoted 9 lines · Greg Kroah-Hartman

Quoted 5 lines · Dan Rue
I made a few comments inline regarding the reported failures. Also, as this report is pushing 200 lines now with all of our tests and environments (about 8*22 test runs), I'm planning on making some changes in the next few weeks to make it more concise and useful. Any suggestions or feature requests are most welcome.
How about only reporting problems? Having tests "pass" is the norm and should always happen, right? That would make the reports smaller.

I agree, though I would like to provide a bit of context so that people new to the process have some idea about testing breadth and depth - but it should be a few lines, rather than the hundreds that we have now.

Dan

Mark Brown

2018-04-24 17:36 UTC #119 lore raw

Quoted 8 lines · Dan Rue

Quoted 2 lines · Greg Kroah-Hartman
How about only reporting problems? Having tests "pass" is the norm and should always happen, right? That would make the reports smaller.
I agree, though I would like to provide a bit of context so that people new to the process have some idea about testing breadth and depth - but it should be a few lines, rather than the hundreds that we have now.

If you link to the web site people can in theory look there (obviously there's some work going on with the website to make it more readily digestible) for more context.

Guenter Roeck

2018-04-24 17:46 UTC #120 lore raw

In reply to Dan Rue

Quoted 8 lines · Dan Rue

Quoted 7 lines · Greg Kroah-Hartman
Quoted 5 lines · Dan Rue
I made a few comments inline regarding the reported failures. Also, as this report is pushing 200 lines now with all of our tests and environments (about 8*22 test runs), I'm planning on making some changes in the next few weeks to make it more concise and useful. Any suggestions or feature requests are most welcome.

Quoted 5 lines

Quoted 2 lines
How about only reporting problems? Having tests "pass" is the norm and should always happen, right? That would make the reports smaller.
I agree, though I would like to provide a bit of context so that people new to the process have some idea about testing breadth and depth - but

I did that initially, but found that it is only confusing. Sure, there should be a means to look up the actual tests, but for the notification e-mail only pass/fail is relevant.

I found that even "skipped" is confusing, because people started asking why tests are being skipped.

Guenter

Greg Kroah-Hartman

author maintainer

2018-04-23 18:04 UTC #121 lore raw