--- /dev/null
+From c0f4b163a03e73055dd734eaca64b9580e72e7fb Mon Sep 17 00:00:00 2001
+From: Sasha Neftin <sasha.neftin@intel.com>
+Date: Mon, 6 Nov 2017 08:31:59 +0200
+Subject: e1000e: fix the use of magic numbers for buffer overrun issue
+
+From: Sasha Neftin <sasha.neftin@intel.com>
+
+commit c0f4b163a03e73055dd734eaca64b9580e72e7fb upstream.
+
+This is a follow on to commit b10effb92e27 ("fix buffer overrun while the
+ I219 is processing DMA transactions") to address David Laights concerns
+about the use of "magic" numbers. So define masks as well as add
+additional code comments to give a better understanding of what needs to
+be done to avoid a buffer overrun.
+
+Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
+Reviewed-by: Alexander H Duyck <alexander.h.duyck@intel.com>
+Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
+Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 ++-
+ drivers/net/ethernet/intel/e1000e/netdev.c | 9 ++++++---
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
++++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
+@@ -113,7 +113,8 @@
+ #define NVM_SIZE_MULTIPLIER 4096 /*multiplier for NVMS field */
+ #define E1000_FLASH_BASE_ADDR 0xE000 /*offset of NVM access regs */
+ #define E1000_CTRL_EXT_NVMVS 0x3 /*NVM valid sector */
+-#define E1000_TARC0_CB_MULTIQ_3_REQ (1 << 28 | 1 << 29)
++#define E1000_TARC0_CB_MULTIQ_3_REQ 0x30000000
++#define E1000_TARC0_CB_MULTIQ_2_REQ 0x20000000
+ #define PCIE_ICH8_SNOOP_ALL PCIE_NO_SNOOP_ALL
+
+ #define E1000_ICH_RAR_ENTRIES 7
+--- a/drivers/net/ethernet/intel/e1000e/netdev.c
++++ b/drivers/net/ethernet/intel/e1000e/netdev.c
+@@ -3030,9 +3030,12 @@ static void e1000_configure_tx(struct e1
+ ew32(IOSFPC, reg_val);
+
+ reg_val = er32(TARC(0));
+- /* SPT and KBL Si errata workaround to avoid Tx hang */
+- reg_val &= ~BIT(28);
+- reg_val |= BIT(29);
++ /* SPT and KBL Si errata workaround to avoid Tx hang.
++ * Dropping the number of outstanding requests from
++ * 3 to 2 in order to avoid a buffer overrun.
++ */
++ reg_val &= ~E1000_TARC0_CB_MULTIQ_3_REQ;
++ reg_val |= E1000_TARC0_CB_MULTIQ_2_REQ;
+ ew32(TARC(0), reg_val);
+ }
+ }
--- /dev/null
+From 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 Mon Sep 17 00:00:00 2001
+From: Don Hiatt <don.hiatt@intel.com>
+Date: Mon, 2 Oct 2017 11:04:48 -0700
+Subject: IB/core: Do not warn on lid conversions for OPA
+
+From: Don Hiatt <don.hiatt@intel.com>
+
+commit 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 upstream.
+
+On OPA devices the user_mad recv_handler can receive 32Bit LIDs
+(e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits
+of the LID as this information is obtained elsewhere. Do not issue
+a warning when calling ib_lid_be16() in this case by masking out
+the upper 16Bits.
+
+[75667.310846] ------------[ cut here ]------------
+[75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad]
+[75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
+[75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1
+[75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
+[75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
+[75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000
+[75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad]
+[75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286
+[75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000
+[75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00
+[75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80
+[75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020
+[75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800
+[75667.499390] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
+[75667.509028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
+[75667.524664] Call Trace:
+[75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core]
+[75667.534031] ? ib_mark_mad_done+0x73/0xa0 [ib_core]
+[75667.540142] ib_mad_recv_done+0x423/0x9b0 [ib_core]
+[75667.546215] __ib_process_cq+0x5d/0xb0 [ib_core]
+[75667.552007] ib_cq_poll_work+0x20/0x60 [ib_core]
+[75667.557766] process_one_work+0x149/0x360
+[75667.562844] worker_thread+0x4d/0x3c0
+[75667.567529] kthread+0x109/0x140
+[75667.571713] ? rescuer_thread+0x380/0x380
+[75667.576775] ? kthread_park+0x60/0x60
+[75667.581447] ret_from_fork+0x25/0x30
+[75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
+[75667.608323] ---[ end trace cf26df27c9597264 ]---
+
+Fixes: 62ede7779904 ("Add OPA extended LID support")
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: Don Hiatt <don.hiatt@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/user_mad.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/core/user_mad.c
++++ b/drivers/infiniband/core/user_mad.c
+@@ -229,7 +229,16 @@ static void recv_handler(struct ib_mad_a
+ packet->mad.hdr.status = 0;
+ packet->mad.hdr.length = hdr_size(file) + mad_recv_wc->mad_len;
+ packet->mad.hdr.qpn = cpu_to_be32(mad_recv_wc->wc->src_qp);
+- packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid);
++ /*
++ * On OPA devices it is okay to lose the upper 16 bits of LID as this
++ * information is obtained elsewhere. Mask off the upper 16 bits.
++ */
++ if (agent->device->port_immutable[agent->port_num].core_cap_flags &
++ RDMA_CORE_PORT_INTEL_OPA)
++ packet->mad.hdr.lid = ib_lid_be16(0xFFFF &
++ mad_recv_wc->wc->slid);
++ else
++ packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid);
+ packet->mad.hdr.sl = mad_recv_wc->wc->sl;
+ packet->mad.hdr.path_bits = mad_recv_wc->wc->dlid_path_bits;
+ packet->mad.hdr.pkey_index = mad_recv_wc->wc->pkey_index;
--- /dev/null
+From 4988be5813ff2afdc0d8bfa315ef34a577d3efbf Mon Sep 17 00:00:00 2001
+From: Don Hiatt <don.hiatt@intel.com>
+Date: Mon, 2 Oct 2017 11:04:55 -0700
+Subject: IB/hfi1: Do not warn on lid conversions for OPA
+
+From: Don Hiatt <don.hiatt@intel.com>
+
+commit 4988be5813ff2afdc0d8bfa315ef34a577d3efbf upstream.
+
+On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID
+is Extended. In such cases, it is okay to lose the upper 16 bits of the
+LID as this information is obtained elsewhere. Do not issue a warning
+when calling ib_lid_cpu16() in this case by masking out the upper 16Bits.
+
+[75920.148985] ------------[ cut here ]------------
+[75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
+[75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
+[75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1
+[75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
+[75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
+[75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000
+[75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
+[75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206
+[75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80
+[75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80
+[75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8
+[75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001
+[75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800
+[75920.337849] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
+[75920.347450] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
+[75920.362947] Call Trace:
+[75920.366257] ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
+[75920.372457] ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
+[75920.378652] ? __kmalloc+0x1df/0x210
+[75920.383229] ib_mad_recv_done+0x305/0x9b0 [ib_core]
+[75920.389270] __ib_process_cq+0x5d/0xb0 [ib_core]
+[75920.395032] ib_cq_poll_work+0x20/0x60 [ib_core]
+[75920.400777] process_one_work+0x149/0x360
+[75920.405836] worker_thread+0x4d/0x3c0
+[75920.410505] kthread+0x109/0x140
+[75920.414681] ? rescuer_thread+0x380/0x380
+[75920.419731] ? kthread_park+0x60/0x60
+[75920.424406] ret_from_fork+0x25/0x30
+[75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff
+[75921.451269] ---[ end trace cf26df27c9597265 ]---
+
+Fixes: 62ede7779904 ("Add OPA extended LID support")
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: Don Hiatt <don.hiatt@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/hfi1/mad.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/hw/hfi1/mad.c
++++ b/drivers/infiniband/hw/hfi1/mad.c
+@@ -4293,7 +4293,6 @@ static int opa_local_smp_check(struct hf
+ const struct ib_wc *in_wc)
+ {
+ struct hfi1_pportdata *ppd = ppd_from_ibp(ibp);
+- u16 slid = ib_lid_cpu16(in_wc->slid);
+ u16 pkey;
+
+ if (in_wc->pkey_index >= ARRAY_SIZE(ppd->pkeys))
+@@ -4320,7 +4319,11 @@ static int opa_local_smp_check(struct hf
+ */
+ if (pkey == LIM_MGMT_P_KEY || pkey == FULL_MGMT_P_KEY)
+ return 0;
+- ingress_pkey_table_fail(ppd, pkey, slid);
++ /*
++ * On OPA devices it is okay to lose the upper 16 bits of LID as this
++ * information is obtained elsewhere. Mask off the upper 16 bits.
++ */
++ ingress_pkey_table_fail(ppd, pkey, ib_lid_cpu16(0xFFFF & in_wc->slid));
+ return 1;
+ }
+
--- /dev/null
+From 4ca59b14e588f873795a11cdc77a25c686a29d23 Mon Sep 17 00:00:00 2001
+From: Sandipan Das <sandipan@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 15:27:28 -0800
+Subject: include/linux/compiler-clang.h: handle randomizable anonymous structs
+
+From: Sandipan Das <sandipan@linux.vnet.ibm.com>
+
+commit 4ca59b14e588f873795a11cdc77a25c686a29d23 upstream.
+
+The GCC randomize layout plugin can randomize the member offsets of
+sensitive kernel data structures. To use this feature, certain
+annotations and members are added to the structures which affect the
+member offsets even if this plugin is not used.
+
+All of these structures are completely randomized, except for task_struct
+which leaves out some of its members. All the other members are wrapped
+within an anonymous struct with the __randomize_layout attribute. This is
+done using the randomized_struct_fields_start and
+randomized_struct_fields_end defines.
+
+When the plugin is disabled, the behaviour of this attribute can vary
+based on the GCC version. For GCC 5.1+, this attribute maps to
+__designated_init otherwise it is just an empty define but the anonymous
+structure is still present. For other compilers, both
+randomized_struct_fields_start and randomized_struct_fields_end default
+to empty defines meaning the anonymous structure is not introduced at
+all.
+
+So, if a module compiled with Clang, such as a BPF program, needs to
+access task_struct fields such as pid and comm, the offsets of these
+members as recognized by Clang are different from those recognized by
+modules compiled with GCC. If GCC 4.6+ is used to build the kernel,
+this can be solved by introducing appropriate defines for Clang so that
+the anonymous structure is seen when determining the offsets for the
+members.
+
+Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
+Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Kate Stewart <kstewart@linuxfoundation.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Cc: Alexei Starovoitov <ast@fb.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>
+
+---
+ include/linux/compiler-clang.h | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/include/linux/compiler-clang.h
++++ b/include/linux/compiler-clang.h
+@@ -16,3 +16,6 @@
+ * with any version that can compile the kernel
+ */
+ #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
++
++#define randomized_struct_fields_start struct {
++#define randomized_struct_fields_end };
--- /dev/null
+From 230b55fa8d64007339319539f8f8e68114d08529 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Tue, 17 Oct 2017 14:24:09 +1100
+Subject: md: forbid a RAID5 from having both a bitmap and a journal.
+
+From: NeilBrown <neilb@suse.com>
+
+commit 230b55fa8d64007339319539f8f8e68114d08529 upstream.
+
+Having both a bitmap and a journal is pointless.
+Attempting to do so can corrupt the bitmap if the journal
+replay happens before the bitmap is initialized.
+Rather than try to avoid this corruption, simply
+refuse to allow arrays with both a bitmap and a journal.
+So:
+ - if raid5_run sees both are present, fail.
+ - if adding a bitmap finds a journal is present, fail
+ - if adding a journal finds a bitmap is present, fail.
+
+Signed-off-by: NeilBrown <neilb@suse.com>
+Tested-by: Joshua Kinard <kumba@gentoo.org>
+Acked-by: Joshua Kinard <kumba@gentoo.org>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/bitmap.c | 6 ++++++
+ drivers/md/md.c | 2 +-
+ drivers/md/raid5.c | 7 +++++++
+ 3 files changed, 14 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/bitmap.c
++++ b/drivers/md/bitmap.c
+@@ -1816,6 +1816,12 @@ struct bitmap *bitmap_create(struct mdde
+
+ BUG_ON(file && mddev->bitmap_info.offset);
+
++ if (test_bit(MD_HAS_JOURNAL, &mddev->flags)) {
++ pr_notice("md/raid:%s: array with journal cannot have bitmap\n",
++ mdname(mddev));
++ return ERR_PTR(-EBUSY);
++ }
++
+ bitmap = kzalloc(sizeof(*bitmap), GFP_KERNEL);
+ if (!bitmap)
+ return ERR_PTR(-ENOMEM);
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -6362,7 +6362,7 @@ static int add_new_disk(struct mddev *md
+ break;
+ }
+ }
+- if (has_journal) {
++ if (has_journal || mddev->bitmap) {
+ export_rdev(rdev);
+ return -EBUSY;
+ }
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -7156,6 +7156,13 @@ static int raid5_run(struct mddev *mddev
+ min_offset_diff = diff;
+ }
+
++ if ((test_bit(MD_HAS_JOURNAL, &mddev->flags) || journal_dev) &&
++ (mddev->bitmap_info.offset || mddev->bitmap_info.file)) {
++ pr_notice("md/raid:%s: array cannot have both journal and bitmap\n",
++ mdname(mddev));
++ return -EINVAL;
++ }
++
+ if (mddev->reshape_position != MaxSector) {
+ /* Check that we can continue the reshape.
+ * Difficulties arise if the stripe we would write to
drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch
drm-amdgpu-move-uvd-vce-and-vcn-structure-out-from-union.patch
drm-amdgpu-set-adev-vcn.irq.num_types-for-vcn.patch
+include-linux-compiler-clang.h-handle-randomizable-anonymous-structs.patch
+ib-core-do-not-warn-on-lid-conversions-for-opa.patch
+ib-hfi1-do-not-warn-on-lid-conversions-for-opa.patch
+e1000e-fix-the-use-of-magic-numbers-for-buffer-overrun-issue.patch
+md-forbid-a-raid5-from-having-both-a-bitmap-and-a-journal.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
