* [PATCH AUTOSEL 4.14 08/27] IB/{qib, hfi1, rdmavt}: Correct ibv_devinfo max_mr value
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Josh Collier, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614203018.27686-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 35164f5259a47ea756fa1deb3e463ac2a4f10dc9 ]
The command 'ibv_devinfo -v' reports 0 for max_mr.
Fix by assigning the query values after the mr lkey_table has been built
rather than early on in the driver.
Fixes: 7b1e2099adc8 ("IB/rdmavt: Move memory registration into rdmavt")
Reviewed-by: Josh Collier <josh.d.collier@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/verbs.c | 2 --
drivers/infiniband/hw/qib/qib_verbs.c | 2 --
drivers/infiniband/sw/rdmavt/mr.c | 2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
index 2e8854ba18cf..f4372afa0e81 100644
--- a/drivers/infiniband/hw/hfi1/verbs.c
+++ b/drivers/infiniband/hw/hfi1/verbs.c
@@ -1400,8 +1400,6 @@ static void hfi1_fill_device_attr(struct hfi1_devdata *dd)
rdi->dparms.props.max_cq = hfi1_max_cqs;
rdi->dparms.props.max_ah = hfi1_max_ahs;
rdi->dparms.props.max_cqe = hfi1_max_cqes;
- rdi->dparms.props.max_mr = rdi->lkey_table.max;
- rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_pd = hfi1_max_pds;
rdi->dparms.props.max_qp_rd_atom = HFI1_MAX_RDMA_ATOMIC;
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c b/drivers/infiniband/hw/qib/qib_verbs.c
index 9d92aeb8d9a1..350bc29a066f 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -1495,8 +1495,6 @@ static void qib_fill_device_attr(struct qib_devdata *dd)
rdi->dparms.props.max_cq = ib_qib_max_cqs;
rdi->dparms.props.max_cqe = ib_qib_max_cqes;
rdi->dparms.props.max_ah = ib_qib_max_ahs;
- rdi->dparms.props.max_mr = rdi->lkey_table.max;
- rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_qp_rd_atom = QIB_MAX_RDMA_ATOMIC;
rdi->dparms.props.max_qp_init_rd_atom = 255;
diff --git a/drivers/infiniband/sw/rdmavt/mr.c b/drivers/infiniband/sw/rdmavt/mr.c
index e7013d2d4f0e..d5b51f4cb49a 100644
--- a/drivers/infiniband/sw/rdmavt/mr.c
+++ b/drivers/infiniband/sw/rdmavt/mr.c
@@ -96,6 +96,8 @@ int rvt_driver_mr_init(struct rvt_dev_info *rdi)
for (i = 0; i < rdi->lkey_table.max; i++)
RCU_INIT_POINTER(rdi->lkey_table.table[i], NULL);
+ rdi->dparms.props.max_mr = rdi->lkey_table.max;
+ rdi->dparms.props.max_fmr = rdi->lkey_table.max;
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 07/27] IB/hfi1: Insure freeze_work work_struct is canceled on shutdown
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Michael J . Ruhl, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614203018.27686-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 6d517353c70bb0818b691ca003afdcb5ee5ea44e ]
By code inspection, the freeze_work is never canceled.
Fix by adding a cancel_work_sync in the shutdown path to insure it is no
longer running.
Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index db33ad985a12..69a79fdfa23e 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -9823,6 +9823,7 @@ void hfi1_quiet_serdes(struct hfi1_pportdata *ppd)
/* disable the port */
clear_rcvctrl(dd, RCV_CTRL_RCV_PORT_ENABLE_SMASK);
+ cancel_work_sync(&ppd->freeze_work);
}
static inline int init_cpu_counters(struct hfi1_devdata *dd)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 06/27] IB/rdmavt: Fix alloc_qpn() WARN_ON()
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Kaike Wan, Dennis Dalessandro, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20190614203018.27686-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 2abae62a26a265129b364d8c1ef3be55e2c01309 ]
The qpn allocation logic has a WARN_ON() that intends to detect the use of
an index that will introduce bits in the lower order bits of the QOS bits
in the QPN.
Unfortunately, it has the following bugs:
- it misfires when wrapping QPN allocation for non-QOS
- it doesn't correctly detect low order QOS bits (despite the comment)
The WARN_ON() should not be applied to non-QOS (qos_shift == 1).
Additionally, it SHOULD test the qpn bits per the table below:
2 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, 0, 0, sc0], qp bit 1 always 0*
3-4 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, 0, sc1, sc0], qp bits [21] always 0
5-8 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, sc2, sc1, sc0] qp bits [321] always 0
Fix by qualifying the warning for qos_shift > 1 and producing the correct
mask to insure the above bits are zero without generating a superfluous
warning.
Fixes: 501edc42446e ("IB/rdmavt: Correct warning during QPN allocation")
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/sw/rdmavt/qp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/rdmavt/qp.c b/drivers/infiniband/sw/rdmavt/qp.c
index 22df09ae809e..b0309876f4bb 100644
--- a/drivers/infiniband/sw/rdmavt/qp.c
+++ b/drivers/infiniband/sw/rdmavt/qp.c
@@ -412,7 +412,8 @@ static int alloc_qpn(struct rvt_dev_info *rdi, struct rvt_qpn_table *qpt,
offset = qpt->incr | ((offset & 1) ^ 1);
}
/* there can be no set bits in low-order QoS bits */
- WARN_ON(offset & (BIT(rdi->dparms.qos_shift) - 1));
+ WARN_ON(rdi->dparms.qos_shift > 1 &&
+ offset & ((BIT(rdi->dparms.qos_shift - 1) - 1) << 1));
qpn = mk_qpn(qpt, map, offset);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 14/39] IB/hfi1: Validate page aligned for a given virtual address
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kamenee Arumugam, Michael J . Ruhl, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614202946.27385-1-sashal@kernel.org>
From: Kamenee Arumugam <kamenee.arumugam@intel.com>
[ Upstream commit 97736f36dbebf2cda2799db3b54717ba5b388255 ]
User applications can register memory regions for TID buffers that are not
aligned on page boundaries. Hfi1 is expected to pin those pages in memory
and cache the pages with mmu_rb. The rb tree will fail to insert pages
that are not aligned correctly.
Validate whether a given virtual address is page aligned before pinning.
Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Kamenee Arumugam <kamenee.arumugam@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/user_exp_rcv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/hw/hfi1/user_exp_rcv.c b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
index dbe7d14a5c76..4e986ca4dd35 100644
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
@@ -324,6 +324,9 @@ int hfi1_user_exp_rcv_setup(struct hfi1_filedata *fd,
u32 *tidlist = NULL;
struct tid_user_buf *tidbuf;
+ if (!PAGE_ALIGNED(tinfo->vaddr))
+ return -EINVAL;
+
tidbuf = kzalloc(sizeof(*tidbuf), GFP_KERNEL);
if (!tidbuf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 13/39] IB/{qib, hfi1, rdmavt}: Correct ibv_devinfo max_mr value
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Josh Collier, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614202946.27385-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 35164f5259a47ea756fa1deb3e463ac2a4f10dc9 ]
The command 'ibv_devinfo -v' reports 0 for max_mr.
Fix by assigning the query values after the mr lkey_table has been built
rather than early on in the driver.
Fixes: 7b1e2099adc8 ("IB/rdmavt: Move memory registration into rdmavt")
Reviewed-by: Josh Collier <josh.d.collier@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/verbs.c | 2 --
drivers/infiniband/hw/qib/qib_verbs.c | 2 --
drivers/infiniband/sw/rdmavt/mr.c | 2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
index 48692adbe811..27d9c4cefdc7 100644
--- a/drivers/infiniband/hw/hfi1/verbs.c
+++ b/drivers/infiniband/hw/hfi1/verbs.c
@@ -1418,8 +1418,6 @@ static void hfi1_fill_device_attr(struct hfi1_devdata *dd)
rdi->dparms.props.max_cq = hfi1_max_cqs;
rdi->dparms.props.max_ah = hfi1_max_ahs;
rdi->dparms.props.max_cqe = hfi1_max_cqes;
- rdi->dparms.props.max_mr = rdi->lkey_table.max;
- rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_pd = hfi1_max_pds;
rdi->dparms.props.max_qp_rd_atom = HFI1_MAX_RDMA_ATOMIC;
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c b/drivers/infiniband/hw/qib/qib_verbs.c
index 41babbc0db58..803c3544c75b 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -1495,8 +1495,6 @@ static void qib_fill_device_attr(struct qib_devdata *dd)
rdi->dparms.props.max_cq = ib_qib_max_cqs;
rdi->dparms.props.max_cqe = ib_qib_max_cqes;
rdi->dparms.props.max_ah = ib_qib_max_ahs;
- rdi->dparms.props.max_mr = rdi->lkey_table.max;
- rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_qp_rd_atom = QIB_MAX_RDMA_ATOMIC;
rdi->dparms.props.max_qp_init_rd_atom = 255;
diff --git a/drivers/infiniband/sw/rdmavt/mr.c b/drivers/infiniband/sw/rdmavt/mr.c
index 5819c9d6ffdc..39d101df229d 100644
--- a/drivers/infiniband/sw/rdmavt/mr.c
+++ b/drivers/infiniband/sw/rdmavt/mr.c
@@ -96,6 +96,8 @@ int rvt_driver_mr_init(struct rvt_dev_info *rdi)
for (i = 0; i < rdi->lkey_table.max; i++)
RCU_INIT_POINTER(rdi->lkey_table.table[i], NULL);
+ rdi->dparms.props.max_mr = rdi->lkey_table.max;
+ rdi->dparms.props.max_fmr = rdi->lkey_table.max;
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 12/39] IB/hfi1: Insure freeze_work work_struct is canceled on shutdown
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Michael J . Ruhl, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614202946.27385-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 6d517353c70bb0818b691ca003afdcb5ee5ea44e ]
By code inspection, the freeze_work is never canceled.
Fix by adding a cancel_work_sync in the shutdown path to insure it is no
longer running.
Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index b12c8ff8ed66..d8eb4dc04d69 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -9849,6 +9849,7 @@ void hfi1_quiet_serdes(struct hfi1_pportdata *ppd)
/* disable the port */
clear_rcvctrl(dd, RCV_CTRL_RCV_PORT_ENABLE_SMASK);
+ cancel_work_sync(&ppd->freeze_work);
}
static inline int init_cpu_counters(struct hfi1_devdata *dd)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 11/39] IB/rdmavt: Fix alloc_qpn() WARN_ON()
From: Sasha Levin @ 2019-06-14 20:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Kaike Wan, Dennis Dalessandro, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20190614202946.27385-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 2abae62a26a265129b364d8c1ef3be55e2c01309 ]
The qpn allocation logic has a WARN_ON() that intends to detect the use of
an index that will introduce bits in the lower order bits of the QOS bits
in the QPN.
Unfortunately, it has the following bugs:
- it misfires when wrapping QPN allocation for non-QOS
- it doesn't correctly detect low order QOS bits (despite the comment)
The WARN_ON() should not be applied to non-QOS (qos_shift == 1).
Additionally, it SHOULD test the qpn bits per the table below:
2 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, 0, 0, sc0], qp bit 1 always 0*
3-4 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, 0, sc1, sc0], qp bits [21] always 0
5-8 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, sc2, sc1, sc0] qp bits [321] always 0
Fix by qualifying the warning for qos_shift > 1 and producing the correct
mask to insure the above bits are zero without generating a superfluous
warning.
Fixes: 501edc42446e ("IB/rdmavt: Correct warning during QPN allocation")
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/sw/rdmavt/qp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/rdmavt/qp.c b/drivers/infiniband/sw/rdmavt/qp.c
index 5ce403c6cddb..7d03680afd91 100644
--- a/drivers/infiniband/sw/rdmavt/qp.c
+++ b/drivers/infiniband/sw/rdmavt/qp.c
@@ -412,7 +412,8 @@ static int alloc_qpn(struct rvt_dev_info *rdi, struct rvt_qpn_table *qpt,
offset = qpt->incr | ((offset & 1) ^ 1);
}
/* there can be no set bits in low-order QoS bits */
- WARN_ON(offset & (BIT(rdi->dparms.qos_shift) - 1));
+ WARN_ON(rdi->dparms.qos_shift > 1 &&
+ offset & ((BIT(rdi->dparms.qos_shift - 1) - 1) << 1));
qpn = mk_qpn(qpt, map, offset);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 24/59] IB/hfi1: Validate page aligned for a given virtual address
From: Sasha Levin @ 2019-06-14 20:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kamenee Arumugam, Michael J . Ruhl, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614202843.26941-1-sashal@kernel.org>
From: Kamenee Arumugam <kamenee.arumugam@intel.com>
[ Upstream commit 97736f36dbebf2cda2799db3b54717ba5b388255 ]
User applications can register memory regions for TID buffers that are not
aligned on page boundaries. Hfi1 is expected to pin those pages in memory
and cache the pages with mmu_rb. The rb tree will fail to insert pages
that are not aligned correctly.
Validate whether a given virtual address is page aligned before pinning.
Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Kamenee Arumugam <kamenee.arumugam@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/user_exp_rcv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/hw/hfi1/user_exp_rcv.c b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
index 0cd71ce7cc71..3592a9ec155e 100644
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
@@ -324,6 +324,9 @@ int hfi1_user_exp_rcv_setup(struct hfi1_filedata *fd,
u32 *tidlist = NULL;
struct tid_user_buf *tidbuf;
+ if (!PAGE_ALIGNED(tinfo->vaddr))
+ return -EINVAL;
+
tidbuf = kzalloc(sizeof(*tidbuf), GFP_KERNEL);
if (!tidbuf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 23/59] IB/{qib, hfi1, rdmavt}: Correct ibv_devinfo max_mr value
From: Sasha Levin @ 2019-06-14 20:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Josh Collier, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614202843.26941-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 35164f5259a47ea756fa1deb3e463ac2a4f10dc9 ]
The command 'ibv_devinfo -v' reports 0 for max_mr.
Fix by assigning the query values after the mr lkey_table has been built
rather than early on in the driver.
Fixes: 7b1e2099adc8 ("IB/rdmavt: Move memory registration into rdmavt")
Reviewed-by: Josh Collier <josh.d.collier@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/verbs.c | 2 --
drivers/infiniband/hw/qib/qib_verbs.c | 2 --
drivers/infiniband/sw/rdmavt/mr.c | 2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
index 55a56b3d7f83..ea68eeba3f22 100644
--- a/drivers/infiniband/hw/hfi1/verbs.c
+++ b/drivers/infiniband/hw/hfi1/verbs.c
@@ -1355,8 +1355,6 @@ static void hfi1_fill_device_attr(struct hfi1_devdata *dd)
rdi->dparms.props.max_cq = hfi1_max_cqs;
rdi->dparms.props.max_ah = hfi1_max_ahs;
rdi->dparms.props.max_cqe = hfi1_max_cqes;
- rdi->dparms.props.max_mr = rdi->lkey_table.max;
- rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_pd = hfi1_max_pds;
rdi->dparms.props.max_qp_rd_atom = HFI1_MAX_RDMA_ATOMIC;
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c b/drivers/infiniband/hw/qib/qib_verbs.c
index 5ff32d32c61c..2c4e569ce438 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -1459,8 +1459,6 @@ static void qib_fill_device_attr(struct qib_devdata *dd)
rdi->dparms.props.max_cq = ib_qib_max_cqs;
rdi->dparms.props.max_cqe = ib_qib_max_cqes;
rdi->dparms.props.max_ah = ib_qib_max_ahs;
- rdi->dparms.props.max_mr = rdi->lkey_table.max;
- rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_qp_rd_atom = QIB_MAX_RDMA_ATOMIC;
rdi->dparms.props.max_qp_init_rd_atom = 255;
diff --git a/drivers/infiniband/sw/rdmavt/mr.c b/drivers/infiniband/sw/rdmavt/mr.c
index 0bb6e39dd03a..b04d2173e3f4 100644
--- a/drivers/infiniband/sw/rdmavt/mr.c
+++ b/drivers/infiniband/sw/rdmavt/mr.c
@@ -96,6 +96,8 @@ int rvt_driver_mr_init(struct rvt_dev_info *rdi)
for (i = 0; i < rdi->lkey_table.max; i++)
RCU_INIT_POINTER(rdi->lkey_table.table[i], NULL);
+ rdi->dparms.props.max_mr = rdi->lkey_table.max;
+ rdi->dparms.props.max_fmr = rdi->lkey_table.max;
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 22/59] IB/hfi1: Insure freeze_work work_struct is canceled on shutdown
From: Sasha Levin @ 2019-06-14 20:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Michael J . Ruhl, Dennis Dalessandro,
Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20190614202843.26941-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 6d517353c70bb0818b691ca003afdcb5ee5ea44e ]
By code inspection, the freeze_work is never canceled.
Fix by adding a cancel_work_sync in the shutdown path to insure it is no
longer running.
Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index 9784c6c0d2ec..403e23c5d08f 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -9848,6 +9848,7 @@ void hfi1_quiet_serdes(struct hfi1_pportdata *ppd)
/* disable the port */
clear_rcvctrl(dd, RCV_CTRL_RCV_PORT_ENABLE_SMASK);
+ cancel_work_sync(&ppd->freeze_work);
}
static inline int init_cpu_counters(struct hfi1_devdata *dd)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 21/59] IB/rdmavt: Fix alloc_qpn() WARN_ON()
From: Sasha Levin @ 2019-06-14 20:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Kaike Wan, Dennis Dalessandro, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20190614202843.26941-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 2abae62a26a265129b364d8c1ef3be55e2c01309 ]
The qpn allocation logic has a WARN_ON() that intends to detect the use of
an index that will introduce bits in the lower order bits of the QOS bits
in the QPN.
Unfortunately, it has the following bugs:
- it misfires when wrapping QPN allocation for non-QOS
- it doesn't correctly detect low order QOS bits (despite the comment)
The WARN_ON() should not be applied to non-QOS (qos_shift == 1).
Additionally, it SHOULD test the qpn bits per the table below:
2 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, 0, 0, sc0], qp bit 1 always 0*
3-4 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, 0, sc1, sc0], qp bits [21] always 0
5-8 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
[ 0, 0, 0, 0, sc2, sc1, sc0] qp bits [321] always 0
Fix by qualifying the warning for qos_shift > 1 and producing the correct
mask to insure the above bits are zero without generating a superfluous
warning.
Fixes: 501edc42446e ("IB/rdmavt: Correct warning during QPN allocation")
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/sw/rdmavt/qp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/rdmavt/qp.c b/drivers/infiniband/sw/rdmavt/qp.c
index a34b9a2a32b6..a77436ee5ff7 100644
--- a/drivers/infiniband/sw/rdmavt/qp.c
+++ b/drivers/infiniband/sw/rdmavt/qp.c
@@ -594,7 +594,8 @@ static int alloc_qpn(struct rvt_dev_info *rdi, struct rvt_qpn_table *qpt,
offset = qpt->incr | ((offset & 1) ^ 1);
}
/* there can be no set bits in low-order QoS bits */
- WARN_ON(offset & (BIT(rdi->dparms.qos_shift) - 1));
+ WARN_ON(rdi->dparms.qos_shift > 1 &&
+ offset & ((BIT(rdi->dparms.qos_shift - 1) - 1) << 1));
qpn = mk_qpn(qpt, map, offset);
}
--
2.20.1
^ permalink raw reply related
* Re: RDMA: Clean destroy CQ in drivers do not return errors
From: Doug Ledford @ 2019-06-14 19:46 UTC (permalink / raw)
To: Colin Ian King, Leon Romanovsky, Gal Pressman, Dennis Dalessandro,
linux-rdma
Cc: linux-kernel
In-Reply-To: <68d62660-902c-ca49-20fd-32e92830faa7@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
On Fri, 2019-06-14 at 14:59 +0100, Colin Ian King wrote:
> Hi,
>
> Static analysis with Coverity reported an issue with the following
> commit:
>
> commit a52c8e2469c30cf7ac453d624aed9c168b23d1af
> Author: Leon Romanovsky <leonro@mellanox.com>
> Date: Tue May 28 14:37:28 2019 +0300
>
> RDMA: Clean destroy CQ in drivers do not return errors
>
> In function bnxt_re_destroy_cq() contains the following:
>
> if (!cq->umem)
> ib_umem_release(cq->umem);
Given that the original test that was replaced was:
if (!IS_ERR_OR_NULL(cq->umem))
we aren't really worried about a null cq, just that umem is valid. So,
the logic is inverted on the test (or possibly we shouldn't have
replaced !IS_ERR_OR_NULL(cq->umem) at all).
But on closer inspection, the bnxt_re specific portion of this patch
appears to have another problem in that it no longer checks the result
of bnxt_qplib_destroy_cq() yet it does nothing to keep that function
from failing.
Leon, can you send a followup fix?
> Coverity detects this as a deference after null check on the null
> pointer cq->umem:
>
> "var_deref_model: Passing null pointer cq->umem to ib_umem_release,
> which dereferences it"
>
> Is the logic inverted on that null check?
>
> Colin
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ipoib: show VF broadcast address
From: Doug Ledford @ 2019-06-14 17:46 UTC (permalink / raw)
To: Denis Kirjanov, davem; +Cc: netdev, linux-rdma, mkubecek
In-Reply-To: <20190614133249.18308-2-dkirjanov@suse.com>
[-- Attachment #1: Type: text/plain, Size: 5016 bytes --]
On Fri, 2019-06-14 at 15:32 +0200, Denis Kirjanov wrote:
> in IPoIB case we can't see a VF broadcast address for but
> can see for PF
>
> Before:
> 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
> state UP mode DEFAULT group default qlen 256
> link/infiniband
> 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
> 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
> vf 0 MAC 14:80:00:00:66:fe, spoof checking off, link-state
> disable,
> trust off, query_rss off
> ...
The above Before: output should be used as the After: portion of the
previous commit message. The previos commit does not fully resolve the
problem, but yet the commit message acts as though it does.
>
> After:
> 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
> state UP mode DEFAULT group default qlen 256
> link/infiniband
> 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
> 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
> vf 0 link/infiniband
> 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
> 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
> checking off, link-state disable, trust off, query_rss off
Ok, I get why the After: should have a valid broadcast. What I don't
get is why the Before: shows a MAC and the After: shows a
link/infiniband? What change in this patch is responsible for that
difference? I honestly expect, by reading this patch, that you would
have a MAC and Broadcast that look like Ethernet, not that the full
issue would be resolved.
> v1->v2: add the IFLA_VF_BROADCAST constant
> v2->v3: put IFLA_VF_BROADCAST at the end
> to avoid KABI breakage and set NLA_REJECT
> dev_setlink
>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> ---
> include/uapi/linux/if_link.h | 5 +++++
> net/core/rtnetlink.c | 5 +++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/include/uapi/linux/if_link.h
> b/include/uapi/linux/if_link.h
> index 5b225ff63b48..6f75bda2c2d7 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -694,6 +694,7 @@ enum {
> IFLA_VF_IB_NODE_GUID, /* VF Infiniband node GUID */
> IFLA_VF_IB_PORT_GUID, /* VF Infiniband port GUID */
> IFLA_VF_VLAN_LIST, /* nested list of vlans, option for
> QinQ */
> + IFLA_VF_BROADCAST, /* VF broadcast */
> __IFLA_VF_MAX,
> };
>
> @@ -704,6 +705,10 @@ struct ifla_vf_mac {
> __u8 mac[32]; /* MAX_ADDR_LEN */
> };
>
> +struct ifla_vf_broadcast {
> + __u8 broadcast[32];
> +};
> +
> struct ifla_vf_vlan {
> __u32 vf;
> __u32 vlan; /* 0 - 4095, 0 disables VLAN filter */
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index cec60583931f..8ac81630ab5c 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -908,6 +908,7 @@ static inline int rtnl_vfinfo_size(const struct
> net_device *dev,
> size += num_vfs *
> (nla_total_size(0) +
> nla_total_size(sizeof(struct ifla_vf_mac)) +
> + nla_total_size(sizeof(struct
> ifla_vf_broadcast)) +
> nla_total_size(sizeof(struct ifla_vf_vlan)) +
> nla_total_size(0) + /* nest IFLA_VF_VLAN_LIST
> */
> nla_total_size(MAX_VLAN_LIST_LEN *
> @@ -1197,6 +1198,7 @@ static noinline_for_stack int
> rtnl_fill_vfinfo(struct sk_buff *skb,
> struct ifla_vf_vlan vf_vlan;
> struct ifla_vf_rate vf_rate;
> struct ifla_vf_mac vf_mac;
> + struct ifla_vf_broadcast vf_broadcast;
> struct ifla_vf_info ivi;
>
> memset(&ivi, 0, sizeof(ivi));
> @@ -1231,6 +1233,7 @@ static noinline_for_stack int
> rtnl_fill_vfinfo(struct sk_buff *skb,
> vf_trust.vf = ivi.vf;
>
> memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
> + memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
> vf_vlan.vlan = ivi.vlan;
> vf_vlan.qos = ivi.qos;
> vf_vlan_info.vlan = ivi.vlan;
> @@ -1247,6 +1250,7 @@ static noinline_for_stack int
> rtnl_fill_vfinfo(struct sk_buff *skb,
> if (!vf)
> goto nla_put_vfinfo_failure;
> if (nla_put(skb, IFLA_VF_MAC, sizeof(vf_mac), &vf_mac) ||
> + nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast),
> &vf_broadcast) ||
> nla_put(skb, IFLA_VF_VLAN, sizeof(vf_vlan), &vf_vlan) ||
> nla_put(skb, IFLA_VF_RATE, sizeof(vf_rate),
> &vf_rate) ||
> @@ -1753,6 +1757,7 @@ static const struct nla_policy
> ifla_info_policy[IFLA_INFO_MAX+1] = {
>
> static const struct nla_policy ifla_vf_policy[IFLA_VF_MAX+1] = {
> [IFLA_VF_MAC] = { .len = sizeof(struct ifla_vf_mac)
> },
> + [IFLA_VF_BROADCAST] = { .type = NLA_REJECT },
> [IFLA_VF_VLAN] = { .len = sizeof(struct
> ifla_vf_vlan) },
> [IFLA_VF_VLAN_LIST] = { .type = NLA_NESTED },
> [IFLA_VF_TX_RATE] = { .len = sizeof(struct ifla_vf_tx_rate) },
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 03/16] drm/i915: stop using drm_pci_alloc
From: Ville Syrjälä @ 2019-06-14 16:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
"moderated list:ARM PORT" <linux-a>
In-Reply-To: <20190614134726.3827-4-hch@lst.de>
On Fri, Jun 14, 2019 at 03:47:13PM +0200, Christoph Hellwig wrote:
> Remove usage of the legacy drm PCI DMA wrappers, and with that the
> incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
> and SetPageReserved.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 30 +++++++++++++-------------
> drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 3 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ad01c92aaf74..8f2053c91aff 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -228,7 +228,6 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
> static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> {
> struct address_space *mapping = obj->base.filp->f_mapping;
> - drm_dma_handle_t *phys;
> struct sg_table *st;
> struct scatterlist *sg;
> char *vaddr;
> @@ -242,13 +241,13 @@ static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> * to handle all possible callers, and given typical object sizes,
> * the alignment of the buddy allocation will naturally match.
> */
> - phys = drm_pci_alloc(obj->base.dev,
> - roundup_pow_of_two(obj->base.size),
> - roundup_pow_of_two(obj->base.size));
> - if (!phys)
> + obj->phys_vaddr = dma_alloc_coherent(&obj->base.dev->pdev->dev,
> + roundup_pow_of_two(obj->base.size),
> + &obj->phys_handle, GFP_KERNEL);
> + if (!obj->phys_vaddr)
> return -ENOMEM;
>
> - vaddr = phys->vaddr;
> + vaddr = obj->phys_vaddr;
> for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
> struct page *page;
> char *src;
> @@ -286,18 +285,17 @@ static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> sg->offset = 0;
> sg->length = obj->base.size;
>
> - sg_dma_address(sg) = phys->busaddr;
> + sg_dma_address(sg) = obj->phys_handle;
> sg_dma_len(sg) = obj->base.size;
>
> - obj->phys_handle = phys;
> -
> __i915_gem_object_set_pages(obj, st, sg->length);
>
> return 0;
>
> err_phys:
> - drm_pci_free(obj->base.dev, phys);
> -
> + dma_free_coherent(&obj->base.dev->pdev->dev,
> + roundup_pow_of_two(obj->base.size), obj->phys_vaddr,
> + obj->phys_handle);
Need to undo the damage to obj->phys_vaddr here since
i915_gem_pwrite_ioctl() will now use that to determine if it's
dealing with a phys obj.
> return err;
> }
>
> @@ -335,7 +333,7 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
>
> if (obj->mm.dirty) {
> struct address_space *mapping = obj->base.filp->f_mapping;
> - char *vaddr = obj->phys_handle->vaddr;
> + char *vaddr = obj->phys_vaddr;
> int i;
>
> for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
> @@ -363,7 +361,9 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
> sg_free_table(pages);
> kfree(pages);
>
> - drm_pci_free(obj->base.dev, obj->phys_handle);
> + dma_free_coherent(&obj->base.dev->pdev->dev,
> + roundup_pow_of_two(obj->base.size), obj->phys_vaddr,
> + obj->phys_handle);
This one is fine I think since the object remains a phys obj once
turned into one. At least the current code isn't clearing
phys_handle here. But my memory is a bit hazy on the details. Chris?
Also maybe s/phys_handle/phys_busaddr/ all over?
> }
>
> static void
> @@ -603,7 +603,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> struct drm_i915_gem_pwrite *args,
> struct drm_file *file)
> {
> - void *vaddr = obj->phys_handle->vaddr + args->offset;
> + void *vaddr = obj->phys_vaddr + args->offset;
> char __user *user_data = u64_to_user_ptr(args->data_ptr);
>
> /* We manually control the domain here and pretend that it
> @@ -1431,7 +1431,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> ret = i915_gem_gtt_pwrite_fast(obj, args);
>
> if (ret == -EFAULT || ret == -ENOSPC) {
> - if (obj->phys_handle)
> + if (obj->phys_vaddr)
> ret = i915_gem_phys_pwrite(obj, args, file);
> else
> ret = i915_gem_shmem_pwrite(obj, args);
> diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h
> index ca93a40c0c87..14bd2d61d0f6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> @@ -290,7 +290,8 @@ struct drm_i915_gem_object {
> };
>
> /** for phys allocated objects */
> - struct drm_dma_handle *phys_handle;
> + dma_addr_t phys_handle;
> + void *phys_vaddr;
>
> struct reservation_object __builtin_resv;
> };
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 5098228f1302..4f8b368ac4e2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10066,7 +10066,7 @@ static u32 intel_cursor_base(const struct intel_plane_state *plane_state)
> u32 base;
>
> if (INTEL_INFO(dev_priv)->display.cursor_needs_physical)
> - base = obj->phys_handle->busaddr;
> + base = obj->phys_handle;
> else
> base = intel_plane_ggtt_offset(plane_state);
>
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
^ permalink raw reply
* [PATCH for-rc 2/7] IB/hfi1: Silence txreq allocation warnings
From: Dennis Dalessandro @ 2019-06-14 16:32 UTC (permalink / raw)
To: jgg, dledford; +Cc: linux-rdma, Mike Marciniszyn, stable
In-Reply-To: <20190614163146.44927.95985.stgit@awfm-01.aw.intel.com>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
The following warning can happen when a memory shortage
occurs during txreq allocation:
[10220.939246] SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
[10220.939246] Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS SE5C610.86B.01.01.0018.C4.072020161249 07/20/2016
[10220.939247] cache: mnt_cache, object size: 384, buffer size: 384, default order: 2, min order: 0
[10220.939260] Workqueue: hfi0_0 _hfi1_do_send [hfi1]
[10220.939261] node 0: slabs: 1026568, objs: 43115856, free: 0
[10220.939262] Call Trace:
[10220.939262] node 1: slabs: 820872, objs: 34476624, free: 0
[10220.939263] dump_stack+0x5a/0x73
[10220.939265] warn_alloc+0x103/0x190
[10220.939267] ? wake_all_kswapds+0x54/0x8b
[10220.939268] __alloc_pages_slowpath+0x86c/0xa2e
[10220.939270] ? __alloc_pages_nodemask+0x2fe/0x320
[10220.939271] __alloc_pages_nodemask+0x2fe/0x320
[10220.939273] new_slab+0x475/0x550
[10220.939275] ___slab_alloc+0x36c/0x520
[10220.939287] ? hfi1_make_rc_req+0x90/0x18b0 [hfi1]
[10220.939299] ? __get_txreq+0x54/0x160 [hfi1]
[10220.939310] ? hfi1_make_rc_req+0x90/0x18b0 [hfi1]
[10220.939312] __slab_alloc+0x40/0x61
[10220.939323] ? hfi1_make_rc_req+0x90/0x18b0 [hfi1]
[10220.939325] kmem_cache_alloc+0x181/0x1b0
[10220.939336] hfi1_make_rc_req+0x90/0x18b0 [hfi1]
[10220.939348] ? hfi1_verbs_send_dma+0x386/0xa10 [hfi1]
[10220.939359] ? find_prev_entry+0xb0/0xb0 [hfi1]
[10220.939371] hfi1_do_send+0x1d9/0x3f0 [hfi1]
[10220.939372] process_one_work+0x171/0x380
[10220.939374] worker_thread+0x49/0x3f0
[10220.939375] kthread+0xf8/0x130
[10220.939377] ? max_active_store+0x80/0x80
[10220.939378] ? kthread_bind+0x10/0x10
[10220.939379] ret_from_fork+0x35/0x40
[10220.939381] SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
The shortage is handled properly so the message isn't needed. Silence by
adding the no warn option to the slab allocation.
Fixes: 45842abbb292 ("staging/rdma/hfi1: move txreq header code")
Cc: <stable@vger.kernel.org>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
---
drivers/infiniband/hw/hfi1/verbs_txreq.c | 2 +-
drivers/infiniband/hw/hfi1/verbs_txreq.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/verbs_txreq.c b/drivers/infiniband/hw/hfi1/verbs_txreq.c
index c4ab2d5..8f766dd 100644
--- a/drivers/infiniband/hw/hfi1/verbs_txreq.c
+++ b/drivers/infiniband/hw/hfi1/verbs_txreq.c
@@ -100,7 +100,7 @@ struct verbs_txreq *__get_txreq(struct hfi1_ibdev *dev,
if (ib_rvt_state_ops[qp->state] & RVT_PROCESS_RECV_OK) {
struct hfi1_qp_priv *priv;
- tx = kmem_cache_alloc(dev->verbs_txreq_cache, GFP_ATOMIC);
+ tx = kmem_cache_alloc(dev->verbs_txreq_cache, VERBS_TXREQ_GFP);
if (tx)
goto out;
priv = qp->priv;
diff --git a/drivers/infiniband/hw/hfi1/verbs_txreq.h b/drivers/infiniband/hw/hfi1/verbs_txreq.h
index b002e96..bfa6e08 100644
--- a/drivers/infiniband/hw/hfi1/verbs_txreq.h
+++ b/drivers/infiniband/hw/hfi1/verbs_txreq.h
@@ -72,6 +72,7 @@ struct verbs_txreq {
struct verbs_txreq *__get_txreq(struct hfi1_ibdev *dev,
struct rvt_qp *qp);
+#define VERBS_TXREQ_GFP (GFP_ATOMIC | __GFP_NOWARN)
static inline struct verbs_txreq *get_txreq(struct hfi1_ibdev *dev,
struct rvt_qp *qp)
__must_hold(&qp->slock)
@@ -79,7 +80,7 @@ static inline struct verbs_txreq *get_txreq(struct hfi1_ibdev *dev,
struct verbs_txreq *tx;
struct hfi1_qp_priv *priv = qp->priv;
- tx = kmem_cache_alloc(dev->verbs_txreq_cache, GFP_ATOMIC);
+ tx = kmem_cache_alloc(dev->verbs_txreq_cache, VERBS_TXREQ_GFP);
if (unlikely(!tx)) {
/* call slow path to get the lock */
tx = __get_txreq(dev, qp);
^ permalink raw reply related
* [PATCH for-rc 1/7] IB/hfi1: Avoid hardlockup with flushlist_lock
From: Dennis Dalessandro @ 2019-06-14 16:32 UTC (permalink / raw)
To: jgg, dledford; +Cc: linux-rdma, Mike Marciniszyn, stable
In-Reply-To: <20190614163146.44927.95985.stgit@awfm-01.aw.intel.com>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
Heavy contention of the sde flushlist_lock can cause hard lockups at
extreme scale when the flushing logic is under stress.
Mitigate by replacing the item at a time copy to the local list with
an O(1) list_splice_init() and using the high priority work queue to
do the flushes.
Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Cc: <stable@vger.kernel.org>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
---
drivers/infiniband/hw/hfi1/sdma.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/sdma.c b/drivers/infiniband/hw/hfi1/sdma.c
index b011072..70828de 100644
--- a/drivers/infiniband/hw/hfi1/sdma.c
+++ b/drivers/infiniband/hw/hfi1/sdma.c
@@ -410,10 +410,7 @@ static void sdma_flush(struct sdma_engine *sde)
sdma_flush_descq(sde);
spin_lock_irqsave(&sde->flushlist_lock, flags);
/* copy flush list */
- list_for_each_entry_safe(txp, txp_next, &sde->flushlist, list) {
- list_del_init(&txp->list);
- list_add_tail(&txp->list, &flushlist);
- }
+ list_splice_init(&sde->flushlist, &flushlist);
spin_unlock_irqrestore(&sde->flushlist_lock, flags);
/* flush from flush list */
list_for_each_entry_safe(txp, txp_next, &flushlist, list)
@@ -2413,7 +2410,7 @@ int sdma_send_txreq(struct sdma_engine *sde,
list_add_tail(&tx->list, &sde->flushlist);
spin_unlock(&sde->flushlist_lock);
iowait_inc_wait_count(wait, tx->num_desc);
- schedule_work(&sde->flush_worker);
+ queue_work_on(sde->cpu, system_highpri_wq, &sde->flush_worker);
ret = -ECOMM;
goto unlock;
nodesc:
@@ -2511,7 +2508,7 @@ int sdma_send_txlist(struct sdma_engine *sde, struct iowait_work *wait,
iowait_inc_wait_count(wait, tx->num_desc);
}
spin_unlock(&sde->flushlist_lock);
- schedule_work(&sde->flush_worker);
+ queue_work_on(sde->cpu, system_highpri_wq, &sde->flush_worker);
ret = -ECOMM;
goto update_tail;
nodesc:
^ permalink raw reply related
* Re: [PATCH 12/16] staging/comedi: mark as broken
From: Christoph Hellwig @ 2019-06-14 15:34 UTC (permalink / raw)
To: Greg KH
Cc: Maxime Ripard, dri-devel, linux-mm, Christoph Hellwig, devel,
linux-s390, linux-rdma, David Airlie, linux-media,
Intel Linux Wireless, intel-gfx, Ian Abbott,
moderated list:ARM PORT, netdev, linux-wireless, linux-kernel,
H Hartley Sweeten, iommu
In-Reply-To: <20190614153032.GD18049@kroah.com>
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> > On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > > Perhaps a hint as to how we can fix this up? This is the first time
> > > I've heard of the comedi code not handling dma properly.
> >
> > It can be fixed by:
> >
> > a) never calling virt_to_page (or vmalloc_to_page for that matter)
> > on dma allocation
> > b) never remapping dma allocation with conflicting cache modes
> > (no remapping should be doable after a) anyway).
>
> Ok, fair enough, have any pointers of drivers/core code that does this
> correctly? I can put it on my todo list, but might take a week or so...
Just about everyone else. They just need to remove the vmap and
either do one large allocation, or live with the fact that they need
helpers to access multiple array elements instead of one net vmap,
which most of the users already seem to do anyway, with just a few
using the vmap (which might explain why we didn't see blowups yet).
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 12/16] staging/comedi: mark as broken
From: Greg KH @ 2019-06-14 15:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Maxime Ripard, dri-devel, linux-mm, devel, linux-s390, linux-rdma,
David Airlie, linux-media, Intel Linux Wireless, intel-gfx,
Ian Abbott, moderated list:ARM PORT, netdev, linux-wireless,
linux-kernel, H Hartley Sweeten, iommu
In-Reply-To: <20190614144857.GA9088@lst.de>
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > Perhaps a hint as to how we can fix this up? This is the first time
> > I've heard of the comedi code not handling dma properly.
>
> It can be fixed by:
>
> a) never calling virt_to_page (or vmalloc_to_page for that matter)
> on dma allocation
> b) never remapping dma allocation with conflicting cache modes
> (no remapping should be doable after a) anyway).
Ok, fair enough, have any pointers of drivers/core code that does this
correctly? I can put it on my todo list, but might take a week or so...
Ian, want to look into doing this sooner?
thanks,
greg k-h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: David Laight @ 2019-06-14 15:16 UTC (permalink / raw)
To: 'Robin Murphy', 'Christoph Hellwig'
Cc: Maxime Ripard, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, devel@driverdev.osuosl.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
David Airlie, linux-media@vger.kernel.org, Intel Linux Wireless,
intel-gfx@lists.freedesktop.org, Ian Abbott,
moderated list:ARM PORT, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
H Hartley Sweeten, iommu
In-Reply-To: <4113cd5f-5c13-e9c7-bc5e-dcf0b60e7054@arm.com>
From: Robin Murphy
> Sent: 14 June 2019 16:06
...
> Well, apart from the bit in DMA-API-HOWTO which has said this since
> forever (well, before Git history, at least):
>
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size. This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary."
I knew it was somewhere :-)
Interestingly that also implies that the address returned for a size
of (say) 128 will also be page aligned.
In that case 128 byte alignment should probably be ok - but it is still
an API change that could have horrid consequences.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: 'Christoph Hellwig' @ 2019-06-14 15:08 UTC (permalink / raw)
To: Robin Murphy
Cc: Maxime Ripard, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, 'Christoph Hellwig',
devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org, David Airlie,
linux-media@vger.kernel.org, Intel Linux Wireless,
intel-gfx@lists.freedesktop.org, Ian Abbott,
moderated list:ARM PORT, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
H Hartley Sweeten
In-Reply-To: <4113cd5f-5c13-e9c7-bc5e-dcf0b60e7054@arm.com>
On Fri, Jun 14, 2019 at 04:05:33PM +0100, Robin Murphy wrote:
> That said, I don't believe this particular patch should make any
> appreciable difference - alloc_pages_exact() is still going to give back
> the same base address as the rounded up over-allocation would, and
> PAGE_ALIGN()ing the size passed to get_order() already seemed to be
> pointless.
True, we actually do get the right alignment just about anywhere.
Not 100% sure about the various static pool implementations, but we
can make sure if any didn't we'll do that right thing once those
get consolidated.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: 'Christoph Hellwig' @ 2019-06-14 15:05 UTC (permalink / raw)
To: David Laight
Cc: Maxime Ripard, Joonas Lahtinen,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
'Christoph Hellwig',
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Airlie,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Intel Linux Wireless,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Maarten Lankhorst, Jani Nikula, Ian Abbott, Rodrigo Vivi,
Sean Paul, moderated list:ARM PORT
In-Reply-To: <d93fd4c2c1584d92a05dd641929f6d63-1XygrNkDbNvwg4NCKwmqgw@public.gmane.org>
On Fri, Jun 14, 2019 at 03:01:22PM +0000, David Laight wrote:
> I'm pretty sure there is a lot of code out there that makes that assumption.
> Without it many drivers will have to allocate almost double the
> amount of memory they actually need in order to get the required alignment.
> So instead of saving memory you'll actually make more be used.
That code would already be broken on a lot of Linux platforms.
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: Robin Murphy @ 2019-06-14 15:05 UTC (permalink / raw)
To: 'Christoph Hellwig', David Laight
Cc: Maxime Ripard, Joonas Lahtinen, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, devel@driverdev.osuosl.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
David Airlie, linux-media@vger.kernel.org, Intel Linux Wireless,
intel-gfx@lists.freedesktop.org, Maarten Lankhorst, Jani Nikula,
Ian Abbott, Rodrigo Vivi, Sean Paul
In-Reply-To: <20190614145001.GB9088@lst.de>
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
> On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote:
>> Does this still guarantee that requests for 16k will not cross a 16k boundary?
>> It looks like you are losing the alignment parameter.
>
> The DMA API never gave you alignment guarantees to start with,
> and you can get not naturally aligned memory from many of our
> current implementations.
Well, apart from the bit in DMA-API-HOWTO which has said this since
forever (well, before Git history, at least):
"The CPU virtual address and the DMA address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size. This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary."
That said, I don't believe this particular patch should make any
appreciable difference - alloc_pages_exact() is still going to give back
the same base address as the rounded up over-allocation would, and
PAGE_ALIGN()ing the size passed to get_order() already seemed to be
pointless.
Robin.
^ permalink raw reply
* RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: David Laight @ 2019-06-14 15:01 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, Intel Linux Wireless,
moderated list:ARM PORT, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, linux-rdma@vger.kernel.org,
linux-media@vger.kernel.org
In-Reply-To: <20190614145001.GB9088@lst.de>
From: 'Christoph Hellwig'
> Sent: 14 June 2019 15:50
> To: David Laight
> On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote:
> > Does this still guarantee that requests for 16k will not cross a 16k boundary?
> > It looks like you are losing the alignment parameter.
>
> The DMA API never gave you alignment guarantees to start with,
> and you can get not naturally aligned memory from many of our
> current implementations.
Hmmm...
I thought that was even documented.
I'm pretty sure there is a lot of code out there that makes that assumption.
Without it many drivers will have to allocate almost double the
amount of memory they actually need in order to get the required alignment.
So instead of saving memory you'll actually make more be used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] [v4.14.y] infiniband: fix race condition between infiniband mlx4, mlx5 driver and core dumping
From: Greg KH @ 2019-06-14 14:55 UTC (permalink / raw)
To: Ajay Kaher
Cc: aarcange@redhat.com, jannh@google.com, oleg@redhat.com,
peterx@redhat.com, rppt@linux.ibm.com, jgg@mellanox.com,
mhocko@suse.com, 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, Srivatsa Bhat
In-Reply-To: <9C189085-083D-46EA-98DB-B11AD62051B6@vmware.com>
On Fri, Jun 14, 2019 at 02:41:39PM +0000, Ajay Kaher wrote:
>
> On 10/06/19, 6:22 PM, "Ajay Kaher" <akaher@vmware.com> wrote:
>
> > 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>
>
> Greg, I hope you would like to review and proceed further with this patch.
If this is all calmed down now, I'll look at it next week, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: 'Christoph Hellwig' @ 2019-06-14 14:50 UTC (permalink / raw)
To: David Laight
Cc: Maxime Ripard, Joonas Lahtinen,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
'Christoph Hellwig',
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Airlie,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Intel Linux Wireless,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Maarten Lankhorst, Jani Nikula, Ian Abbott, Rodrigo Vivi,
Sean Paul, moderated list:ARM PORT
In-Reply-To: <a90cf7ec5f1c4166b53c40e06d4d832a-1XygrNkDbNvwg4NCKwmqgw@public.gmane.org>
On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote:
> Does this still guarantee that requests for 16k will not cross a 16k boundary?
> It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to start with,
and you can get not naturally aligned memory from many of our
current implementations.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox