* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement check
out under the code that does the quasi-probe for the device. This
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe so this would only be triggered if a corresponding
device was found.
Signed-off-by: Luis R. Rodriguez
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Jason Gunthorpe
Sent: Thursday, June 25, 2015 2:30 PM
To: Steve Wise
Cc: 'Hefty, Sean'; linux-rdma@vger.kernel.org; sa...@mellanox.com;
orgerl...@mellanox.com; 'Roi
Please accept my apologies. The original patch used WARN_ON but I was
advised to use BUG_ON in a review and I should have thought about it more
rather than blindly make the change.
Ira,
Can you please point me to the review thread where this advise was made? I
can't track it. In
We might return res which is not initialized. Also
reduce code duplication by exporting srp_parse_tmo so
srp_tmo_set can reuse it.
Detected by Coverity.
Signed-off-by: Sagi Grimberg sa...@mellanox.com
Signed-off-by: Jenny Falkovich jen...@mellanox.com
---
drivers/infiniband/ulp/srp/ib_srp.c |
From: Ira Weiny ira.we...@intel.com
We recently added BUG_ON's which were inappropriate for a condition which
should never happen. Change these to be WARN_ON_ONCE as a debugging aid.
Fixes: 4cd7c9479aff ('IB/mad: Add support for additional MAD info to/from
drivers')
Signed-off-by: Ira Weiny
From: Ira Weiny ira.we...@intel.com
Commit 3d33f9d9fea0 IB/mad: Add final OPA MAD processing
Added a 0-day build error which did not appear until building with the OPA
driver sent to the list.
Signed-off-by: Ira Weiny ira.we...@intel.com
Reviewed-by: Mike Marciniszyn mike.marcinis...@intel.com
On 6/24/2015 8:57 PM, Jason Gunthorpe wrote:
On Mon, Jun 22, 2015 at 05:47:14PM +0300, Yishai Hadas wrote:
fd_install(resp.async_fd, filp);
@@ -386,6 +376,7 @@ ssize_t ib_uverbs_get_context(struct ib_uverbs_file *file,
return in_len;
err_file:
+
On 6/24/2015 9:25 PM, Jason Gunthorpe wrote:
On Mon, Jun 22, 2015 at 05:47:16PM +0300, Yishai Hadas wrote:
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -137,7 +137,12 @@ static void ib_uverbs_release_dev(struct kref *ref)
struct ib_uverbs_device *dev =
On Thu, Jun 25, 2015 at 4:52 AM, Weiny, Ira ira.we...@intel.com wrote:
Linus,
On the *other* side of the same conflict, I find an even more offensive
commit,
namely commit 4cd7c9479aff (IB/mad: Add support for additional MAD info
to/from drivers) which adds a BUG_ON() for a sanity check,
I don't understand why iWarp HW choose to ignore the verbs spec and
not use IB_ACCESS_LOCAL_WRITE to cover RDMA READ responses...
The iWARP verbs spec mandates this.
Steve.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
The semantics for MR access rights are not consistent across RDMA
protocols. So rather than have applications try and glean what they need,
have them pass in the intended roles for the MR to be allocated and let
the RDMA core select the appropriate access rights given the roles and
device
Memory regions that are the target of an iWARP RDMA READ RESPONSE need
REMOTE_WRITE access rights. So enable REMOTE_WRITE for iWARP devices.
iWARP RDMA READ target sge depth is 1. So save the max_read_sge in
the target device structure and use that when creating RDMA_READ work
requests.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
Tested-by: Vasu Dev vasu@intel.com
---
drivers/infiniband/ulp/iser/iscsi_iser.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
The following series implements support for iWARP transpors
in the iSER initiator and target. This is based on
Doug's k.o/for-4.2 branch.
---
Steve Wise (2):
RDMA/iser: limit sg tablesize on device fastreg max depth
RDMA/isert: Support iWARP transport
Whenever ib_cm gets remove_one call, like when there is a hot-unplug
event, the driver should mark itself as going_down and confirm that no
new works are going to be queued for that device.
so, the order of the actions are:
1. mark the going_down bit.
2. flush the wq.
3. [make sure no new works
The function was deprecated and later dropped by udev entirely
because it was pointless.
Quoting kernel's Documentation/sysfs-rules.txt:
sysfs is always at /sys
Parsing /proc/mounts is a waste of time. Other mount points are
a system configuration bug you should not try to solve. [...]
Hello,
the first patch simplifies code.
The second patch fixes an overlinking issue.
Regards,
Michal
Michal Schmidt (2):
rdma-ndd: never use udev_get_sys_path()
build-sys: avoid overlinking to libudev
Makefile.am| 6 ++
configure.ac | 10 +-
src/rdma-ndd.c | 19
Not all built binaries need to link to udev, only rdma-ndd.
Use pkg-config to detect udev in configure.ac.
Signed-off-by: Michal Schmidt mschm...@redhat.com
---
Makefile.am | 6 ++
configure.ac | 9 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Makefile.am
On 06/25/15 03:34, Sagi Grimberg wrote:
We might return res which is not initialized. Also
reduce code duplication by exporting srp_parse_tmo so
srp_tmo_set can reuse it.
Good catch.
Reviewed-by: Bart Van Assche bart.vanass...@sandisk.com
--
To unsubscribe from this list: send the line
For IB links, reading HCA flow counters through iboe_process_mad() should
be used when mlx4_ib_process_mad() is invoked only for VFs PMA queries and
exactly nothing else.
Fixes: 7193a141eb74 ('IB/mlx4: Set VF to read from QP counters')
Reported-by: Linus Torvalds torva...@linux-foundation.org
On 6/25/2015 4:52 PM, ira.we...@intel.com wrote:
From: Ira Weinyira.we...@intel.com
We recently added BUG_ON's which were inappropriate for a condition
which should never happen. Change these to be WARN_ON_ONCE as a
debugging aid.
Fixes: 4cd7c9479aff ('IB/mad: Add support for
On 6/25/2015 4:52 PM, ira.we...@intel.com wrote:
From: Ira Weinyira.we...@intel.com
We recently added BUG_ON's which were inappropriate for a condition which
should never happen. Change these to be WARN_ON_ONCE as a debugging aid.
Fixes: 4cd7c9479aff ('IB/mad: Add support for additional MAD
From: Ira Weiny ira.we...@intel.com
The define OPA_LID_PERMISSIVE is big endian and was compared to cpu value
opa_drslid.
0-day build caught this while building with the OPA (hfi1) driver which was
recently sent to the list.
Fixes: 8e4349d13f33 (IB/mad: Add final OPA MAD processing)
On 6/25/2015 6:39 PM, Steve Wise wrote:
Memory regions that are the target of an iWARP RDMA READ RESPONSE need
REMOTE_WRITE access rights. So enable REMOTE_WRITE for iWARP devices.
iWARP RDMA READ target sge depth is 1. So save the max_read_sge in
the target device structure and use that when
On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement
On 6/25/2015 6:39 PM, Steve Wise wrote:
Signed-off-by: Steve Wise sw...@opengridcomputing.com
Tested-by: Vasu Dev vasu@intel.com
---
drivers/infiniband/ulp/iser/iscsi_iser.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Sagi Grimberg
Sent: Thursday, June 25, 2015 11:58 AM
To: Steve Wise; linux-rdma@vger.kernel.org
Cc: Or Gerlitz; Roi Dayan; target-devel; Nicholas A. Bellinger
Subject:
On 06/25/2015 07:13 AM, Erez Shitrit wrote:
@@ -3864,14 +3904,23 @@ static void cm_remove_one(struct ib_device *ib_device)
list_del(cm_dev-list);
write_unlock_irqrestore(cm.device_lock, flags);
+ spin_lock_irq(cm.lock);
+ cm_dev-going_down = 1;
+
On 6/25/2015 6:39 PM, Steve Wise wrote:
The following series implements support for iWARP transpors
in the iSER initiator and target. This is based on
Doug's k.o/for-4.2 branch.
Hi Steve,
Thanks for this set,
Can you please rebase for target-pending/master?
or at least submit on top of:
On Thu, Jun 25, 2015 at 04:51:49PM +0300, Yishai Hadas wrote:
On 6/24/2015 9:25 PM, Jason Gunthorpe wrote:
Is not holding the RCU lock while ib_uverbs_release_dev is reading
ib_dev. The barriers in kref are not strong enough to guarentee the RCU
protected data will be visible. (remember when I
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Sagi Grimberg
Sent: Thursday, June 25, 2015 11:51 AM
To: Steve Wise; linux-rdma@vger.kernel.org
Cc: Or Gerlitz; Roi Dayan; target-devel
Subject: Re: [PATCH RFC 2/2]
On 06/25/2015 09:04 AM, ira.we...@intel.com wrote:
From: Ira Weiny ira.we...@intel.com
The define OPA_LID_PERMISSIVE is big endian and was compared to cpu value
opa_drslid.
0-day build caught this while building with the OPA (hfi1) driver which was
recently sent to the list.
Fixes:
+* IWARP transports need REMOTE_WRITE for MRs used as the target of
+* an RDMA_READ. Since the DMA MR is used for all ports, then if
+* any port is running IWARP, add REMOTE_WRITE.
+*/
+ if (any_port_is_iwarp(device))
It would be nice to have a new-style cap test
On Thu, Jun 25, 2015 at 10:39:23AM -0500, Steve Wise wrote:
+ /*
+ * IWARP transports need REMOTE_WRITE for MRs used as the target of
+ * an RDMA_READ. Since the DMA MR is used for all ports, then if
+ * any port is running IWARP, add REMOTE_WRITE.
+ */
+ if
-Original Message-
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, June 25, 2015 1:25 PM
To: Steve Wise
Cc: linux-rdma@vger.kernel.org; sa...@mellanox.com; orgerl...@mellanox.com;
r...@mellanox.com
Subject: Re: [PATCH RFC 2/2] RDMA/isert: Support
On Thu, Jun 25, 2015 at 11:34:43AM +0300, Or Gerlitz wrote:
So... are we finally OK wrt the feedback you provided?
I've been looking at Yishai's series, I though it was almost good to
go, but the error flows are still wrong :(
For Matan's patch, I only looked briefly, merging it with the
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Hefty, Sean
Sent: Thursday, June 25, 2015 1:30 PM
To: Jason Gunthorpe; Steve Wise
Cc: linux-rdma@vger.kernel.org; sa...@mellanox.com; orgerl...@mellanox.com;
On Thu, Jun 25, 2015 at 02:46:02PM +0300, Yishai Hadas wrote:
On 6/24/2015 8:57 PM, Jason Gunthorpe wrote:
On Mon, Jun 22, 2015 at 05:47:14PM +0300, Yishai Hadas wrote:
fd_install(resp.async_fd, filp);
@@ -386,6 +376,7 @@ ssize_t ib_uverbs_get_context(struct ib_uverbs_file
*file,
How would you envision doing this? At the time a MR is registered the
device driver doesn't know if the application will be doing
RDMA reads or not on that MR.
I was thinking of checking for REMOTE_READ, but that doesn't work on the
initiator side.
I guess you could a READ_DEST(SOURCE?
On Thu, Jun 25, 2015 at 06:45:56PM +, Hefty, Sean wrote:
How would you envision doing this? At the time a MR is registered the
device driver doesn't know if the application will be doing
RDMA reads or not on that MR.
I was thinking of checking for REMOTE_READ, but that doesn't work
What about moving to something more specific? Encode the allowed verbs
in the access flag?
This makes more sense to me. Something like: SEND, RECV, INIT READ, INIT
WRITE, READ TARGET, WRITE TARGET, etc. We're close to this, but it's not
clear, for example, what flags are needed for a
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Hefty, Sean
Sent: Thursday, June 25, 2015 2:20 PM
To: Jason Gunthorpe
Cc: Steve Wise; linux-rdma@vger.kernel.org; sa...@mellanox.com;
orgerl...@mellanox.com; Roi
On Thu, Jun 25, 2015 at 02:25:49PM -0500, Steve Wise wrote:
To stage the changes we could introduce a new function that returns
the needed ib_access_flags value given the desired opcodes. Then
have a series that changes all the existing ULPs to make use of this
new function.
I wouldn't be
On Thu, Jun 25, 2015 at 04:29:17PM -0500, Steve Wise wrote:
- * ib_dma_mapping_error - check a DMA addr for error
+ * rdma_mr_roles - possible roles a MR will be used for
+ *
+ * This allows a transport independent RDMA application to
+ * create MRs that are usable for all the desired roles
-Original Message-
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, June 25, 2015 4:40 PM
To: Steve Wise
Cc: sa...@mellanox.com; r...@mellanox.com; ogerl...@mellanox.com;
sean.he...@intel.com; linux-rdma@vger.kernel.org
Subject: Re: [PATCH RFC]
On Fri, Jun 12, 2015 at 10:06:06AM -0400, kaike@intel.com wrote:
This patch routes a SA pathrecord query to netlink first and processes the
response appropriately. If a failure is returned, the request will be sent
through IB. The decision whether to route the request to netlink first is
+enum rdma_mr_roles {
I would drop naming the enum - it shouldn't be used, as the values are bit
flags.
+ RDMA_MRR_RECV = 1,
+ RDMA_MRR_SEND = (11),
+ RDMA_MRR_READ_SOURCE= (12),
+ RDMA_MRR_READ_SINK = (13),
+
On Wed, Jun 24, 2015 at 3:59 PM, Matan Barak mat...@mellanox.com wrote:
[...]
Changes from V5:
(1) Incoporate the changes to cache.c so we use the same infrastructure
to manage both IB and RoCE (per Doug's request)
(2) Replace the locking mechanism in the IB core GID cache from seqcount +
On 6/25/2015 4:50 AM, ira.we...@intel.com wrote:
From: Ira Weinyira.we...@intel.com
commit 97f229a8515f932e5adc6cdfa18cc1440235b9fd
IB/mad: Add support for additional MAD info to/from drivers
added BUG_ON's which were inappropriate for a condition which should never
happen. Change these to be
50 matches
Mail list logo
