Merge remote-tracking branch 'origin/f26' into f26-user-thl-vanilla-fedora

5 files changed, 346 insertions, 1 deletions

diff --git a/0001-mm-don-t-warn-about-allocations-which-stall-for-too-.patch b/0001-mm-don-t-warn-about-allocations-which-stall-for-too-.patch
new file mode 100644
index 000000000..bc5921caf
--- /dev/null
+++ b/0001-mm-don-t-warn-about-allocations-which-stall-for-too-.patch
@@ -0,0 +1,181 @@
+From 400e22499dd92613821374c8c6c88c7225359980 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Wed, 15 Nov 2017 17:38:37 -0800
+Subject: [PATCH] mm: don't warn about allocations which stall for too long
+
+Commit 63f53dea0c98 ("mm: warn about allocations which stall for too
+long") was a great step for reducing possibility of silent hang up
+problem caused by memory allocation stalls.  But this commit reverts it,
+for it is possible to trigger OOM lockup and/or soft lockups when many
+threads concurrently called warn_alloc() (in order to warn about memory
+allocation stalls) due to current implementation of printk(), and it is
+difficult to obtain useful information due to limitation of synchronous
+warning approach.
+
+Current printk() implementation flushes all pending logs using the
+context of a thread which called console_unlock().  printk() should be
+able to flush all pending logs eventually unless somebody continues
+appending to printk() buffer.
+
+Since warn_alloc() started appending to printk() buffer while waiting
+for oom_kill_process() to make forward progress when oom_kill_process()
+is processing pending logs, it became possible for warn_alloc() to force
+oom_kill_process() loop inside printk().  As a result, warn_alloc()
+significantly increased possibility of preventing oom_kill_process()
+from making forward progress.
+
+---------- Pseudo code start ----------
+Before warn_alloc() was introduced:
+
+  retry:
+    if (mutex_trylock(&oom_lock)) {
+      while (atomic_read(&printk_pending_logs) > 0) {
+        atomic_dec(&printk_pending_logs);
+        print_one_log();
+      }
+      // Send SIGKILL here.
+      mutex_unlock(&oom_lock)
+    }
+    goto retry;
+
+After warn_alloc() was introduced:
+
+  retry:
+    if (mutex_trylock(&oom_lock)) {
+      while (atomic_read(&printk_pending_logs) > 0) {
+        atomic_dec(&printk_pending_logs);
+        print_one_log();
+      }
+      // Send SIGKILL here.
+      mutex_unlock(&oom_lock)
+    } else if (waited_for_10seconds()) {
+      atomic_inc(&printk_pending_logs);
+    }
+    goto retry;
+---------- Pseudo code end ----------
+
+Although waited_for_10seconds() becomes true once per 10 seconds,
+unbounded number of threads can call waited_for_10seconds() at the same
+time.  Also, since threads doing waited_for_10seconds() keep doing
+almost busy loop, the thread doing print_one_log() can use little CPU
+resource.  Therefore, this situation can be simplified like
+
+---------- Pseudo code start ----------
+  retry:
+    if (mutex_trylock(&oom_lock)) {
+      while (atomic_read(&printk_pending_logs) > 0) {
+        atomic_dec(&printk_pending_logs);
+        print_one_log();
+      }
+      // Send SIGKILL here.
+      mutex_unlock(&oom_lock)
+    } else {
+      atomic_inc(&printk_pending_logs);
+    }
+    goto retry;
+---------- Pseudo code end ----------
+
+when printk() is called faster than print_one_log() can process a log.
+
+One of possible mitigation would be to introduce a new lock in order to
+make sure that no other series of printk() (either oom_kill_process() or
+warn_alloc()) can append to printk() buffer when one series of printk()
+(either oom_kill_process() or warn_alloc()) is already in progress.
+
+Such serialization will also help obtaining kernel messages in readable
+form.
+
+---------- Pseudo code start ----------
+  retry:
+    if (mutex_trylock(&oom_lock)) {
+      mutex_lock(&oom_printk_lock);
+      while (atomic_read(&printk_pending_logs) > 0) {
+        atomic_dec(&printk_pending_logs);
+        print_one_log();
+      }
+      // Send SIGKILL here.
+      mutex_unlock(&oom_printk_lock);
+      mutex_unlock(&oom_lock)
+    } else {
+      if (mutex_trylock(&oom_printk_lock)) {
+        atomic_inc(&printk_pending_logs);
+        mutex_unlock(&oom_printk_lock);
+      }
+    }
+    goto retry;
+---------- Pseudo code end ----------
+
+But this commit does not go that direction, for we don't want to
+introduce a new lock dependency, and we unlikely be able to obtain
+useful information even if we serialized oom_kill_process() and
+warn_alloc().
+
+Synchronous approach is prone to unexpected results (e.g.  too late [1],
+too frequent [2], overlooked [3]).  As far as I know, warn_alloc() never
+helped with providing information other than "something is going wrong".
+I want to consider asynchronous approach which can obtain information
+during stalls with possibly relevant threads (e.g.  the owner of
+oom_lock and kswapd-like threads) and serve as a trigger for actions
+(e.g.  turn on/off tracepoints, ask libvirt daemon to take a memory dump
+of stalling KVM guest for diagnostic purpose).
+
+This commit temporarily loses ability to report e.g.  OOM lockup due to
+unable to invoke the OOM killer due to !__GFP_FS allocation request.
+But asynchronous approach will be able to detect such situation and emit
+warning.  Thus, let's remove warn_alloc().
+
+[1] https://bugzilla.kernel.org/show_bug.cgi?id=192981
+[2] http://lkml.kernel.org/r/CAM_iQpWuPVGc2ky8M-9yukECtS+zKjiDasNymX7rMcBjBFyM_A@mail.gmail.com
+[3] commit db73ee0d46379922 ("mm, vmscan: do not loop on too_many_isolated for ever"))
+
+Link: http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
+Reported-by: yuwang.yuwang <yuwang.yuwang@alibaba-inc.com>
+Reported-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: Dave Hansen <dave.hansen@intel.com>
+Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Cc: Petr Mladek <pmladek@suse.com>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ mm/page_alloc.c | 10 ----------
+ 1 file changed, 10 deletions(-)
+
+diff --git a/mm/page_alloc.c b/mm/page_alloc.c
+index 04bf1ad50144..bd1a686e40fe 100644
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -3903,8 +3903,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
+ 	enum compact_result compact_result;
+ 	int compaction_retries;
+ 	int no_progress_loops;
+-	unsigned long alloc_start = jiffies;
+-	unsigned int stall_timeout = 10 * HZ;
+ 	unsigned int cpuset_mems_cookie;
+ 	int reserve_flags;
+
+@@ -4036,14 +4034,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
+ 	if (!can_direct_reclaim)
+ 		goto nopage;
+
+-	/* Make sure we know about allocations which stall for too long */
+-	if (time_after(jiffies, alloc_start + stall_timeout)) {
+-		warn_alloc(gfp_mask & ~__GFP_NOWARN, ac->nodemask,
+-			"page allocation stalls for %ums, order:%u",
+-			jiffies_to_msecs(jiffies-alloc_start), order);
+-		stall_timeout += 10 * HZ;
+-	}
+-
+ 	/* Avoid recursion of direct reclaim */
+ 	if (current->flags & PF_MEMALLOC)
+ 		goto nopage;
+-- 
+2.14.3
+
diff --git a/ACPI-sbshc-remove-raw-pointer-from-printk-message.patch b/ACPI-sbshc-remove-raw-pointer-from-printk-message.patch
new file mode 100644
index 000000000..0aa10d0af
--- /dev/null
+++ b/ACPI-sbshc-remove-raw-pointer-from-printk-message.patch
@@ -0,0 +1,41 @@
+From patchwork Fri Jan 19 09:06:03 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: ACPI: sbshc: remove raw pointer from printk message
+From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
+X-Patchwork-Id: 10174835
+Message-Id: <20180119090603.GA7775@kroah.com>
+To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>
+Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
+ Wang Qize <wang_qize@venustech.com.cn>
+Date: Fri, 19 Jan 2018 10:06:03 +0100
+
+There's no need to be printing a raw kernel pointer to the kernel log at
+every boot.  So just remove it, and change the whole message to use the
+correct dev_info() call at the same time.
+
+Reported-by: Wang Qize <wang_qize@venustech.com.cn>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+---
+To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
+
+diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
+index 2fa8304171e0..217e1caf58d6 100644
+--- a/drivers/acpi/sbshc.c
++++ b/drivers/acpi/sbshc.c
+@@ -275,8 +275,8 @@ static int acpi_smbus_hc_add(struct acpi_device *device)
+ 	device->driver_data = hc;
+ 
+ 	acpi_ec_add_query_handler(hc->ec, hc->query_bit, NULL, smbus_alarm, hc);
+-	printk(KERN_INFO PREFIX "SBS HC: EC = 0x%p, offset = 0x%0x, query_bit = 0x%0x\n",
+-		hc->ec, hc->offset, hc->query_bit);
++	dev_info(&device->dev, "SBS HC: offset = 0x%0x, query_bit = 0x%0x\n",
++		 hc->offset, hc->query_bit);
+ 
+ 	return 0;
+ }
diff --git a/Add-support-for-One-by-Wacom-CTL-472-CTL-672.patch b/Add-support-for-One-by-Wacom-CTL-472-CTL-672.patch
new file mode 100644
index 000000000..3f2d7fcd9
--- /dev/null
+++ b/Add-support-for-One-by-Wacom-CTL-472-CTL-672.patch
@@ -0,0 +1,51 @@
+From patchwork Tue Dec 26 23:50:18 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: Add support for One by Wacom (CTL-472 / CTL-672)
+From: Jason Gerecke <killertofu@gmail.com>
+X-Patchwork-Id: 10133291
+Message-Id: <20171226235018.5522-1-killertofu@gmail.com>
+To: linux-input@vger.kernel.org, Jiri Kosina <jkosina@suse.cz>,
+ Mx Jing <jingmingxuan@outlook.com>
+Cc: Ping Cheng <pinglinux@gmail.com>, Aaron Skomra <skomra@gmail.com>,
+ Jason Gerecke <killertofu@gmail.com>,
+ Jason Gerecke <jason.gerecke@wacom.com>
+Date: Tue, 26 Dec 2017 15:50:18 -0800
+
+Adds support for the second-generation "One by Wacom" tablets. These
+devices are similar to the last generation, but a slightly different size
+and reporting a higher number of pressure levels.
+
+Signed-off-by: Mx Jing <jingmingxuan@outlook.com>
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+---
+ drivers/hid/wacom_wac.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
+index aa692e28b2cd..5f932ddcdc49 100644
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -4376,6 +4376,12 @@ static const struct wacom_features wacom_features_0x360 =
+ static const struct wacom_features wacom_features_0x361 =
+ 	{ "Wacom Intuos Pro L", 62200, 43200, 8191, 63,
+ 	  INTUOSP2_BT, WACOM_INTUOS3_RES, WACOM_INTUOS3_RES, 9, .touch_max = 10 };
++static const struct wacom_features wacom_features_0x37A =
++	{ "Wacom One by Wacom S", 15200, 9500, 2047, 63,
++	  BAMBOO_PEN, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
++static const struct wacom_features wacom_features_0x37B =
++	{ "Wacom One by Wacom M", 21600, 13500, 2047, 63,
++	  BAMBOO_PEN, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+ 
+ static const struct wacom_features wacom_features_HID_ANY_ID =
+ 	{ "Wacom HID", .type = HID_GENERIC, .oVid = HID_ANY_ID, .oPid = HID_ANY_ID };
+@@ -4544,6 +4550,8 @@ const struct hid_device_id wacom_ids[] = {
+ 	{ USB_DEVICE_WACOM(0x343) },
+ 	{ BT_DEVICE_WACOM(0x360) },
+ 	{ BT_DEVICE_WACOM(0x361) },
++	{ USB_DEVICE_WACOM(0x37A) },
++	{ USB_DEVICE_WACOM(0x37B) },
+ 	{ USB_DEVICE_WACOM(0x4001) },
+ 	{ USB_DEVICE_WACOM(0x4004) },
+ 	{ USB_DEVICE_WACOM(0x5000) },
diff --git a/kernel.spec b/kernel.spec
index fd6b782d1..b4971bec8 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -44,7 +44,7 @@ Summary: The Linux kernel
 # For non-released -rc kernels, this will be appended after the rcX and
 # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
 #
-%global baserelease 200
+%global baserelease 201
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -651,6 +651,7 @@ Patch507: loop-fix-concurrent-lo_open-lo_release.patch
 
 # 550-600 Meltdown and Spectre Fixes
 Patch550: prevent-bounds-check-bypass-via-speculative-execution.patch
+Patch551: revert-module-add-retpoline-tag-to-vermagic.patch
 
 # 600 - Patches for improved Bay and Cherry Trail device support
 # Below patches are submitted upstream, awaiting review / merging
@@ -682,6 +683,15 @@ Patch633: 0001-platform-x86-dell-laptop-Filter-out-spurious-keyboar.patch
 # Fix crash on Xwayland using nouveau
 Patch634: dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch
 
+# rhbz 1539238
+Patch635: Add-support-for-One-by-Wacom-CTL-472-CTL-672.patch
+
+# CVE-2018-5750 rhbz 1539706 1539708
+Patch636: ACPI-sbshc-remove-raw-pointer-from-printk-message.patch
+
+# rhbz 1492664 1492665
+Patch637: 0001-mm-don-t-warn-about-allocations-which-stall-for-too-.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2262,6 +2272,16 @@ fi
 #
 #
 %changelog
+* Mon Jan 29 2018 Justin M. Forbes <jforbes@fedoraproject.org>
+- Fix CVE-2018-5750 (rhbz 1539706 1539708)
+- Fix softlockup (rhbz 1492664 1492665)
+
+* Sat Jan 27 2018 Laura Abbott <labbott@fedoraproject.org>
+- Add support for Wacom tablet (rhbz 1539238)
+
+* Fri Jan 26 2018 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.15-201
+- Revert retpoline vermagic tag
+
 * Wed Jan 24 2018 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.15-200
 - Linux v4.14.15
 - Fix CVE-2018-1000004 (rhbz 1535315 1535316)
diff --git a/revert-module-add-retpoline-tag-to-vermagic.patch b/revert-module-add-retpoline-tag-to-vermagic.patch
new file mode 100644
index 000000000..2b4d0eacc
--- /dev/null
+++ b/revert-module-add-retpoline-tag-to-vermagic.patch
@@ -0,0 +1,52 @@
+From 5132ede0fe8092b043dae09a7cc32b8ae7272baa Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Wed, 24 Jan 2018 15:28:17 +0100
+Subject: Revert "module: Add retpoline tag to VERMAGIC"
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 5132ede0fe8092b043dae09a7cc32b8ae7272baa upstream.
+
+This reverts commit 6cfb521ac0d5b97470883ff9b7facae264b7ab12.
+
+Turns out distros do not want to make retpoline as part of their "ABI",
+so this patch should not have been merged.  Sorry Andi, this was my
+fault, I suggested it when your original patch was the "correct" way of
+doing this instead.
+
+Reported-by: Jiri Kosina <jikos@kernel.org>
+Fixes: 6cfb521ac0d5 ("module: Add retpoline tag to VERMAGIC")
+Acked-by: Andi Kleen <ak@linux.intel.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: David Woodhouse <dwmw@amazon.co.uk>
+Cc: rusty@rustcorp.com.au
+Cc: arjan.van.de.ven@intel.com
+Cc: jeyu@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/vermagic.h |    8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/include/linux/vermagic.h
++++ b/include/linux/vermagic.h
+@@ -31,17 +31,11 @@
+ #else
+ #define MODULE_RANDSTRUCT_PLUGIN
+ #endif
+-#ifdef RETPOLINE
+-#define MODULE_VERMAGIC_RETPOLINE "retpoline "
+-#else
+-#define MODULE_VERMAGIC_RETPOLINE ""
+-#endif
+ 
+ #define VERMAGIC_STRING 						\
+ 	UTS_RELEASE " "							\
+ 	MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT 			\
+ 	MODULE_VERMAGIC_MODULE_UNLOAD MODULE_VERMAGIC_MODVERSIONS	\
+ 	MODULE_ARCH_VERMAGIC						\
+-	MODULE_RANDSTRUCT_PLUGIN					\
+-	MODULE_VERMAGIC_RETPOLINE
++	MODULE_RANDSTRUCT_PLUGIN
+