Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1691242 > unrolled thread

[PATCH 4.12 00/84] 4.12.3-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 11:50 +0200
    [PATCH 4.12 56/84] arm64: Preventing READ_IMPLIES_EXEC propagation Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 63/84] mnt: Make propagate_umount less slow for overlapping mount propagation trees Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 59/84] nvmem: core: fix leaks on registration errors Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 54/84] powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 41/84] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 38/84] parisc: use compat_sys_keyctl() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 76/84] PM / wakeirq: Convert to SRCU Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 46/84] fs/dcache.c: fix spin lockup issue on nlru->lock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 40/84] parisc/mm: Ensure IRQs are off in switch_mm() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 53/84] exec: Limit arg stack to at most 75% of _STK_LIM Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 57/84] vt: fix unchecked __put_user() in tioclinux ioctls Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 64/84] selftests/capabilities: Fix the test_execve test Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 55/84] ARM64: dts: marvell: armada37xx: Fix timer interrupt specifiers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 52/84] s390: reduce ELF_ET_DYN_BASE Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 44/84] kernel/extable.c: mark core_kernel_text notrace Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 39/84] parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 45/84] mm/list_lru.c: fix list_lru_count_node() to be race free Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 47/84] checkpatch: silence perl 5.26.0 unescaped left brace warnings Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 62/84] mnt: In propgate_umount handle visiting mounts in any order Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 61/84] mnt: In umount propagation reparent in a separate pass Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 50/84] arm64: move ELF_ET_DYN_BASE to 4GB / 4MB Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 58/84] rcu: Add memory barriers for NOCB leader wakeup Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 48/84] binfmt_elf: use ELF_ET_DYN_BASE only for PIE Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 60/84] Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:00 +0200
    [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
      Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Daniel Kiper <daniel.kiper@oracle.com> - 2017-07-19 12:40 +0200
        Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 13:20 +0200
          Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 13:30 +0200
            Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Daniel Kiper <daniel.kiper@oracle.com> - 2017-07-19 14:00 +0200
          Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Daniel Kiper <daniel.kiper@oracle.com> - 2017-07-19 13:30 +0200
        Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-20 11:20 +0200
          Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Ingo Molnar <mingo@kernel.org> - 2017-07-20 11:50 +0200
          Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Daniel Kiper <daniel.kiper@oracle.com> - 2017-07-20 14:40 +0200
            Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Juergen Gross <jgross@suse.com> - 2017-07-21 08:40 +0200
        Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct  members used by Xen Ingo Molnar <mingo@kernel.org> - 2017-07-20 11:20 +0200
    [PATCH 4.12 09/84] liquidio: fix bug in soft reset failure detection Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 02/84] net/mlx5: Fix driver load error flow when firmware is stuck Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 16/84] tap: convert a mutex to a spinlock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 30/84] cfg80211: Check if PMKID attribute is of expected size Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 20/84] Adding asm-prototypes.h for genksyms to generate crc Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 32/84] drm/amdgpu/gfx6: properly cache mc_arb_ramcfg Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 13/84] rds: tcp: use sock_create_lite() to create the accept socket Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 06/84] vxlan: fix hlist corruption Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 03/84] net/mlx5: Cancel delayed recovery work when unloading the driver Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 04/84] net/mlx5e: Fix TX carrier errors report in get stats ndo Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 36/84] irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 22/84] Adding the type of exported symbols Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 12/84] virtio-net: fix leaking of ctx array Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 28/84] cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 05/84] ipv6: dad: dont remove dynamic addresses if link is down Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 24/84] brcmfmac: Fix a memory leak in error handling path in brcmf_cfg80211_attach Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    [PATCH 4.12 17/84] bridge: mdb: fix leak on complete_info ptr on fail path Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-19 12:10 +0200
    Re: [PATCH 4.12 00/84] 4.12.3-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-07-19 18:40 +0200
      Re: [PATCH 4.12 00/84] 4.12.3-stable review Kevin Hilman <khilman@baylibre.com> - 2017-07-22 17:50 +0200
        Re: [PATCH 4.12 00/84] 4.12.3-stable review Sjoerd Simons <sjoerd.simons@collabora.co.uk> - 2017-07-24 11:20 +0200
    Re: [PATCH 4.12 00/84] 4.12.3-stable review Guenter Roeck <linux@roeck-us.net> - 2017-07-19 22:40 +0200
      Re: [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-07-20 07:10 +0200
    Re: [PATCH 4.12 00/84] 4.12.3-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-07-20 01:40 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1691270 — [PATCH 4.12 61/84] mnt: In umount propagation reparent in a separate pass

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

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

From: Eric W. Biederman <ebiederm@xmission.com>

commit 570487d3faf2a1d8a220e6ee10f472163123d7da upstream.

It was observed that in some pathlogical cases that the current code
does not unmount everything it should.  After investigation it
was determined that the issue is that mnt_change_mntpoint can
can change which mounts are available to be unmounted during mount
propagation which is wrong.

The trivial reproducer is:
$ cat ./pathological.sh

mount -t tmpfs test-base /mnt
cd /mnt
mkdir 1 2 1/1
mount --bind 1 1
mount --make-shared 1
mount --bind 1 2
mount --bind 1/1 1/1
mount --bind 1/1 1/1
echo
grep test-base /proc/self/mountinfo
umount 1/1
echo
grep test-base /proc/self/mountinfo

$ unshare -Urm ./pathological.sh

The expected output looks like:
46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
49 54 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
50 53 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
51 49 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
54 47 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
53 48 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
52 50 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000

46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000

The output without the fix looks like:
46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
49 54 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
50 53 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
51 49 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
54 47 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
53 48 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
52 50 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000

46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
52 48 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000

That last mount in the output was in the propgation tree to be unmounted but
was missed because the mnt_change_mountpoint changed it's parent before the walk
through the mount propagation tree observed it.

Fixes: 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.")
Acked-by: Andrei Vagin <avagin@virtuozzo.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/mount.h     |    1 +
 fs/namespace.c |    1 +
 fs/pnode.c     |   35 ++++++++++++++++++++++++++++++-----
 3 files changed, 32 insertions(+), 5 deletions(-)

--- a/fs/mount.h
+++ b/fs/mount.h
@@ -58,6 +58,7 @@ struct mount {
 	struct mnt_namespace *mnt_ns;	/* containing namespace */
 	struct mountpoint *mnt_mp;	/* where is it mounted */
 	struct hlist_node mnt_mp_list;	/* list mounts with the same mountpoint */
+	struct list_head mnt_reparent;	/* reparent list entry */
 #ifdef CONFIG_FSNOTIFY
 	struct fsnotify_mark_connector __rcu *mnt_fsnotify_marks;
 	__u32 mnt_fsnotify_mask;
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -236,6 +236,7 @@ static struct mount *alloc_vfsmnt(const
 		INIT_LIST_HEAD(&mnt->mnt_slave_list);
 		INIT_LIST_HEAD(&mnt->mnt_slave);
 		INIT_HLIST_NODE(&mnt->mnt_mp_list);
+		INIT_LIST_HEAD(&mnt->mnt_reparent);
 		init_fs_pin(&mnt->mnt_umount, drop_mountpoint);
 	}
 	return mnt;
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -439,7 +439,7 @@ static void mark_umount_candidates(struc
  * NOTE: unmounting 'mnt' naturally propagates to all other mounts its
  * parent propagates to.
  */
-static void __propagate_umount(struct mount *mnt)
+static void __propagate_umount(struct mount *mnt, struct list_head *to_reparent)
 {
 	struct mount *parent = mnt->mnt_parent;
 	struct mount *m;
@@ -464,17 +464,38 @@ static void __propagate_umount(struct mo
 		 */
 		topper = find_topper(child);
 		if (topper)
-			mnt_change_mountpoint(child->mnt_parent, child->mnt_mp,
-					      topper);
+			list_add_tail(&topper->mnt_reparent, to_reparent);
 
-		if (list_empty(&child->mnt_mounts)) {
+		if (topper || list_empty(&child->mnt_mounts)) {
 			list_del_init(&child->mnt_child);
+			list_del_init(&child->mnt_reparent);
 			child->mnt.mnt_flags |= MNT_UMOUNT;
 			list_move_tail(&child->mnt_list, &mnt->mnt_list);
 		}
 	}
 }
 
+static void reparent_mounts(struct list_head *to_reparent)
+{
+	while (!list_empty(to_reparent)) {
+		struct mount *mnt, *parent;
+		struct mountpoint *mp;
+
+		mnt = list_first_entry(to_reparent, struct mount, mnt_reparent);
+		list_del_init(&mnt->mnt_reparent);
+
+		/* Where should this mount be reparented to? */
+		mp = mnt->mnt_mp;
+		parent = mnt->mnt_parent;
+		while (parent->mnt.mnt_flags & MNT_UMOUNT) {
+			mp = parent->mnt_mp;
+			parent = parent->mnt_parent;
+		}
+
+		mnt_change_mountpoint(parent, mp, mnt);
+	}
+}
+
 /*
  * collect all mounts that receive propagation from the mount in @list,
  * and return these additional mounts in the same list.
@@ -485,11 +506,15 @@ static void __propagate_umount(struct mo
 int propagate_umount(struct list_head *list)
 {
 	struct mount *mnt;
+	LIST_HEAD(to_reparent);
 
 	list_for_each_entry_reverse(mnt, list, mnt_list)
 		mark_umount_candidates(mnt);
 
 	list_for_each_entry(mnt, list, mnt_list)
-		__propagate_umount(mnt);
+		__propagate_umount(mnt, &to_reparent);
+
+	reparent_mounts(&to_reparent);
+
 	return 0;
 }

[toc] | [prev] | [next] | [standalone]

#1691272 — [PATCH 4.12 50/84] arm64: move ELF_ET_DYN_BASE to 4GB / 4MB

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

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

From: Kees Cook <keescook@chromium.org>

commit 02445990a96e60a67526510d8b00f7e3d14101c3 upstream.

Now that explicitly executed loaders are loaded in the mmap region, we
have more freedom to decide where we position PIE binaries in the
address space to avoid possible collisions with mmap or stack regions.

For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
address space for 32-bit pointers.  On 32-bit use 4MB, to match ARM.
This could be 0x8000, the standard ET_EXEC load address, but that is
needlessly close to the NULL address, and anyone running arm compat PIE
will have an MMU, so the tight mapping is not needed.

Link: http://lkml.kernel.org/r/1498251600-132458-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/include/asm/elf.h |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -113,12 +113,11 @@
 #define ELF_EXEC_PAGESIZE	PAGE_SIZE
 
 /*
- * This is the location that an ET_DYN program is loaded if exec'ed.  Typical
- * use of this is to invoke "./ld.so someprog" to test out a new version of
- * the loader.  We need to make sure that it is out of the way of the program
- * that it will "exec", and that there is sufficient room for the brk.
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
  */
-#define ELF_ET_DYN_BASE	(2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE		0x100000000UL
 
 #ifndef __ASSEMBLY__
 
@@ -173,7 +172,8 @@ extern int arch_setup_additional_pages(s
 
 #ifdef CONFIG_COMPAT
 
-#define COMPAT_ELF_ET_DYN_BASE		(2 * TASK_SIZE_32 / 3)
+/* PIE load location for compat arm. Must match ARM ELF_ET_DYN_BASE. */
+#define COMPAT_ELF_ET_DYN_BASE		0x000400000UL
 
 /* AArch32 registers. */
 #define COMPAT_ELF_NGREG		18

[toc] | [prev] | [next] | [standalone]

#1691273 — [PATCH 4.12 58/84] rcu: Add memory barriers for NOCB leader wakeup

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

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

From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 6b5fc3a1331810db407c9e0e673dc1837afdc9d0 upstream.

Wait/wakeup operations do not guarantee ordering on their own.  Instead,
either locking or memory barriers are required.  This commit therefore
adds memory barriers to wake_nocb_leader() and nocb_leader_wait().

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Krister Johansen <kjlx@templeofstupid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/rcu/tree_plugin.h |    2 ++
 1 file changed, 2 insertions(+)

--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1769,6 +1769,7 @@ static void wake_nocb_leader(struct rcu_
 	if (READ_ONCE(rdp_leader->nocb_leader_sleep) || force) {
 		/* Prior smp_mb__after_atomic() orders against prior enqueue. */
 		WRITE_ONCE(rdp_leader->nocb_leader_sleep, false);
+		smp_mb(); /* ->nocb_leader_sleep before swake_up(). */
 		swake_up(&rdp_leader->nocb_wq);
 	}
 }
@@ -2023,6 +2024,7 @@ wait_again:
 	 * nocb_gp_head, where they await a grace period.
 	 */
 	gotcbs = false;
+	smp_mb(); /* wakeup before ->nocb_head reads. */
 	for (rdp = my_rdp; rdp; rdp = rdp->nocb_next_follower) {
 		rdp->nocb_gp_head = READ_ONCE(rdp->nocb_head);
 		if (!rdp->nocb_gp_head)

[toc] | [prev] | [next] | [standalone]

#1691274 — [PATCH 4.12 48/84] binfmt_elf: use ELF_ET_DYN_BASE only for PIE

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

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

From: Kees Cook <keescook@chromium.org>

commit eab09532d40090698b05a07c1c87f39fdbc5fab5 upstream.

The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries.  (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)

With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN.  However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.

For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region.  This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.

Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).

To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader.  Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.

For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.

Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.

Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/include/asm/elf.h |   13 +++++----
 fs/binfmt_elf.c            |   59 ++++++++++++++++++++++++++++++++++++++-------
 2 files changed, 58 insertions(+), 14 deletions(-)

--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -245,12 +245,13 @@ extern int force_personality32;
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* This is the location that an ET_DYN program is loaded if exec'ed.  Typical
-   use of this is to invoke "./ld.so someprog" to test out a new version of
-   the loader.  We need to make sure that it is out of the way of the program
-   that it will "exec", and that there is sufficient room for the brk.  */
-
-#define ELF_ET_DYN_BASE		(TASK_SIZE / 3 * 2)
+/*
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
+ */
+#define ELF_ET_DYN_BASE		(mmap_is_ia32() ? 0x000400000UL : \
+						  0x100000000UL)
 
 /* This yields a mask that user programs can use to figure out what
    instruction set this CPU supports.  This could be done in user space,
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -927,17 +927,60 @@ static int load_elf_binary(struct linux_
 		elf_flags = MAP_PRIVATE | MAP_DENYWRITE | MAP_EXECUTABLE;
 
 		vaddr = elf_ppnt->p_vaddr;
+		/*
+		 * If we are loading ET_EXEC or we have already performed
+		 * the ET_DYN load_addr calculations, proceed normally.
+		 */
 		if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) {
 			elf_flags |= MAP_FIXED;
 		} else if (loc->elf_ex.e_type == ET_DYN) {
-			/* Try and get dynamic programs out of the way of the
-			 * default mmap base, as well as whatever program they
-			 * might try to exec.  This is because the brk will
-			 * follow the loader, and is not movable.  */
-			load_bias = ELF_ET_DYN_BASE - vaddr;
-			if (current->flags & PF_RANDOMIZE)
-				load_bias += arch_mmap_rnd();
-			load_bias = ELF_PAGESTART(load_bias);
+			/*
+			 * This logic is run once for the first LOAD Program
+			 * Header for ET_DYN binaries to calculate the
+			 * randomization (load_bias) for all the LOAD
+			 * Program Headers, and to calculate the entire
+			 * size of the ELF mapping (total_size). (Note that
+			 * load_addr_set is set to true later once the
+			 * initial mapping is performed.)
+			 *
+			 * There are effectively two types of ET_DYN
+			 * binaries: programs (i.e. PIE: ET_DYN with INTERP)
+			 * and loaders (ET_DYN without INTERP, since they
+			 * _are_ the ELF interpreter). The loaders must
+			 * be loaded away from programs since the program
+			 * may otherwise collide with the loader (especially
+			 * for ET_EXEC which does not have a randomized
+			 * position). For example to handle invocations of
+			 * "./ld.so someprog" to test out a new version of
+			 * the loader, the subsequent program that the
+			 * loader loads must avoid the loader itself, so
+			 * they cannot share the same load range. Sufficient
+			 * room for the brk must be allocated with the
+			 * loader as well, since brk must be available with
+			 * the loader.
+			 *
+			 * Therefore, programs are loaded offset from
+			 * ELF_ET_DYN_BASE and loaders are loaded into the
+			 * independently randomized mmap region (0 load_bias
+			 * without MAP_FIXED).
+			 */
+			if (elf_interpreter) {
+				load_bias = ELF_ET_DYN_BASE;
+				if (current->flags & PF_RANDOMIZE)
+					load_bias += arch_mmap_rnd();
+				elf_flags |= MAP_FIXED;
+			} else
+				load_bias = 0;
+
+			/*
+			 * Since load_bias is used for all subsequent loading
+			 * calculations, we must lower it by the first vaddr
+			 * so that the remaining calculations based on the
+			 * ELF vaddrs will be correctly offset. The result
+			 * is then page aligned.
+			 */
+			load_bias = ELF_PAGESTART(load_bias - vaddr);
+
 			total_size = total_mapping_size(elf_phdata,
 							loc->elf_ex.e_phnum);
 			if (!total_size) {

[toc] | [prev] | [next] | [standalone]

#1691276 — [PATCH 4.12 60/84] Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page

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

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

From: Michael Kelley <mikelley@microsoft.com>

commit 13b9abfc92be7c4454bff912021b9f835dea6e15 upstream.

Extend the disabling of preemption to include the hypercall so that
another thread can't get the CPU and corrupt the per-cpu page used
for hypercall arguments.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -82,10 +82,15 @@ int hv_post_message(union hv_connection_
 	aligned_msg->message_type = message_type;
 	aligned_msg->payload_size = payload_size;
 	memcpy((void *)aligned_msg->payload, payload, payload_size);
-	put_cpu_ptr(hv_cpu);
 
 	status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
 
+	/* Preemption must remain disabled until after the hypercall
+	 * so some other thread can't get scheduled onto this cpu and
+	 * corrupt the per-cpu post_msg_page
+	 */
+	put_cpu_ptr(hv_cpu);
+
 	return status & 0xFFFF;
 }
 

[toc] | [prev] | [next] | [standalone]

#1691277 — [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

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

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

From: Daniel Kiper <daniel.kiper@oracle.com>

commit 6c64447ec58b0bac612732303f7ab04562124587 upstream.

The current approach, which is the wholesale efi struct initialization from
a 'efi_xen' local template is not robust. Usually if new member is defined
then it is properly initialized in drivers/firmware/efi/efi.c, but not in
arch/x86/xen/efi.c.

The effect is that the Xen initialization clears any fields the generic code
might have set and the Xen code does not know about yet.

I saw this happen a few times, so let's initialize only the EFI struct members
used by Xen and maintain no local duplicate, to avoid such issues in the future.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: jgross@suse.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1498128697-12943-3-git-send-email-daniel.kiper@oracle.com
[ Clarified the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/xen/efi.c |   45 ++++++++++++---------------------------------
 1 file changed, 12 insertions(+), 33 deletions(-)

--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -54,38 +54,6 @@ static efi_system_table_t efi_systab_xen
 	.tables		= EFI_INVALID_TABLE_ADDR  /* Initialized later. */
 };
 
-static const struct efi efi_xen __initconst = {
-	.systab                   = NULL, /* Initialized later. */
-	.runtime_version	  = 0,    /* Initialized later. */
-	.mps                      = EFI_INVALID_TABLE_ADDR,
-	.acpi                     = EFI_INVALID_TABLE_ADDR,
-	.acpi20                   = EFI_INVALID_TABLE_ADDR,
-	.smbios                   = EFI_INVALID_TABLE_ADDR,
-	.smbios3                  = EFI_INVALID_TABLE_ADDR,
-	.sal_systab               = EFI_INVALID_TABLE_ADDR,
-	.boot_info                = EFI_INVALID_TABLE_ADDR,
-	.hcdp                     = EFI_INVALID_TABLE_ADDR,
-	.uga                      = EFI_INVALID_TABLE_ADDR,
-	.uv_systab                = EFI_INVALID_TABLE_ADDR,
-	.fw_vendor                = EFI_INVALID_TABLE_ADDR,
-	.runtime                  = EFI_INVALID_TABLE_ADDR,
-	.config_table             = EFI_INVALID_TABLE_ADDR,
-	.get_time                 = xen_efi_get_time,
-	.set_time                 = xen_efi_set_time,
-	.get_wakeup_time          = xen_efi_get_wakeup_time,
-	.set_wakeup_time          = xen_efi_set_wakeup_time,
-	.get_variable             = xen_efi_get_variable,
-	.get_next_variable        = xen_efi_get_next_variable,
-	.set_variable             = xen_efi_set_variable,
-	.query_variable_info      = xen_efi_query_variable_info,
-	.update_capsule           = xen_efi_update_capsule,
-	.query_capsule_caps       = xen_efi_query_capsule_caps,
-	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
-	.reset_system             = xen_efi_reset_system,
-	.set_virtual_address_map  = NULL, /* Not used under Xen. */
-	.flags			  = 0     /* Initialized later. */
-};
-
 static efi_system_table_t __init *xen_efi_probe(void)
 {
 	struct xen_platform_op op = {
@@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_ef
 
 	/* Here we know that Xen runs on EFI platform. */
 
-	efi = efi_xen;
+	efi.get_time                 = xen_efi_get_time;
+	efi.set_time                 = xen_efi_set_time;
+	efi.get_wakeup_time          = xen_efi_get_wakeup_time;
+	efi.set_wakeup_time          = xen_efi_set_wakeup_time;
+	efi.get_variable             = xen_efi_get_variable;
+	efi.get_next_variable        = xen_efi_get_next_variable;
+	efi.set_variable             = xen_efi_set_variable;
+	efi.query_variable_info      = xen_efi_query_variable_info;
+	efi.update_capsule           = xen_efi_update_capsule;
+	efi.query_capsule_caps       = xen_efi_query_capsule_caps;
+	efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+	efi.reset_system             = xen_efi_reset_system;
 
 	efi_systab_xen.tables = info->cfg.addr;
 	efi_systab_xen.nr_tables = info->cfg.nent;

[toc] | [prev] | [next] | [standalone]

#1691430 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

Hey Greg,

On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> 4.12-stable review patch.  If anyone has any objections, please let me know.

Why did you skip this patch for 4.11? IMO it should be applied there too.

Daniel

[toc] | [prev] | [next] | [standalone]

#1691488 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> Hey Greg,
> 
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch.  If anyone has any objections, please let me know.
> 
> Why did you skip this patch for 4.11? IMO it should be applied there too.

Are you sure it actually applied?  (hint, it did not...)

If you want it in 4.11, or older kernels, please provide a working
backport.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1691532 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> > 
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch.  If anyone has any objections, please let me know.
> > 
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
> 
> Are you sure it actually applied?  (hint, it did not...)
> 
> If you want it in 4.11, or older kernels, please provide a working
> backport.

And, in the future, if you want it to be applied to older kernels, or be
notified if it can not be, please add a kernel version number in the
stable marking:
	Cc: stable@vger.kernel.org # 4.0+
or use the Fixes: tag:
	Fixes: SHASHAHSA ("short description")
which I pick up on and let you know if the patch does not actually apply
back to the kernel that the fixes: tag was in.

hope this helps,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1691606 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On Wed, Jul 19, 2017 at 01:19:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch.  If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > Are you sure it actually applied?  (hint, it did not...)
> >
> > If you want it in 4.11, or older kernels, please provide a working
> > backport.
>
> And, in the future, if you want it to be applied to older kernels, or be
> notified if it can not be, please add a kernel version number in the
> stable marking:
> 	Cc: stable@vger.kernel.org # 4.0+
> or use the Fixes: tag:
> 	Fixes: SHASHAHSA ("short description")
> which I pick up on and let you know if the patch does not actually apply
> back to the kernel that the fixes: tag was in.
>
> hope this helps,

Sure thing! Thanks a lot!

Daniel

[toc] | [prev] | [next] | [standalone]

#1691538 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch.  If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> Are you sure it actually applied?  (hint, it did not...)
>
> If you want it in 4.11, or older kernels, please provide a working
> backport.

OK, if it did not apply then probably there were some changes in the code
here and there. Though, IIRC, fix itself is perfectly valid for 4.11.
So, I will post updated patch for it.

Thanks,

Daniel

[toc] | [prev] | [next] | [standalone]

#1692676 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> 
> * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> 
> > Hey Greg,
> > 
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch.  If anyone has any objections, please let me know.
> > 
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
> 
> The thing is, this patch should probaly not even be in v4.12, as it should only 
> make any difference if there's a separate _bug_ in the kernel.
> 
> This patch makes things more robust going forward, but I question that it needs to 
> be in -stable.

Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
tree as it obviously isn't stable material, sorry for not catching that
before.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1692703 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> > 
> > * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > 
> > > Hey Greg,
> > > 
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> > 
> > The thing is, this patch should probaly not even be in v4.12, as it should only 
> > make any difference if there's a separate _bug_ in the kernel.
> > 
> > This patch makes things more robust going forward, but I question that it needs to 
> > be in -stable.
> 
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.

I should have caught the tag as well when applying the upstream patch to begin 
with.

Thanks!

	Ingo

[toc] | [prev] | [next] | [standalone]

#1692887 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch.  If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.

Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
found/assigned by/to him. Juergen? If it is true then I would apply it to
stable. If I am wrong you can drop it.

Thanks,

Daniel

[toc] | [prev] | [next] | [standalone]

#1693416 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

On 20/07/17 14:33, Daniel Kiper wrote:
> On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
>>>
>>> * Daniel Kiper <daniel.kiper@oracle.com> wrote:
>>>
>>>> Hey Greg,
>>>>
>>>> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
>>>>> 4.12-stable review patch.  If anyone has any objections, please let me know.
>>>>
>>>> Why did you skip this patch for 4.11? IMO it should be applied there too.
>>>
>>> The thing is, this patch should probaly not even be in v4.12, as it should only
>>> make any difference if there's a separate _bug_ in the kernel.
>>>
>>> This patch makes things more robust going forward, but I question that it needs to
>>> be in -stable.
>>
>> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
>> tree as it obviously isn't stable material, sorry for not catching that
>> before.
> 
> Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
> found/assigned by/to him. Juergen? If it is true then I would apply it to
> stable. If I am wrong you can drop it.

I'm not sure both patches (this one and upstream 457ea3f7e97881f) are
needed. I have got a report about a failing boot and with both patches
applied the boot is working. I will ask if 457ea3f7e97881f alone works,
too. If it doesn't I'll request this patch to be added to stable again.


Juergen

[toc] | [prev] | [next] | [standalone]

#1692678 — Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

* Daniel Kiper <daniel.kiper@oracle.com> wrote:

> Hey Greg,
> 
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch.  If anyone has any objections, please let me know.
> 
> Why did you skip this patch for 4.11? IMO it should be applied there too.

The thing is, this patch should probaly not even be in v4.12, as it should only 
make any difference if there's a separate _bug_ in the kernel.

This patch makes things more robust going forward, but I question that it needs to 
be in -stable.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1691278 — [PATCH 4.12 09/84] liquidio: fix bug in soft reset failure detection

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

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

From: Derek Chickles <derek.chickles@cavium.com>


[ Upstream commit 05a6b4cae8c0cc1680c9dd33a97a49a13c0f01bc ]

The code that detects a failed soft reset of Octeon is comparing the wrong
value against the reset value of the Octeon SLI_SCRATCH_1 register,
resulting in an inability to detect a soft reset failure.  Fix it by using
the correct value in the comparison, which is any non-zero value.

Fixes: f21fb3ed364b ("Add support of Cavium Liquidio ethernet adapters")
Fixes: c0eab5b3580a ("liquidio: CN23XX firmware download")
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c |    2 +-
 drivers/net/ethernet/cavium/liquidio/cn66xx_device.c    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -221,7 +221,7 @@ static int cn23xx_pf_soft_reset(struct o
 	/* Wait for 100ms as Octeon resets. */
 	mdelay(100);
 
-	if (octeon_read_csr64(oct, CN23XX_SLI_SCRATCH1) == 0x1234ULL) {
+	if (octeon_read_csr64(oct, CN23XX_SLI_SCRATCH1)) {
 		dev_err(&oct->pci_dev->dev, "OCTEON[%d]: Soft reset failed\n",
 			oct->octeon_id);
 		return 1;
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
@@ -44,7 +44,7 @@ int lio_cn6xxx_soft_reset(struct octeon_
 	/* Wait for 10ms as Octeon resets. */
 	mdelay(100);
 
-	if (octeon_read_csr64(oct, CN6XXX_SLI_SCRATCH1) == 0x1234ULL) {
+	if (octeon_read_csr64(oct, CN6XXX_SLI_SCRATCH1)) {
 		dev_err(&oct->pci_dev->dev, "Soft reset failed\n");
 		return 1;
 	}

[toc] | [prev] | [next] | [standalone]

#1691279 — [PATCH 4.12 02/84] net/mlx5: Fix driver load error flow when firmware is stuck

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

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

From: Gal Pressman <galp@mellanox.com>


[ Upstream commit 8ce59b16b4b6eacedaec1f7b652b4781cdbfe15f ]

When wait for firmware init fails, previous code would mistakenly
return success and cause inconsistency in the driver state.

Fixes: 6c780a0267b8 ("net/mlx5: Wait for FW readiness before initializing command interface")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1020,7 +1020,7 @@ static int mlx5_load_one(struct mlx5_cor
 	if (err) {
 		dev_err(&dev->pdev->dev, "Firmware over %d MS in pre-initializing state, aborting\n",
 			FW_PRE_INIT_TIMEOUT_MILI);
-		goto out;
+		goto out_err;
 	}
 
 	err = mlx5_cmd_init(dev);

[toc] | [prev] | [next] | [standalone]

#1691280 — [PATCH 4.12 16/84] tap: convert a mutex to a spinlock

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

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

From: WANG Cong <xiyou.wangcong@gmail.com>


[ Upstream commit ffa423fb3251f8737303ffc3b0659e86e501808e ]

We are not allowed to block on the RCU reader side, so can't
just hold the mutex as before. As a quick fix, convert it to
a spinlock.

Fixes: d9f1f61c0801 ("tap: Extending tap device create/destroy APIs")
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Sainath Grandhi <sainath.grandhi@intel.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/tap.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -106,7 +106,7 @@ struct major_info {
 	struct rcu_head rcu;
 	dev_t major;
 	struct idr minor_idr;
-	struct mutex minor_lock;
+	spinlock_t minor_lock;
 	const char *device_name;
 	struct list_head next;
 };
@@ -416,15 +416,15 @@ int tap_get_minor(dev_t major, struct ta
 		goto unlock;
 	}
 
-	mutex_lock(&tap_major->minor_lock);
-	retval = idr_alloc(&tap_major->minor_idr, tap, 1, TAP_NUM_DEVS, GFP_KERNEL);
+	spin_lock(&tap_major->minor_lock);
+	retval = idr_alloc(&tap_major->minor_idr, tap, 1, TAP_NUM_DEVS, GFP_ATOMIC);
 	if (retval >= 0) {
 		tap->minor = retval;
 	} else if (retval == -ENOSPC) {
 		netdev_err(tap->dev, "Too many tap devices\n");
 		retval = -EINVAL;
 	}
-	mutex_unlock(&tap_major->minor_lock);
+	spin_unlock(&tap_major->minor_lock);
 
 unlock:
 	rcu_read_unlock();
@@ -442,12 +442,12 @@ void tap_free_minor(dev_t major, struct
 		goto unlock;
 	}
 
-	mutex_lock(&tap_major->minor_lock);
+	spin_lock(&tap_major->minor_lock);
 	if (tap->minor) {
 		idr_remove(&tap_major->minor_idr, tap->minor);
 		tap->minor = 0;
 	}
-	mutex_unlock(&tap_major->minor_lock);
+	spin_unlock(&tap_major->minor_lock);
 
 unlock:
 	rcu_read_unlock();
@@ -467,13 +467,13 @@ static struct tap_dev *dev_get_by_tap_fi
 		goto unlock;
 	}
 
-	mutex_lock(&tap_major->minor_lock);
+	spin_lock(&tap_major->minor_lock);
 	tap = idr_find(&tap_major->minor_idr, minor);
 	if (tap) {
 		dev = tap->dev;
 		dev_hold(dev);
 	}
-	mutex_unlock(&tap_major->minor_lock);
+	spin_unlock(&tap_major->minor_lock);
 
 unlock:
 	rcu_read_unlock();
@@ -1227,7 +1227,7 @@ static int tap_list_add(dev_t major, con
 	tap_major->major = MAJOR(major);
 
 	idr_init(&tap_major->minor_idr);
-	mutex_init(&tap_major->minor_lock);
+	spin_lock_init(&tap_major->minor_lock);
 
 	tap_major->device_name = device_name;
 

[toc] | [prev] | [next] | [standalone]

#1691284 — [PATCH 4.12 30/84] cfg80211: Check if PMKID attribute is of expected size

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

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

From: Srinivas Dasari <dasaris@qti.qualcomm.com>

commit 9361df14d1cbf966409d5d6f48bb334384fbe138 upstream.

nla policy checks for only maximum length of the attribute data
when the attribute type is NLA_BINARY. If userspace sends less
data than specified, the wireless drivers may access illegal
memory. When type is NLA_UNSPEC, nla policy check ensures that
userspace sends minimum specified length number of bytes.

Remove type assignment to NLA_BINARY from nla_policy of
NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum
WLAN_PMKID_LEN bytes are received from userspace with
NL80211_ATTR_PMKID.

Fixes: 67fbb16be69d ("nl80211: PMKSA caching support")
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/wireless/nl80211.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -291,8 +291,7 @@ static const struct nla_policy nl80211_p
 	[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
 	[NL80211_ATTR_PID] = { .type = NLA_U32 },
 	[NL80211_ATTR_4ADDR] = { .type = NLA_U8 },
-	[NL80211_ATTR_PMKID] = { .type = NLA_BINARY,
-				 .len = WLAN_PMKID_LEN },
+	[NL80211_ATTR_PMKID] = { .len = WLAN_PMKID_LEN },
 	[NL80211_ATTR_DURATION] = { .type = NLA_U32 },
 	[NL80211_ATTR_COOKIE] = { .type = NLA_U64 },
 	[NL80211_ATTR_TX_RATES] = { .type = NLA_NESTED },

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web