--- /dev/null
+From 59ea6d06cfa9247b586a695c21f94afa7183af74 Mon Sep 17 00:00:00 2001
+From: Andrea Arcangeli <aarcange@redhat.com>
+Date: Thu, 13 Jun 2019 15:56:11 -0700
+Subject: coredump: fix race condition between collapse_huge_page() and core dumping
+
+From: Andrea Arcangeli <aarcange@redhat.com>
+
+commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream.
+
+When fixing the race conditions between the coredump and the mmap_sem
+holders outside the context of the process, we focused on
+mmget_not_zero()/get_task_mm() callers in 04f5866e41fb70 ("coredump: fix
+race condition between mmget_not_zero()/get_task_mm() and core
+dumping"), but those aren't the only cases where the mmap_sem can be
+taken outside of the context of the process as Michal Hocko noticed
+while backporting that commit to older -stable kernels.
+
+If mmgrab() is called in the context of the process, but then the
+mm_count reference is transferred outside the context of the process,
+that can also be a problem if the mmap_sem has to be taken for writing
+through that mm_count reference.
+
+khugepaged registration calls mmgrab() in the context of the process,
+but the mmap_sem for writing is taken later in the context of the
+khugepaged kernel thread.
+
+collapse_huge_page() after taking the mmap_sem for writing doesn't
+modify any vma, so it's not obvious that it could cause a problem to the
+coredump, but it happens to modify the pmd in a way that breaks an
+invariant that pmd_trans_huge_lock() relies upon. collapse_huge_page()
+needs the mmap_sem for writing just to block concurrent page faults that
+call pmd_trans_huge_lock().
+
+Specifically the invariant that "!pmd_trans_huge()" cannot become a
+"pmd_trans_huge()" doesn't hold while collapse_huge_page() runs.
+
+The coredump will call __get_user_pages() without mmap_sem for reading,
+which eventually can invoke a lockless page fault which will need a
+functional pmd_trans_huge_lock().
+
+So collapse_huge_page() needs to use mmget_still_valid() to check it's
+not running concurrently with the coredump... as long as the coredump
+can invoke page faults without holding the mmap_sem for reading.
+
+This has "Fixes: khugepaged" to facilitate backporting, but in my view
+it's more a bug in the coredump code that will eventually have to be
+rewritten to stop invoking page faults without the mmap_sem for reading.
+So the long term plan is still to drop all mmget_still_valid().
+
+Link: http://lkml.kernel.org/r/20190607161558.32104-1-aarcange@redhat.com
+Fixes: ba76149f47d8 ("thp: khugepaged")
+Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
+Reported-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Jann Horn <jannh@google.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Cc: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: Peter Xu <peterx@redhat.com>
+Cc: Jason Gunthorpe <jgg@mellanox.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/sched/mm.h | 4 ++++
+ mm/khugepaged.c | 3 +++
+ 2 files changed, 7 insertions(+)
+
+--- a/include/linux/sched/mm.h
++++ b/include/linux/sched/mm.h
+@@ -62,6 +62,10 @@ static inline void mmdrop_async(struct m
+ * followed by taking the mmap_sem for writing before modifying the
+ * vmas or anything the coredump pretends not to change from under it.
+ *
++ * It also has to be called when mmgrab() is used in the context of
++ * the process, but then the mm_count refcount is transferred outside
++ * the context of the process to run down_write() on that pinned mm.
++ *
+ * NOTE: find_extend_vma() called from GUP context is the only place
+ * that can modify the "mm" (notably the vm_start/end) under mmap_sem
+ * for reading and outside the context of the process, so it is also
+--- a/mm/khugepaged.c
++++ b/mm/khugepaged.c
+@@ -1006,6 +1006,9 @@ static void collapse_huge_page(struct mm
+ * handled by the anon_vma lock + PG_lock.
+ */
+ down_write(&mm->mmap_sem);
++ result = SCAN_ANY_PROCESS;
++ if (!mmget_still_valid(mm))
++ goto out;
+ result = hugepage_vma_revalidate(mm, address, &vma);
+ if (result)
+ goto out;
--- /dev/null
+From e92a7be7fe5b2510fa60965eaf25f9e3dc08b8cc Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <jason.gerecke@wacom.com>
+Date: Wed, 24 Apr 2019 15:12:58 -0700
+Subject: HID: wacom: Don't report anything prior to the tool entering range
+
+From: Jason Gerecke <jason.gerecke@wacom.com>
+
+commit e92a7be7fe5b2510fa60965eaf25f9e3dc08b8cc upstream.
+
+If the tool spends some time in prox before entering range, a series of
+events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
+have any clue about the pen whose data is being reported. We need to hold
+off on reporting anything until the pen has entered range. Since we still
+want to report events that occur "in prox" after the pen has *left* range
+we use 'wacom-tool[0]' as the indicator that the pen did at one point
+enter range and provide us/userspace with tool type and serial number
+information.
+
+Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
+Cc: <stable@vger.kernel.org> # 4.11+
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom_wac.c | 20 +++++++++++---------
+ 1 file changed, 11 insertions(+), 9 deletions(-)
+
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -1271,17 +1271,19 @@ static void wacom_intuos_pro2_bt_pen(str
+ input_report_abs(pen_input, ABS_Z, rotation);
+ input_report_abs(pen_input, ABS_WHEEL, get_unaligned_le16(&frame[11]));
+ }
+- input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
+- input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
++ if (wacom->tool[0]) {
++ input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
++ input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
+
+- input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
+- input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
+- input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
++ input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
++ input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
++ input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
+
+- input_report_key(pen_input, wacom->tool[0], prox);
+- input_event(pen_input, EV_MSC, MSC_SERIAL, wacom->serial[0]);
+- input_report_abs(pen_input, ABS_MISC,
+- wacom_intuos_id_mangle(wacom->id[0])); /* report tool id */
++ input_report_key(pen_input, wacom->tool[0], prox);
++ input_event(pen_input, EV_MSC, MSC_SERIAL, wacom->serial[0]);
++ input_report_abs(pen_input, ABS_MISC,
++ wacom_intuos_id_mangle(wacom->id[0])); /* report tool id */
++ }
+
+ wacom->shared->stylus_in_proximity = prox;
+
--- /dev/null
+From 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725 Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <jason.gerecke@wacom.com>
+Date: Wed, 24 Apr 2019 15:12:57 -0700
+Subject: HID: wacom: Don't set tool type until we're in range
+
+From: Jason Gerecke <jason.gerecke@wacom.com>
+
+commit 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725 upstream.
+
+The serial number and tool type information that is reported by the tablet
+while a pen is merely "in prox" instead of fully "in range" can be stale
+and cause us to report incorrect tool information. Serial number, tool
+type, and other information is only valid once the pen comes fully in range
+so we should be careful to not use this information until that point.
+
+In particular, this issue may cause the driver to incorectly report
+BTN_TOOL_RUBBER after switching from the eraser tool back to the pen.
+
+Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
+Cc: <stable@vger.kernel.org> # 4.11+
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom_wac.c | 17 ++++++++++++++++-
+ 1 file changed, 16 insertions(+), 1 deletion(-)
+
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -1225,13 +1225,13 @@ static void wacom_intuos_pro2_bt_pen(str
+ /* Add back in missing bits of ID for non-USI pens */
+ wacom->id[0] |= (wacom->serial[0] >> 32) & 0xFFFFF;
+ }
+- wacom->tool[0] = wacom_intuos_get_tool_type(wacom_intuos_id_mangle(wacom->id[0]));
+
+ for (i = 0; i < pen_frames; i++) {
+ unsigned char *frame = &data[i*pen_frame_len + 1];
+ bool valid = frame[0] & 0x80;
+ bool prox = frame[0] & 0x40;
+ bool range = frame[0] & 0x20;
++ bool invert = frame[0] & 0x10;
+
+ if (!valid)
+ continue;
+@@ -1240,8 +1240,13 @@ static void wacom_intuos_pro2_bt_pen(str
+ wacom->shared->stylus_in_proximity = false;
+ wacom_exit_report(wacom);
+ input_sync(pen_input);
++
++ wacom->tool[0] = 0;
++ wacom->id[0] = 0;
++ wacom->serial[0] = 0;
+ return;
+ }
++
+ if (range) {
+ /* Fix rotation alignment: userspace expects zero at left */
+ int16_t rotation = (int16_t)get_unaligned_le16(&frame[9]);
+@@ -1249,6 +1254,16 @@ static void wacom_intuos_pro2_bt_pen(str
+ if (rotation > 899)
+ rotation -= 1800;
+
++ if (!wacom->tool[0]) { /* first in range */
++ /* Going into range select tool */
++ if (invert)
++ wacom->tool[0] = BTN_TOOL_RUBBER;
++ else if (wacom->id[0])
++ wacom->tool[0] = wacom_intuos_get_tool_type(wacom->id[0]);
++ else
++ wacom->tool[0] = BTN_TOOL_PEN;
++ }
++
+ input_report_abs(pen_input, ABS_X, get_unaligned_le16(&frame[1]));
+ input_report_abs(pen_input, ABS_Y, get_unaligned_le16(&frame[3]));
+ input_report_abs(pen_input, ABS_TILT_X, (char)frame[7]);
--- /dev/null
+From fe7f8d73d1af19b678171170e4e5384deb57833d Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <jason.gerecke@wacom.com>
+Date: Tue, 7 May 2019 11:53:20 -0700
+Subject: HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact
+
+From: Jason Gerecke <jason.gerecke@wacom.com>
+
+commit fe7f8d73d1af19b678171170e4e5384deb57833d upstream.
+
+The Bluetooth reports from the 2nd-gen Intuos Pro have separate bits for
+indicating if the tip or eraser is in contact with the tablet. At the
+moment, only the tip contact bit controls the state of the BTN_TOUCH
+event. This prevents the eraser from working as expected. This commit
+changes the driver to send BTN_TOUCH whenever either the tip or eraser
+contact bit is set.
+
+Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
+Cc: <stable@vger.kernel.org> # 4.11+
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+Reviewed-by: Aaron Skomra <aaron.skomra@wacom.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom_wac.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -1275,7 +1275,7 @@ static void wacom_intuos_pro2_bt_pen(str
+ input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
+ input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
+
+- input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
++ input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x09);
+ input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
+ input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
+
--- /dev/null
+From akaher@vmware.com Thu Jun 20 16:25:33 2019
+From: Ajay Kaher <akaher@vmware.com>
+Date: Tue, 11 Jun 2019 02:22:17 +0530
+Subject: infiniband: fix race condition between infiniband mlx4, mlx5 driver and core dumping
+To: <aarcange@redhat.com>, <jannh@google.com>, <oleg@redhat.com>, <peterx@redhat.com>, <rppt@linux.ibm.com>, <jgg@mellanox.com>, <mhocko@suse.com>
+Cc: <yishaih@mellanox.com>, <dledford@redhat.com>, <sean.hefty@intel.com>, <hal.rosenstock@gmail.com>, <matanb@mellanox.com>, <leonro@mellanox.com>, <linux-rdma@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>, <akaher@vmware.com>, <srivatsab@vmware.com>, <amakhalov@vmware.com>
+Message-ID: <1560199937-23476-1-git-send-email-akaher@vmware.com>
+
+From: Ajay Kaher <akaher@vmware.com>
+
+This patch is the extension of following upstream commit to fix
+the race condition between get_task_mm() and core dumping
+for IB->mlx4 and IB->mlx5 drivers:
+
+commit 04f5866e41fb ("coredump: fix race condition between
+mmget_not_zero()/get_task_mm() and core dumping")'
+
+Thanks to Jason for pointing this.
+
+Signed-off-by: Ajay Kaher <akaher@vmware.com>
+Acked-by: Jason Gunthorpe <jgg@mellanox.com>
+---
+ drivers/infiniband/hw/mlx4/main.c | 4 +++-
+ drivers/infiniband/hw/mlx5/main.c | 3 +++
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/mlx4/main.c
++++ b/drivers/infiniband/hw/mlx4/main.c
+@@ -1197,6 +1197,8 @@ static void mlx4_ib_disassociate_ucontex
+ * mlx4_ib_vma_close().
+ */
+ down_write(&owning_mm->mmap_sem);
++ if (!mmget_still_valid(owning_mm))
++ goto skip_mm;
+ for (i = 0; i < HW_BAR_COUNT; i++) {
+ vma = context->hw_bar_info[i].vma;
+ if (!vma)
+@@ -1215,7 +1217,7 @@ static void mlx4_ib_disassociate_ucontex
+ /* context going to be destroyed, should not access ops any more */
+ context->hw_bar_info[i].vma->vm_ops = NULL;
+ }
+-
++skip_mm:
+ up_write(&owning_mm->mmap_sem);
+ mmput(owning_mm);
+ put_task_struct(owning_process);
+--- a/drivers/infiniband/hw/mlx5/main.c
++++ b/drivers/infiniband/hw/mlx5/main.c
+@@ -1646,6 +1646,8 @@ static void mlx5_ib_disassociate_ucontex
+ * mlx5_ib_vma_close.
+ */
+ down_write(&owning_mm->mmap_sem);
++ if (!mmget_still_valid(owning_mm))
++ goto skip_mm;
+ mutex_lock(&context->vma_private_list_mutex);
+ list_for_each_entry_safe(vma_private, n, &context->vma_private_list,
+ list) {
+@@ -1662,6 +1664,7 @@ static void mlx5_ib_disassociate_ucontex
+ kfree(vma_private);
+ }
+ mutex_unlock(&context->vma_private_list_mutex);
++skip_mm:
+ up_write(&owning_mm->mmap_sem);
+ mmput(owning_mm);
+ put_task_struct(owning_process);
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++++
+ drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++++
1 file changed, 4 insertions(+)
-diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
-index ab09f9e43c79..5c74787f903b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
-@@ -2505,6 +2505,10 @@ mlxsw_sp_port_set_link_ksettings(struct net_device *dev,
+@@ -2505,6 +2505,10 @@ mlxsw_sp_port_set_link_ksettings(struct
mlxsw_reg_ptys_eth_unpack(ptys_pl, ð_proto_cap, NULL, NULL);
autoneg = cmd->base.autoneg == AUTONEG_ENABLE;
eth_proto_new = autoneg ?
mlxsw_sp_to_ptys_advert_link(cmd) :
mlxsw_sp_to_ptys_speed(cmd->base.speed);
---
-2.20.1
-
scsi-scsi_dh_alua-fix-possible-null-ptr-deref.patch
scsi-libsas-delete-sas-port-if-expander-discover-fai.patch
mlxsw-spectrum-prevent-force-of-56g.patch
+hid-wacom-don-t-set-tool-type-until-we-re-in-range.patch
+hid-wacom-don-t-report-anything-prior-to-the-tool-entering-range.patch
+hid-wacom-send-btn_touch-in-response-to-intuosp2_bt-eraser-contact.patch
+coredump-fix-race-condition-between-collapse_huge_page-and-core-dumping.patch
+infiniband-fix-race-condition-between-infiniband-mlx4-mlx5-driver-and-core-dumping.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
