[PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[Dennis Dalessandro]

Hi Doug,
There are a couple fixes in here that would have been nice to get into the RC
cycle, including one marked stable. However I think you will find them to be
too many LOC for an rc-4 submission so I have sent them in one series for-next.
Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not really that
important to the end user.

There are some clean ups in here from Don from the 16B changes. One takes care
of some sparse warnings and the other two are from a WARN_ON_ONCE that needed
special cased for OPA.

Patches can can also be found in my GitHub repo at:
https://github.com/ddalessa/kernel/tree/for-4.15

---

Don Hiatt (3):
      IB/core: Use __be32 for LIDs in opa_is_extended_lid
      IB/core: Do not warn on lid conversions for OPA
      IB/hfi1: Do not warn on lid conversions for OPA

Jakub Byczkowski (1):
      IB/hfi1: Add parsing for platform configuration format version 4

Michael J. Ruhl (1):
      IB/hfi1: Fix incorrect available receive user context count

Mike Marciniszyn (1):
      IB/hfi1: Fix output trace issues from 16B change

Sebastian Sanchez (2):
      IB/hfi1: Prevent LNI out of sync by resetting host interface version
      IB/rdmavt: Correct issues with read-mostly and send size cache lines


 drivers/infiniband/core/user_mad.c        |   11 +++
 drivers/infiniband/hw/hfi1/chip.c         |  112 +++++++++++++++++++----------
 drivers/infiniband/hw/hfi1/chip.h         |    1 
 drivers/infiniband/hw/hfi1/firmware.c     |   87 ++++++++++++++++++-----
 drivers/infiniband/hw/hfi1/hfi.h          |    3 +
 drivers/infiniband/hw/hfi1/mad.c          |    7 +-
 drivers/infiniband/hw/hfi1/sysfs.c        |    2 -
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h |    5 +
 drivers/infiniband/hw/hfi1/vnic_main.c    |    7 +-
 include/rdma/opa_addr.h                   |    6 +-
 include/rdma/rdmavt_qp.h                  |    6 +-
 11 files changed, 177 insertions(+), 70 deletions(-)

[PATCH for-next 1/8] IB/hfi1: Add parsing for platform configuration format version 4

[Dennis Dalessandro]

From: Jakub Byczkowski <jakub.byczkowski-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Platform configuration format version 4, that didn't use the file
size field, is not parsed by the host driver. Only version 5 is
supported. Add logic in parsing procedure to determine what format
is being used and allow to read data from version 4 files.

Reviewed-by: Jan Sokolowski <jan.sokolowski-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Reviewed-by: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Jakub Byczkowski <jakub.byczkowski-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/firmware.c |   24 ++++++++++++++++++++++--
 1 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/firmware.c b/drivers/infiniband/hw/hfi1/firmware.c
index 5aea8f4..9471c40 100644
--- a/drivers/infiniband/hw/hfi1/firmware.c
+++ b/drivers/infiniband/hw/hfi1/firmware.c
@@ -113,6 +113,12 @@ struct css_header {
 #define MU_SIZE		8
 #define EXPONENT_SIZE	4
 
+/* size of platform configuration partition */
+#define MAX_PLATFORM_CONFIG_FILE_SIZE 4096
+
+/* size of file of plaform configuration encoded in format version 4 */
+#define PLATFORM_CONFIG_FORMAT_4_FILE_SIZE 528
+
 /* the file itself */
 struct firmware_file {
 	struct css_header css_header;
@@ -1774,7 +1780,20 @@ int parse_platform_config(struct hfi1_devdata *dd)
 
 	/* Field is file size in DWORDs */
 	file_length = (*ptr) * 4;
-	ptr++;
+
+	/*
+	 * Length can't be larger than partition size. Assume platform
+	 * config format version 4 is being used. Interpret the file size
+	 * field as header instead by not moving the pointer.
+	 */
+	if (file_length > MAX_PLATFORM_CONFIG_FILE_SIZE) {
+		dd_dev_info(dd,
+			    "%s:File length out of bounds, using alternative format\n",
+			    __func__);
+		file_length = PLATFORM_CONFIG_FORMAT_4_FILE_SIZE;
+	} else {
+		ptr++;
+	}
 
 	if (file_length > dd->platform_config.size) {
 		dd_dev_info(dd, "%s:File claims to be larger than read size\n",
@@ -1789,7 +1808,8 @@ int parse_platform_config(struct hfi1_devdata *dd)
 
 	/*
 	 * In both cases where we proceed, using the self-reported file length
-	 * is the safer option
+	 * is the safer option. In case of old format a predefined value is
+	 * being used.
 	 */
 	while (ptr < (u32 *)(dd->platform_config.data + file_length)) {
 		header1 = *ptr;

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 2/8] IB/hfi1: Fix output trace issues from 16B change

[Dennis Dalessandro]

From: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

The 16B changes to the output side of the header trace introduced
two issues:

1. An uninitialized field "l4" for 9B packets

   This field needs to be given a value of 0 for 9B
   packets to insure a correct 9B trace.

   The fix adds a new define to insure that there is a dummy
   default for 9B packets to insure the correct string
   is decoded.

2. Use of entry vs. __entry in field references

Fixes: Commit 863cf89d472f ("IB/hfi1: Add 16B trace support")
Reported-by: Kaike Wan <kaike.wan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Reviewed-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/hfi.h          |    1 +
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h |    5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/hfi.h b/drivers/infiniband/hw/hfi1/hfi.h
index cb74ae8..44a2c8f 100644
--- a/drivers/infiniband/hw/hfi1/hfi.h
+++ b/drivers/infiniband/hw/hfi1/hfi.h
@@ -390,6 +390,7 @@ struct hfi1_packet {
 /*
  * OPA 16B L2/L4 Encodings
  */
+#define OPA_16B_L4_9B		0x00
 #define OPA_16B_L2_TYPE		0x02
 #define OPA_16B_L4_IB_LOCAL	0x09
 #define OPA_16B_L4_IB_GLOBAL	0x0A
diff --git a/drivers/infiniband/hw/hfi1/trace_ibhdrs.h b/drivers/infiniband/hw/hfi1/trace_ibhdrs.h
index 6dd0d63..fb63127 100644
--- a/drivers/infiniband/hw/hfi1/trace_ibhdrs.h
+++ b/drivers/infiniband/hw/hfi1/trace_ibhdrs.h
@@ -334,7 +334,7 @@ void hfi1_trace_parse_16b_hdr(struct hfi1_16b_header *hdr,
 							 &__entry->dlid,
 							 &__entry->slid);
 
-				if (entry->l4 == OPA_16B_L4_IB_LOCAL)
+				if (__entry->l4 == OPA_16B_L4_IB_LOCAL)
 					ohdr = &opah->opah.u.oth;
 				else
 					ohdr = &opah->opah.u.l.oth;
@@ -348,6 +348,7 @@ void hfi1_trace_parse_16b_hdr(struct hfi1_16b_header *hdr,
 							 &__entry->psn,
 							 &__entry->qpn);
 			} else {
+				__entry->l4 = OPA_16B_L4_9B;
 				hfi1_trace_parse_9b_hdr(&opah->ibh, sc5,
 							&__entry->lnh,
 							&__entry->lver,
@@ -356,7 +357,7 @@ void hfi1_trace_parse_16b_hdr(struct hfi1_16b_header *hdr,
 							&__entry->len,
 							&__entry->dlid,
 							&__entry->slid);
-				if (entry->lnh == HFI1_LRH_BTH)
+				if (__entry->lnh == HFI1_LRH_BTH)
 					ohdr = &opah->ibh.u.oth;
 				else
 					ohdr = &opah->ibh.u.l.oth;

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 4/8] IB/hfi1: Prevent LNI out of sync by resetting host interface version

[Dennis Dalessandro]

From: Sebastian Sanchez <sebastian.sanchez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

When the link is disabled and re-enabled, the host version bit is not
set again, so the firmware behaves as though it’s interacting with an
old driver. This causes LNI to get out of sync. The host version bit
needs to be set at load_8051_firmware() and _dc_start(). Currently, it's
only set at load_8051_firmware().

Create a common function to set the bit with the intent to make the code
more maintainable in the future, set the host version bit at _dc_start()
and modify the 8051 command API to prevent a deadlock as _dc_start() is
already holding the dc8051 lock.

Fixes: 913cc67159bc ("IB/hfi1: Always perform offline transition")
Reviewed-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Sebastian Sanchez <sebastian.sanchez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/chip.c     |   77 +++++++++++++++++++++++----------
 drivers/infiniband/hw/hfi1/chip.h     |    1 
 drivers/infiniband/hw/hfi1/firmware.c |   63 ++++++++++++++++++++-------
 3 files changed, 101 insertions(+), 40 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index 764a066..56bba8d 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -6520,12 +6520,11 @@ static void _dc_start(struct hfi1_devdata *dd)
 	if (!dd->dc_shutdown)
 		return;
 
-	/* Take the 8051 out of reset */
-	write_csr(dd, DC_DC8051_CFG_RST, 0ull);
-	/* Wait until 8051 is ready */
-	if (wait_fm_ready(dd, TIMEOUT_8051_START))
-		dd_dev_err(dd, "%s: timeout starting 8051 firmware\n",
-			   __func__);
+	/*
+	 * Take the 8051 out of reset, wait until 8051 is ready, and set host
+	 * version bit.
+	 */
+	release_and_wait_ready_8051_firmware(dd);
 
 	/* Take away reset for LCB and RX FPE (set in lcb_shutdown). */
 	write_csr(dd, DCC_CFG_RESET, 0x10);
@@ -8595,30 +8594,23 @@ int write_lcb_csr(struct hfi1_devdata *dd, u32 addr, u64 data)
 }
 
 /*
+ * If the 8051 is in reset mode (dd->dc_shutdown == 1), this function
+ * will still continue executing.
+ *
  * Returns:
  *	< 0 = Linux error, not able to get access
  *	> 0 = 8051 command RETURN_CODE
  */
-static int do_8051_command(
-	struct hfi1_devdata *dd,
-	u32 type,
-	u64 in_data,
-	u64 *out_data)
+static int _do_8051_command(struct hfi1_devdata *dd, u32 type, u64 in_data,
+			    u64 *out_data)
 {
 	u64 reg, completed;
 	int return_code;
 	unsigned long timeout;
 
+	lockdep_assert_held(&dd->dc8051_lock);
 	hfi1_cdbg(DC8051, "type %d, data 0x%012llx", type, in_data);
 
-	mutex_lock(&dd->dc8051_lock);
-
-	/* We can't send any commands to the 8051 if it's in reset */
-	if (dd->dc_shutdown) {
-		return_code = -ENODEV;
-		goto fail;
-	}
-
 	/*
 	 * If an 8051 host command timed out previously, then the 8051 is
 	 * stuck.
@@ -8719,6 +8711,29 @@ static int do_8051_command(
 	write_csr(dd, DC_DC8051_CFG_HOST_CMD_0, 0);
 
 fail:
+	return return_code;
+}
+
+/*
+ * Returns:
+ *	< 0 = Linux error, not able to get access
+ *	> 0 = 8051 command RETURN_CODE
+ */
+static int do_8051_command(struct hfi1_devdata *dd, u32 type, u64 in_data,
+			   u64 *out_data)
+{
+	int return_code;
+
+	mutex_lock(&dd->dc8051_lock);
+	/* We can't send any commands to the 8051 if it's in reset */
+	if (dd->dc_shutdown) {
+		return_code = -ENODEV;
+		goto fail;
+	}
+
+	return_code = _do_8051_command(dd, type, in_data, out_data);
+
+fail:
 	mutex_unlock(&dd->dc8051_lock);
 	return return_code;
 }
@@ -8728,16 +8743,17 @@ static int set_physical_link_state(struct hfi1_devdata *dd, u64 state)
 	return do_8051_command(dd, HCMD_CHANGE_PHY_STATE, state, NULL);
 }
 
-int load_8051_config(struct hfi1_devdata *dd, u8 field_id,
-		     u8 lane_id, u32 config_data)
+int _load_8051_config(struct hfi1_devdata *dd, u8 field_id,
+		      u8 lane_id, u32 config_data)
 {
 	u64 data;
 	int ret;
 
+	lockdep_assert_held(&dd->dc8051_lock);
 	data = (u64)field_id << LOAD_DATA_FIELD_ID_SHIFT
 		| (u64)lane_id << LOAD_DATA_LANE_ID_SHIFT
 		| (u64)config_data << LOAD_DATA_DATA_SHIFT;
-	ret = do_8051_command(dd, HCMD_LOAD_CONFIG_DATA, data, NULL);
+	ret = _do_8051_command(dd, HCMD_LOAD_CONFIG_DATA, data, NULL);
 	if (ret != HCMD_SUCCESS) {
 		dd_dev_err(dd,
 			   "load 8051 config: field id %d, lane %d, err %d\n",
@@ -8746,6 +8762,18 @@ int load_8051_config(struct hfi1_devdata *dd, u8 field_id,
 	return ret;
 }
 
+int load_8051_config(struct hfi1_devdata *dd, u8 field_id,
+		     u8 lane_id, u32 config_data)
+{
+	int return_code;
+
+	mutex_lock(&dd->dc8051_lock);
+	return_code = _load_8051_config(dd, field_id, lane_id, config_data);
+	mutex_unlock(&dd->dc8051_lock);
+
+	return return_code;
+}
+
 /*
  * Read the 8051 firmware "registers".  Use the RAM directly.  Always
  * set the result, even on error.
@@ -8861,13 +8889,14 @@ int write_host_interface_version(struct hfi1_devdata *dd, u8 version)
 	u32 frame;
 	u32 mask;
 
+	lockdep_assert_held(&dd->dc8051_lock);
 	mask = (HOST_INTERFACE_VERSION_MASK << HOST_INTERFACE_VERSION_SHIFT);
 	read_8051_config(dd, RESERVED_REGISTERS, GENERAL_CONFIG, &frame);
 	/* Clear, then set field */
 	frame &= ~mask;
 	frame |= ((u32)version << HOST_INTERFACE_VERSION_SHIFT);
-	return load_8051_config(dd, RESERVED_REGISTERS, GENERAL_CONFIG,
-				frame);
+	return _load_8051_config(dd, RESERVED_REGISTERS, GENERAL_CONFIG,
+				 frame);
 }
 
 void read_misc_status(struct hfi1_devdata *dd, u8 *ver_major, u8 *ver_minor,
diff --git a/drivers/infiniband/hw/hfi1/chip.h b/drivers/infiniband/hw/hfi1/chip.h
index 50b8645..213b6a3 100644
--- a/drivers/infiniband/hw/hfi1/chip.h
+++ b/drivers/infiniband/hw/hfi1/chip.h
@@ -710,6 +710,7 @@ void read_misc_status(struct hfi1_devdata *dd, u8 *ver_major, u8 *ver_minor,
 		      u8 *ver_patch);
 int write_host_interface_version(struct hfi1_devdata *dd, u8 version);
 void read_guid(struct hfi1_devdata *dd);
+int release_and_wait_ready_8051_firmware(struct hfi1_devdata *dd);
 int wait_fm_ready(struct hfi1_devdata *dd, u32 mstimeout);
 void set_link_down_reason(struct hfi1_pportdata *ppd, u8 lcl_reason,
 			  u8 neigh_reason, u8 rem_reason);
diff --git a/drivers/infiniband/hw/hfi1/firmware.c b/drivers/infiniband/hw/hfi1/firmware.c
index 9471c40..dee3c67 100644
--- a/drivers/infiniband/hw/hfi1/firmware.c
+++ b/drivers/infiniband/hw/hfi1/firmware.c
@@ -971,6 +971,46 @@ int wait_fm_ready(struct hfi1_devdata *dd, u32 mstimeout)
 }
 
 /*
+ * Clear all reset bits, releasing the 8051.
+ * Wait for firmware to be ready to accept host requests.
+ * Then, set host version bit.
+ *
+ * This function executes even if the 8051 is in reset mode when
+ * dd->dc_shutdown == 1.
+ *
+ * Expects dd->dc8051_lock to be held.
+ */
+int release_and_wait_ready_8051_firmware(struct hfi1_devdata *dd)
+{
+	int ret;
+
+	lockdep_assert_held(&dd->dc8051_lock);
+	/* clear all reset bits, releasing the 8051 */
+	write_csr(dd, DC_DC8051_CFG_RST, 0ull);
+
+	/*
+	 * Wait for firmware to be ready to accept host
+	 * requests.
+	 */
+	ret = wait_fm_ready(dd, TIMEOUT_8051_START);
+	if (ret) {
+		dd_dev_err(dd, "8051 start timeout, current FW state 0x%x\n",
+			   get_firmware_state(dd));
+		return ret;
+	}
+
+	ret = write_host_interface_version(dd, HOST_INTERFACE_VERSION);
+	if (ret != HCMD_SUCCESS) {
+		dd_dev_err(dd,
+			   "Failed to set host interface version, return 0x%x\n",
+			   ret);
+		return -EIO;
+	}
+
+	return 0;
+}
+
+/*
  * Load the 8051 firmware.
  */
 static int load_8051_firmware(struct hfi1_devdata *dd,
@@ -1035,31 +1075,22 @@ static int load_8051_firmware(struct hfi1_devdata *dd,
 	if (ret)
 		return ret;
 
-	/* clear all reset bits, releasing the 8051 */
-	write_csr(dd, DC_DC8051_CFG_RST, 0ull);
-
 	/*
+	 * Clear all reset bits, releasing the 8051.
 	 * DC reset step 5. Wait for firmware to be ready to accept host
 	 * requests.
+	 * Then, set host version bit.
 	 */
-	ret = wait_fm_ready(dd, TIMEOUT_8051_START);
-	if (ret) { /* timed out */
-		dd_dev_err(dd, "8051 start timeout, current state 0x%x\n",
-			   get_firmware_state(dd));
-		return -ETIMEDOUT;
-	}
+	mutex_lock(&dd->dc8051_lock);
+	ret = release_and_wait_ready_8051_firmware(dd);
+	mutex_unlock(&dd->dc8051_lock);
+	if (ret)
+		return ret;
 
 	read_misc_status(dd, &ver_major, &ver_minor, &ver_patch);
 	dd_dev_info(dd, "8051 firmware version %d.%d.%d\n",
 		    (int)ver_major, (int)ver_minor, (int)ver_patch);
 	dd->dc8051_ver = dc8051_ver(ver_major, ver_minor, ver_patch);
-	ret = write_host_interface_version(dd, HOST_INTERFACE_VERSION);
-	if (ret != HCMD_SUCCESS) {
-		dd_dev_err(dd,
-			   "Failed to set host interface version, return 0x%x\n",
-			   ret);
-		return -EIO;
-	}
 
 	return 0;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Dennis Dalessandro]

From: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

The LIDs passed to opa_extended_lid are in __be32 format,
change function signature accordingly.

This fixes the following sparse warnings:
  drivers/infiniband/core/cm.c:1181:60: warning: incorrect type in
	argument 1 (different ba
  drivers/infiniband/core/cm.c:1182:60: warning: incorrect type in
	argument 2 (different ba
  drivers/infiniband/core/cm.c:1242:68: warning: incorrect type in
	argument 1 (different ba
  drivers/infiniband/core/cm.c:1243:68: warning: incorrect type in
	argument 2 (different ba
  drivers/infiniband/core/cm.c:2922:66: warning: incorrect type in
	argument 1 (different ba
  drivers/infiniband/core/cm.c:2923:66: warning: incorrect type in
	argument 2 (different ba
  include/rdma/opa_addr.h:102:14: warning: cast to restricted __be32

Fixes: e92aa00a5189 ("IB/CM: Add OPA Path record support to CM")
Reviewed-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/rdma/opa_addr.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/rdma/opa_addr.h b/include/rdma/opa_addr.h
index e6e90f1..f68fca2 100644
--- a/include/rdma/opa_addr.h
+++ b/include/rdma/opa_addr.h
@@ -97,15 +97,15 @@ static inline u32 opa_get_lid_from_gid(const union ib_gid *gid)
  * @dlid: The DLID
  * @slid: The SLID
  */
-static inline bool opa_is_extended_lid(u32 dlid, u32 slid)
+static inline bool opa_is_extended_lid(__be32 dlid, __be32 slid)
 {
 	if ((be32_to_cpu(dlid) >=
 	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
 	    (be32_to_cpu(slid) >=
 	     be16_to_cpu(IB_MULTICAST_LID_BASE)))
 		return true;
-	else
-		return false;
+
+	return false;
 }
 
 /* Get multicast lid base */

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Mon, Oct 02, 2017 at 11:04:33AM -0700, Dennis Dalessandro wrote:
> From: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> The LIDs passed to opa_extended_lid are in __be32 format,
> change function signature accordingly.
>
> This fixes the following sparse warnings:
>   drivers/infiniband/core/cm.c:1181:60: warning: incorrect type in
> 	argument 1 (different ba
>   drivers/infiniband/core/cm.c:1182:60: warning: incorrect type in
> 	argument 2 (different ba
>   drivers/infiniband/core/cm.c:1242:68: warning: incorrect type in
> 	argument 1 (different ba
>   drivers/infiniband/core/cm.c:1243:68: warning: incorrect type in
> 	argument 2 (different ba
>   drivers/infiniband/core/cm.c:2922:66: warning: incorrect type in
> 	argument 1 (different ba
>   drivers/infiniband/core/cm.c:2923:66: warning: incorrect type in
> 	argument 2 (different ba
>   include/rdma/opa_addr.h:102:14: warning: cast to restricted __be32
>
> Fixes: e92aa00a5189 ("IB/CM: Add OPA Path record support to CM")
> Reviewed-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  include/rdma/opa_addr.h |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/rdma/opa_addr.h b/include/rdma/opa_addr.h
> index e6e90f1..f68fca2 100644
> --- a/include/rdma/opa_addr.h
> +++ b/include/rdma/opa_addr.h
> @@ -97,15 +97,15 @@ static inline u32 opa_get_lid_from_gid(const union ib_gid *gid)
>   * @dlid: The DLID
>   * @slid: The SLID
>   */
> -static inline bool opa_is_extended_lid(u32 dlid, u32 slid)
> +static inline bool opa_is_extended_lid(__be32 dlid, __be32 slid)
>  {
>  	if ((be32_to_cpu(dlid) >=
>  	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
>  	    (be32_to_cpu(slid) >=
>  	     be16_to_cpu(IB_MULTICAST_LID_BASE)))

You can drop be32_to_cpu and be16_to_cpu now.
The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct
comparison will work.

>  		return true;
> -	else
> -		return false;
> +
> +	return false;
>  }
>
>  /* Get multicast lid base */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Jason Gunthorpe]

On Tue, Oct 03, 2017 at 09:16:57AM +0300, Leon Romanovsky wrote:

> > -static inline bool opa_is_extended_lid(u32 dlid, u32 slid)
> > +static inline bool opa_is_extended_lid(__be32 dlid, __be32 slid)
> >  {
> >  	if ((be32_to_cpu(dlid) >=
> >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
> >  	    (be32_to_cpu(slid) >=
> >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)))
> 
> You can drop be32_to_cpu and be16_to_cpu now.
> The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct
> comparison will work.

It won't order properly for >=, the swap is still needed...

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Tue, Oct 03, 2017 at 10:00:59AM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 03, 2017 at 09:16:57AM +0300, Leon Romanovsky wrote:
>
> > > -static inline bool opa_is_extended_lid(u32 dlid, u32 slid)
> > > +static inline bool opa_is_extended_lid(__be32 dlid, __be32 slid)
> > >  {
> > >  	if ((be32_to_cpu(dlid) >=
> > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
> > >  	    (be32_to_cpu(slid) >=
> > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)))
> >
> > You can drop be32_to_cpu and be16_to_cpu now.
> > The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct
> > comparison will work.
>
> It won't order properly for >=, the swap is still needed...

Jason,
Do you have reference for that?

I tried to find any information about comparison of values from one
endianess on machine with another endianess and didn't find anything
relevant.

Thanks

>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Hefty, Sean]

> > > >  	if ((be32_to_cpu(dlid) >=
> > > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
> > > >  	    (be32_to_cpu(slid) >=
> > > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)))
> > >
> > > You can drop be32_to_cpu and be16_to_cpu now.
> > > The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct
> > > comparison will work.
> >
> > It won't order properly for >=, the swap is still needed...
> 
> Jason,
> Do you have reference for that?
> 
> I tried to find any information about comparison of values from one
> endianess on machine with another endianess and didn't find anything
> relevant.

The bytes are out of order, so the comparisons won't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

On Tue, Oct 03, 2017 at 05:05:06PM +0000, Hefty, Sean wrote:
> > > > >  	if ((be32_to_cpu(dlid) >=
> > > > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
> > > > >  	    (be32_to_cpu(slid) >=
> > > > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)))
> > > >
> > > > You can drop be32_to_cpu and be16_to_cpu now.
> > > > The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct
> > > > comparison will work.
> > >
> > > It won't order properly for >=, the swap is still needed...
> >
> > Jason,
> > Do you have reference for that?
> >
> > I tried to find any information about comparison of values from one
> > endianess on machine with another endianess and didn't find anything
> > relevant.
>
> The bytes are out of order, so the comparisons won't work.

I understand it for the "manual" comparison (C-like arrays), but does it apply
for the compiler-aware comparison? Both these variables are marked as
__be32 for the compiler.

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

On Tue, Oct 03, 2017 at 09:07:35PM +0300, Leon Romanovsky wrote:
> On Tue, Oct 03, 2017 at 05:05:06PM +0000, Hefty, Sean wrote:
> > > > > >  	if ((be32_to_cpu(dlid) >=
> > > > > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)) ||
> > > > > >  	    (be32_to_cpu(slid) >=
> > > > > >  	     be16_to_cpu(IB_MULTICAST_LID_BASE)))
> > > > >
> > > > > You can drop be32_to_cpu and be16_to_cpu now.
> > > > > The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct
> > > > > comparison will work.
> > > >
> > > > It won't order properly for >=, the swap is still needed...
> > >
> > > Jason,
> > > Do you have reference for that?
> > >
> > > I tried to find any information about comparison of values from one
> > > endianess on machine with another endianess and didn't find anything
> > > relevant.
> >
> > The bytes are out of order, so the comparisons won't work.
>
> I understand it for the "manual" comparison (C-like arrays), but does it apply
> for the compiler-aware comparison? Both these variables are marked as
> __be32 for the compiler.

OK, I finally found time to test my question and you and Jason are right.
Thank you for your time.

For curious readers, the snippet below, tested on x86:

diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index bcc4c2db81d0..234105716120 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -4754,6 +4754,15 @@ static int __init mlx5_ib_init(void)
 {
 	int err;

+	uint32_t u1 = 0x2233;
+	uint32_t u2 = 0x4411;
+
+	__be32 b1 = cpu_to_be32(u1);
+	__be32 b2 = cpu_to_be32(u2);
+
+	printk(KERN_ERR "test: u1 %s u1\n", (u1 < u2 ) ? "<":">");
+	printk(KERN_ERR "test: b1 %s b1\n", (b1 < b2 ) ? "<":">");
+
 	mlx5_ib_odp_init();

 	err = mlx5_register_interface(&mlx5_ib_interface);

and the result:
[    6.566979] test: u1 < u1
[    6.567147] test: b1 > b1

Thanks

>
> Thanks



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH for-next 6/8] IB/rdmavt: Correct issues with read-mostly and send size cache lines

[Dennis Dalessandro]

From: Sebastian Sanchez <sebastian.sanchez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

The s_ahgpsn was incorrectly placed in the read-mostly section of the QP
and the s_curr_size and s_hdrwords are oversized. The misplaced
s_ahgpsn will cause the read-mostly cachelines to thrash.

Place s_ahgpsn in the send side cache lines and correctly size and
s_hdrwords and s_cur_size to keep the send side cachelines at the same
size.

Reviewed-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Sebastian Sanchez <sebastian.sanchez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/chip.c |    4 ++--
 include/rdma/rdmavt_qp.h          |    6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index 56bba8d..d2d72e0 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -8743,8 +8743,8 @@ static int set_physical_link_state(struct hfi1_devdata *dd, u64 state)
 	return do_8051_command(dd, HCMD_CHANGE_PHY_STATE, state, NULL);
 }
 
-int _load_8051_config(struct hfi1_devdata *dd, u8 field_id,
-		      u8 lane_id, u32 config_data)
+static int _load_8051_config(struct hfi1_devdata *dd, u8 field_id,
+			     u8 lane_id, u32 config_data)
 {
 	u64 data;
 	int ret;
diff --git a/include/rdma/rdmavt_qp.h b/include/rdma/rdmavt_qp.h
index 0eed3d8..89ab88c 100644
--- a/include/rdma/rdmavt_qp.h
+++ b/include/rdma/rdmavt_qp.h
@@ -282,7 +282,6 @@ struct rvt_qp {
 	u32 remote_qpn;
 	u32 qkey;               /* QKEY for this QP (for UD or RD) */
 	u32 s_size;             /* send work queue size */
-	u32 s_ahgpsn;           /* set to the psn in the copy of the header */
 
 	u16 pmtu;		/* decoded from path_mtu */
 	u8 log_pmtu;		/* shift for pmtu */
@@ -344,7 +343,6 @@ struct rvt_qp {
 	struct rvt_swqe *s_wqe;
 	struct rvt_sge_state s_sge;     /* current send request data */
 	struct rvt_mregion *s_rdma_mr;
-	u32 s_cur_size;         /* size of send packet in bytes */
 	u32 s_len;              /* total length of s_sge */
 	u32 s_rdma_read_len;    /* total length of s_rdma_read_sge */
 	u32 s_last_psn;         /* last response PSN processed */
@@ -358,8 +356,10 @@ struct rvt_qp {
 	u32 s_acked;            /* last un-ACK'ed entry */
 	u32 s_last;             /* last completed entry */
 	u32 s_lsn;              /* limit sequence number (credit) */
-	u16 s_hdrwords;         /* size of s_hdr in 32 bit words */
+	u32 s_ahgpsn;           /* set to the psn in the copy of the header */
+	u16 s_cur_size;         /* size of send packet in bytes */
 	u16 s_rdma_ack_cnt;
+	u8 s_hdrwords;         /* size of s_hdr in 32 bit words */
 	s8 s_ahgidx;
 	u8 s_state;             /* opcode of last packet sent */
 	u8 s_ack_state;         /* opcode of packet to ACK */

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 7/8] IB/core: Do not warn on lid conversions for OPA

[Dennis Dalessandro]

From: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/core/user_mad.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/infiniband/core/user_mad.c b/drivers/infiniband/core/user_mad.c
index c1696e6..603acaf 100644
--- 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_agent *agent,
 	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;

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 7/8] IB/core: Do not warn on lid conversions for OPA

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 3887 bytes --]

On Mon, Oct 02, 2017 at 11:04:48AM -0700, Dennis Dalessandro wrote:
> From: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/infiniband/core/user_mad.c |   11 ++++++++++-
>  1 files changed, 10 insertions(+), 1 deletions(-)

Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH for-next 8/8] IB/hfi1: Do not warn on lid conversions for OPA

[Dennis Dalessandro]

From: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/mad.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/mad.c b/drivers/infiniband/hw/hfi1/mad.c
index f4c0ffc..07b80fa 100644
--- 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 hfi1_ibport *ibp,
 			       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 hfi1_ibport *ibp,
 	 */
 	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;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 8/8] IB/hfi1: Do not warn on lid conversions for OPA

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 3940 bytes --]

On Mon, Oct 02, 2017 at 11:04:55AM -0700, Dennis Dalessandro wrote:
> From: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Don Hiatt <don.hiatt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/infiniband/hw/hfi1/mad.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
>

Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[Doug Ledford]

On Mon, 2017-10-02 at 11:03 -0700, Dennis Dalessandro wrote:
> Hi Doug,
> There are a couple fixes in here that would have been nice to get
> into the RC
> cycle, including one marked stable. However I think you will find
> them to be
> too many LOC for an rc-4 submission so I have sent them in one series
> for-next.
> Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not
> really that
> important to the end user.
> 
> There are some clean ups in here from Don from the 16B changes. One
> takes care
> of some sparse warnings and the other two are from a WARN_ON_ONCE
> that needed
> special cased for OPA.
> 
> Patches can can also be found in my GitHub repo at:
> https://github.com/ddalessa/kernel/tree/for-4.15

Hi Denny,

I didn't process that you mixed for-rc and for-next stuff in a single
thread before I had gone through and looked at the patches and
processed them.  So, this time they all went to for-next.  In the
future, you really need patches you want in for-rc separate from the
patches intended for for-next.

Anyway, applied.  And 2 and 5 are the only ones I would have been
likely to take to for-rc right now, and 2 isn't that important to the
end user as you say, so that just leaves 5, and it's sparse warnings,
so we'll just leave things as they are.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[Dennis Dalessandro]

On 10/4/2017 3:44 PM, Doug Ledford wrote:
> On Mon, 2017-10-02 at 11:03 -0700, Dennis Dalessandro wrote:
>> Hi Doug,
>> There are a couple fixes in here that would have been nice to get
>> into the RC
>> cycle, including one marked stable. However I think you will find
>> them to be
>> too many LOC for an rc-4 submission so I have sent them in one series
>> for-next.
>> Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not
>> really that
>> important to the end user.
>>
>> There are some clean ups in here from Don from the 16B changes. One
>> takes care
>> of some sparse warnings and the other two are from a WARN_ON_ONCE
>> that needed
>> special cased for OPA.
>>
>> Patches can can also be found in my GitHub repo at:
>> https://github.com/ddalessa/kernel/tree/for-4.15
> 
> Hi Denny,
> 
> I didn't process that you mixed for-rc and for-next stuff in a single
> thread before I had gone through and looked at the patches and
> processed them.  So, this time they all went to for-next.  In the
> future, you really need patches you want in for-rc separate from the
> patches intended for for-next.

Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So 
yep for-next was the right target.

I would have liked to get the fixes into -rc but they were just too 
complex for this late in the game is all I meant.

-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

On Wed, Oct 04, 2017 at 09:22:06PM -0400, Dennis Dalessandro wrote:
> On 10/4/2017 3:44 PM, Doug Ledford wrote:
> > On Mon, 2017-10-02 at 11:03 -0700, Dennis Dalessandro wrote:
> > > Hi Doug,
> > > There are a couple fixes in here that would have been nice to get
> > > into the RC
> > > cycle, including one marked stable. However I think you will find
> > > them to be
> > > too many LOC for an rc-4 submission so I have sent them in one series
> > > for-next.
> > > Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not
> > > really that
> > > important to the end user.
> > >
> > > There are some clean ups in here from Don from the 16B changes. One
> > > takes care
> > > of some sparse warnings and the other two are from a WARN_ON_ONCE
> > > that needed
> > > special cased for OPA.
> > >
> > > Patches can can also be found in my GitHub repo at:
> > > https://github.com/ddalessa/kernel/tree/for-4.15
> >
> > Hi Denny,
> >
> > I didn't process that you mixed for-rc and for-next stuff in a single
> > thread before I had gone through and looked at the patches and
> > processed them.  So, this time they all went to for-next.  In the
> > future, you really need patches you want in for-rc separate from the
> > patches intended for for-next.
>
> Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep
> for-next was the right target.
>
> I would have liked to get the fixes into -rc but they were just too complex
> for this late in the game is all I meant.

IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the
severity of fixes yes.

Thanks

>
> -Denny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[Dennis Dalessandro]

On 10/5/2017 3:04 AM, Leon Romanovsky wrote:
> On Wed, Oct 04, 2017 at 09:22:06PM -0400, Dennis Dalessandro wrote:
>> On 10/4/2017 3:44 PM, Doug Ledford wrote:
>>> On Mon, 2017-10-02 at 11:03 -0700, Dennis Dalessandro wrote:
>>>> Hi Doug,
>>>> There are a couple fixes in here that would have been nice to get
>>>> into the RC
>>>> cycle, including one marked stable. However I think you will find
>>>> them to be
>>>> too many LOC for an rc-4 submission so I have sent them in one series
>>>> for-next.
>>>> Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not
>>>> really that
>>>> important to the end user.
>>>>
>>>> There are some clean ups in here from Don from the 16B changes. One
>>>> takes care
>>>> of some sparse warnings and the other two are from a WARN_ON_ONCE
>>>> that needed
>>>> special cased for OPA.
>>>>
>>>> Patches can can also be found in my GitHub repo at:
>>>> https://github.com/ddalessa/kernel/tree/for-4.15
>>>
>>> Hi Denny,
>>>
>>> I didn't process that you mixed for-rc and for-next stuff in a single
>>> thread before I had gone through and looked at the patches and
>>> processed them.  So, this time they all went to for-next.  In the
>>> future, you really need patches you want in for-rc separate from the
>>> patches intended for for-next.
>>
>> Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep
>> for-next was the right target.
>>
>> I would have liked to get the fixes into -rc but they were just too complex
>> for this late in the game is all I meant.
> 
> IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the
> severity of fixes yes.

Not the gating factor necessarily, but a factor that has to be be 
weighed against the severity of the bug being fixed. As we get into 
later -rc cycles the bar for risk vs reward gets raised, not that there 
should be a limit of X LOC for -rc whatever it's more of an overall 
assessment of the risk of causing more harm than good.

-Denny

Re: [PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1196 bytes --]

On 10/5/2017 6:44 AM, Dennis Dalessandro wrote:
> On 10/5/2017 3:04 AM, Leon Romanovsky wrote:
>> On Wed, Oct 04, 2017 at 09:22:06PM -0400, Dennis Dalessandro wrote:
>>> Maybe I wasn't too clear, I didn't intend any of those to go for-rc.
>>> So yep
>>> for-next was the right target.

Ok.

>>> I would have liked to get the fixes into -rc but they were just too
>>> complex
>>> for this late in the game is all I meant.

Understood.

>> IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the
>> severity of fixes yes.
> 
> Not the gating factor necessarily, but a factor that has to be be
> weighed against the severity of the bug being fixed. As we get into
> later -rc cycles the bar for risk vs reward gets raised, not that there
> should be a limit of X LOC for -rc whatever it's more of an overall
> assessment of the risk of causing more harm than good.

Exactly.  And given the rc stage we are at now, and the complexity of
the fixes, you made the right call.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

[PATCH for-next 3/8] IB/hfi1: Fix incorrect available receive user context count

[Dennis Dalessandro]

From: Michael J. Ruhl <michael.j.ruhl@intel.com>

The addition of the VNIC contexts to num_rcv_contexts changes the
meaning of the sysfs value nctxts from available user contexts, to
user contexts + reserved VNIC contexts.

User applications that use nctxts are now broken.

Update the calculation so that VNIC contexts are used only if there are
hardware contexts available, and do not silently affect nctxts.

Update code to use the calculated VNIC context number.

Update the sysfs value nctxts to be available user contexts only.

Fixes: 2280740f01ae ("IB/hfi1: Virtual Network Interface Controller (VNIC) HW support")
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Niranjana Vishwanathapura <Niranjana.Vishwanathapura@intel.com>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Cc: <Stable@vger.kernel.org> #v4.12+
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
---
 drivers/infiniband/hw/hfi1/chip.c      |   35 +++++++++++++++++++-------------
 drivers/infiniband/hw/hfi1/hfi.h       |    2 ++
 drivers/infiniband/hw/hfi1/sysfs.c     |    2 +-
 drivers/infiniband/hw/hfi1/vnic_main.c |    7 +++++-
 4 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index 680cfd4..764a066 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -13076,7 +13076,7 @@ static int request_msix_irqs(struct hfi1_devdata *dd)
 	first_sdma = last_general;
 	last_sdma = first_sdma + dd->num_sdma;
 	first_rx = last_sdma;
-	last_rx = first_rx + dd->n_krcv_queues + HFI1_NUM_VNIC_CTXT;
+	last_rx = first_rx + dd->n_krcv_queues + dd->num_vnic_contexts;
 
 	/* VNIC MSIx interrupts get mapped when VNIC contexts are created */
 	dd->first_dyn_msix_idx = first_rx + dd->n_krcv_queues;
@@ -13282,8 +13282,9 @@ static int set_up_interrupts(struct hfi1_devdata *dd)
 	 *		slow source, SDMACleanupDone)
 	 *	N interrupts - one per used SDMA engine
 	 *	M interrupt - one per kernel receive context
+	 *	V interrupt - one for each VNIC context
 	 */
-	total = 1 + dd->num_sdma + dd->n_krcv_queues + HFI1_NUM_VNIC_CTXT;
+	total = 1 + dd->num_sdma + dd->n_krcv_queues + dd->num_vnic_contexts;
 
 	/* ask for MSI-X interrupts */
 	request = request_msix(dd, total);
@@ -13344,10 +13345,12 @@ static int set_up_interrupts(struct hfi1_devdata *dd)
  *                             in array of contexts
  *	freectxts  - number of free user contexts
  *	num_send_contexts - number of PIO send contexts being used
+ *	num_vnic_contexts - number of contexts reserved for VNIC
  */
 static int set_up_context_variables(struct hfi1_devdata *dd)
 {
 	unsigned long num_kernel_contexts;
+	u16 num_vnic_contexts = HFI1_NUM_VNIC_CTXT;
 	int total_contexts;
 	int ret;
 	unsigned ngroups;
@@ -13381,6 +13384,14 @@ static int set_up_context_variables(struct hfi1_devdata *dd)
 			   num_kernel_contexts);
 		num_kernel_contexts = dd->chip_send_contexts - num_vls - 1;
 	}
+
+	/* Accommodate VNIC contexts if possible */
+	if ((num_kernel_contexts + num_vnic_contexts) > dd->chip_rcv_contexts) {
+		dd_dev_err(dd, "No receive contexts available for VNIC\n");
+		num_vnic_contexts = 0;
+	}
+	total_contexts = num_kernel_contexts + num_vnic_contexts;
+
 	/*
 	 * User contexts:
 	 *	- default to 1 user context per real (non-HT) CPU core if
@@ -13390,19 +13401,16 @@ static int set_up_context_variables(struct hfi1_devdata *dd)
 		num_user_contexts =
 			cpumask_weight(&node_affinity.real_cpu_mask);
 
-	total_contexts = num_kernel_contexts + num_user_contexts;
-
 	/*
 	 * Adjust the counts given a global max.
 	 */
-	if (total_contexts > dd->chip_rcv_contexts) {
+	if (total_contexts + num_user_contexts > dd->chip_rcv_contexts) {
 		dd_dev_err(dd,
 			   "Reducing # user receive contexts to: %d, from %d\n",
-			   (int)(dd->chip_rcv_contexts - num_kernel_contexts),
+			   (int)(dd->chip_rcv_contexts - total_contexts),
 			   (int)num_user_contexts);
-		num_user_contexts = dd->chip_rcv_contexts - num_kernel_contexts;
 		/* recalculate */
-		total_contexts = num_kernel_contexts + num_user_contexts;
+		num_user_contexts = dd->chip_rcv_contexts - total_contexts;
 	}
 
 	/* each user context requires an entry in the RMT */
@@ -13415,25 +13423,24 @@ static int set_up_context_variables(struct hfi1_devdata *dd)
 			   user_rmt_reduced);
 		/* recalculate */
 		num_user_contexts = user_rmt_reduced;
-		total_contexts = num_kernel_contexts + num_user_contexts;
 	}
 
-	/* Accommodate VNIC contexts */
-	if ((total_contexts + HFI1_NUM_VNIC_CTXT) <= dd->chip_rcv_contexts)
-		total_contexts += HFI1_NUM_VNIC_CTXT;
+	total_contexts += num_user_contexts;
 
 	/* the first N are kernel contexts, the rest are user/vnic contexts */
 	dd->num_rcv_contexts = total_contexts;
 	dd->n_krcv_queues = num_kernel_contexts;
 	dd->first_dyn_alloc_ctxt = num_kernel_contexts;
+	dd->num_vnic_contexts = num_vnic_contexts;
 	dd->num_user_contexts = num_user_contexts;
 	dd->freectxts = num_user_contexts;
 	dd_dev_info(dd,
-		    "rcv contexts: chip %d, used %d (kernel %d, user %d)\n",
+		    "rcv contexts: chip %d, used %d (kernel %d, vnic %u, user %u)\n",
 		    (int)dd->chip_rcv_contexts,
 		    (int)dd->num_rcv_contexts,
 		    (int)dd->n_krcv_queues,
-		    (int)dd->num_rcv_contexts - dd->n_krcv_queues);
+		    dd->num_vnic_contexts,
+		    dd->num_user_contexts);
 
 	/*
 	 * Receive array allocation:
diff --git a/drivers/infiniband/hw/hfi1/hfi.h b/drivers/infiniband/hw/hfi1/hfi.h
index 44a2c8f..2f3c830 100644
--- a/drivers/infiniband/hw/hfi1/hfi.h
+++ b/drivers/infiniband/hw/hfi1/hfi.h
@@ -1049,6 +1049,8 @@ struct hfi1_devdata {
 	u64 z_send_schedule;
 
 	u64 __percpu *send_schedule;
+	/* number of reserved contexts for VNIC usage */
+	u16 num_vnic_contexts;
 	/* number of receive contexts in use by the driver */
 	u32 num_rcv_contexts;
 	/* number of pio send contexts in use by the driver */
diff --git a/drivers/infiniband/hw/hfi1/sysfs.c b/drivers/infiniband/hw/hfi1/sysfs.c
index 6d2702e..25e8673 100644
--- a/drivers/infiniband/hw/hfi1/sysfs.c
+++ b/drivers/infiniband/hw/hfi1/sysfs.c
@@ -543,7 +543,7 @@ static ssize_t show_nctxts(struct device *device,
 	 * give a more accurate picture of total contexts available.
 	 */
 	return scnprintf(buf, PAGE_SIZE, "%u\n",
-			 min(dd->num_rcv_contexts - dd->first_dyn_alloc_ctxt,
+			 min(dd->num_user_contexts,
 			     (u32)dd->sc_sizes[SC_USER].count));
 }
 
diff --git a/drivers/infiniband/hw/hfi1/vnic_main.c b/drivers/infiniband/hw/hfi1/vnic_main.c
index f419cbb..1a17708 100644
--- a/drivers/infiniband/hw/hfi1/vnic_main.c
+++ b/drivers/infiniband/hw/hfi1/vnic_main.c
@@ -840,6 +840,9 @@ struct net_device *hfi1_vnic_alloc_rn(struct ib_device *device,
 	struct rdma_netdev *rn;
 	int i, size, rc;
 
+	if (!dd->num_vnic_contexts)
+		return ERR_PTR(-ENOMEM);
+
 	if (!port_num || (port_num > dd->num_pports))
 		return ERR_PTR(-EINVAL);
 
@@ -848,7 +851,7 @@ struct net_device *hfi1_vnic_alloc_rn(struct ib_device *device,
 
 	size = sizeof(struct opa_vnic_rdma_netdev) + sizeof(*vinfo);
 	netdev = alloc_netdev_mqs(size, name, name_assign_type, setup,
-				  dd->chip_sdma_engines, HFI1_NUM_VNIC_CTXT);
+				  dd->chip_sdma_engines, dd->num_vnic_contexts);
 	if (!netdev)
 		return ERR_PTR(-ENOMEM);
 
@@ -856,7 +859,7 @@ struct net_device *hfi1_vnic_alloc_rn(struct ib_device *device,
 	vinfo = opa_vnic_dev_priv(netdev);
 	vinfo->dd = dd;
 	vinfo->num_tx_q = dd->chip_sdma_engines;
-	vinfo->num_rx_q = HFI1_NUM_VNIC_CTXT;
+	vinfo->num_rx_q = dd->num_vnic_contexts;
 	vinfo->netdev = netdev;
 	rn->free_rdma_netdev = hfi1_vnic_free_rn;
 	rn->set_id = hfi1_vnic_set_vesw_id;