* RE: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Weiny, Ira @ 2016-10-04 18:36 UTC (permalink / raw)
To: Christoph Lameter,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Jason Gunthorpe, Fleck, John,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
skc-YOWKrPYUwWM@public.gmane.org,
shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <alpine.DEB.2.20.1610040344500.11122-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
Christoph,
I just want to be sure that the Tuesday session at LPC is located at the Community Convention Center:
Sante Fe Community Convention Center
201 W. Marcy Street
Santa Fe, New Mexico 87501
United States
Or is that also at the Hilton?
Thanks,
Ira
> -----Original Message-----
> From: Christoph Lameter [mailto:cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org]
> Sent: Tuesday, October 04, 2016 2:16 AM
> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Weiny, Ira <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; Jason Gunthorpe
> <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>; Fleck, John <john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
> leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; skc-YOWKrPYUwWM@public.gmane.org;
> shewa-YOWKrPYUwWM@public.gmane.org
> Subject: RDMA developer gatherings around Kernel Summit and Linux
> Plumbers in Santa Fe
>
> We now have confirmation about the meetings related to the KS and LPC.
> The events will be held at the:
>
> Hilton Santa Fe
> 100 Sandoval St.
> Santa Fe, NM 87501
> Phone: (505)988-2811
>
> We meet specifically on the subject matter of RDMA two days:
>
> - RDMA workshop on Tuesday, 1st of November
>
> Meeting in Sweeney B 9am till 5pm.
> See
> http://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
>
> This is part of the Kernel Summit and the Linux Plumbers
> Conference. Only open to KS and LPC attendees with an invitation.
>
> - RDMA Summit on Saturday the 5th of November
>
> Meeting in the Canyon Ballroom 9am till 4pm.
>
> This event is sponsored by the Open Fabrics Alliance and will be
> open to all
>
>
> We think the workshop could be focusing more on the technical topics (some
> of which could be carried over to Saturday if necessary because we have
> more time then. The "Summit" would also be including management issues,
> long range plans and OFA related material. We will summarize what
> happened on Tuesday for those who were not able to participate earlier.
>
> Each day we thought we could cover 6 subjects. 3 in the morning 3 in the
> afternoon.
>
> Initial ideas for sessions:
>
> Workshop:
> - New ioctl ABI and issues related to that
> - Consolidated libraries. Closer integration of librdmacm to
> libibverbs etc.
> - Using standard network tools/techniques for IB interfaces.
> - Debuggability and tracing (also can standard tools help here?)
> - State of Multicast support
> - Containers and RDMA
>
> Summit:
> - Licensing (GPL vs. Dual licensed)
> - Integration with other subsystems (GPUs, network, PCI etc ...)
> - Roadmap and future of RDMA
> - Leftover issues and TODO for consolidated library.
> - Submission process for multi-subsystem drivers (f.e ROCE)
>
>
> Feedback would be appreciated so that we can workout an agenda that is
> useful for all participants.
--
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
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Parav Pandit @ 2016-10-04 18:19 UTC (permalink / raw)
To: Tejun Heo
Cc: Leon Romanovsky, Jason Gunthorpe, Christoph Hellwig, Matan Barak,
cgroups-u79uwXL29TY76Z2rM5mHXA, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Li Zefan, Johannes Weiner, Doug Ledford, Liran Liss, Hefty, Sean,
Haggai Eran, Jonathan Corbet,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA,
serge-A9i7LUbDfNHQT0dZR+AlfA, Or Gerlitz, Andrew Morton,
linux-security-module-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAG53R5WMuojhzFGmqk6nHfypd9Hq4dGsWRKjtUyMZ=RezU-LhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Doug,
I am still waiting for Leon to provide his comments if any on rdma cgroup.
>From other email context, he was on vacation last week.
While we wait for his comments, I wanted to know your view of this
patchset in 4.9 merge window.
To summarize the discussion that happened in two threads.
[1] Ack by Tejun, asking for review from rdma list
[2] quick review by Christoph on patch-v11 (patch 12 has only typo corrections)
[3] Christoph's ack on architecture of rdma cgroup and fitting it with ABI
[4] My response on Matan's query on RSS indirection table
[5] Response from Intel on their driver support for Matan's query
[6] Christoph's point on architecture, which we are following in new
ABI and current ABI
I have reviewed recent patch [7] from Matan where I see IB verbs
objects are still handled through common path as suggested by
Christoph.
I do not see any issues with rdma cgroup patchset other than it requires rebase.
Am I missing something?
Can you please help me - What would be required to merge it to 4.9?
[1] https://lkml.org/lkml/2016/8/31/494
[2] https://lkml.org/lkml/2016/8/25/146
[3] https://lkml.org/lkml/2016/9/10/175
[4] https://lkml.org/lkml/2016/9/14/221
[5] https://lkml.org/lkml/2016/9/19/571
[6] http://www.spinics.net/lists/linux-rdma/msg40337.html
[7] email subject: [RFC ABI V4 0/7] SG-based RDMA ABI Proposal
Regards,
Parav Pandit
On Wed, Sep 21, 2016 at 9:32 PM, Parav Pandit <pandit.parav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Tejun,
>
> On Wed, Sep 21, 2016 at 7:56 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Hello, Parav.
>>
>> On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
>>> We have completed review from Tejun, Christoph.
>>> HFI driver folks also provided feedback for Intel drivers.
>>> Matan's also doesn't have any more comments.
>>>
>>> If possible, if you can also review, it will be helpful.
>>>
>>> I have some more changes unrelated to cgroup in same files in both the git tree.
>>> Pushing them now either results into merge conflict later on for
>>> Doug/Tejun, or requires rebase and resending patch.
>>> If you can review, we can avoid such rework.
>>
>> My impression of the thread was that there doesn't seem to be enough
>> of consensus around how rdma resources should be defined. Is that
>> part agreed upon now?
>>
>
> We ended up discussing few points on different thread [1].
>
> There was confusion on how some non-rdma/non-IB drivers would work
> with rdma cgroup from Matan.
> Christoph explained how they don't fit in the rdma subsystem and
> therefore its not prime target to addess.
> Intel driver maintainer Denny also acknowledged same on [2].
> IB compliant drivers of Intel support rdma cgroup as explained in [2].
> With that usnic and Intel psm drivers falls out of rdma cgroup support
> as they don't fit very well in the verbs definition.
>
> [1] https://www.spinics.net/lists/linux-rdma/msg40340.html
> [2] http://www.spinics.net/lists/linux-rdma/msg40717.html
>
> I will wait for Leon's review comments if he has different view on architecture.
> Back in April when I met face-to-face to Leon and Haggai, Leon was in
> support to have kernel defined the rdma resources as suggested by
> Christoph and Tejun instead of IB/RDMA subsystem.
> I will wait for his comments if his views have changed with new uAPI
> taking shape.
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Robert LeBlanc @ 2016-10-04 16:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Hannes Reinecke, Johannes Thumshirn,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161004114642.GA2377-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Do you want me to try this patch or wait for some of the suggestions
Christoph brought up to be Incorporated?
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
On Tue, Oct 4, 2016 at 5:46 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Tue, Oct 04, 2016 at 11:11:18AM +0200, Hannes Reinecke wrote:
>> Hmm. Looking at the code it looks as we might miss some calls to
>> 'complete'. Can you try with the attached patch?
>
> That only looks slightly better than the original. What this really
> needs is a waitqueue and and waitevent on sess->ncon. Although
> that will need a bit more refactoring around that code. There also
> are a few more ovbious issues around it, e.g. iscsit_close_connection
> needs to use atomic_dec_and_test on sess->nconn instead of having
> separate atomic_dec and atomic_read calls, and a lot of the 0 or 1
> atomic_ts in this code should be replaced with atomic bitops.
>
> Btw, there also was a fix from Lee in this area that added a missing
> wakeup, make sure your tree already has that.
--
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
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Atchley, Scott @ 2016-10-04 15:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Lameter, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <20161004124513.GA12483-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> On Oct 4, 2016, at 8:45 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>
>> Summit:
>> - Licensing (GPL vs. Dual licensed)
>
> So we're finally going to bring OFA in front of an anti-trust code
> to bring down their silly Dual licensing requirement for their members.
> Can't see any other reason why this would be brought up again, as they
> obviously can't force anyone else under a dual licensing scheme
> requirement for Linux code.
What is the purpose of this comment?
--
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
^ permalink raw reply
* Re: [RFC] IB/srp: export reset-host via sysfs
From: Gioh Kim @ 2016-10-04 15:22 UTC (permalink / raw)
To: Bart Van Assche, dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <af0d75ef-734d-2cdf-05d8-bf4cd9c59ef9-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On 04.10.2016 16:24, Bart Van Assche wrote:
> On 10/04/16 07:00, Gioh Kim wrote:
>> Standard SCSI device has host_reset sysfs interface.
>> This patch exports the host_reset interface for upper layer.
>>
>> Signed-off-by: Gioh Kim <gi-oh.kim-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
>> ---
>> drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
>> b/drivers/infiniband/ulp/srp/ib_srp.c
>> index 3322ed7..92e6c3f 100644
>> --- a/drivers/infiniband/ulp/srp/ib_srp.c
>> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
>> @@ -2628,6 +2628,15 @@ static int srp_reset_device(struct scsi_cmnd
>> *scmnd)
>> return SUCCESS;
>> }
>>
>> +static int srp_scsi_host_reset(struct Scsi_Host *shost, int reset_type)
>> +{
>> + struct srp_target_port *target = host_to_target(shost);
>> +
>> + shost_printk(KERN_EMERG, target->scsi_host, PFX "SRP reset_host
>> called\n");
>> +
>> + return srp_reconnect_rport(target->rport);
>> +}
>> +
>> static int srp_reset_host(struct scsi_cmnd *scmnd)
>> {
>> struct srp_target_port *target =
>> host_to_target(scmnd->device->host);
>> @@ -2858,6 +2867,7 @@ static struct scsi_host_template srp_template = {
>> .use_clustering = ENABLE_CLUSTERING,
>> .shost_attrs = srp_host_attrs,
>> .track_queue_depth = 1,
>> + .host_reset = srp_scsi_host_reset,
>> };
>
> Hello Gioh,
>
> A patch description should not only explain what is changed but also
> why a change is considered useful. Why do you think it would be useful
> to allow users to trigger a call of srp_reconnect_rport() through
> sysfs instead of using the functionality that is already available
> through sysfs, namely removing a SCSI host and reconnecting?
Hello Bart,
It's my mistake to miss 0000-cover-letter.patch file including description.
I'm testing SCSI devices which are exported by the remote servers via IB
network. I know that SCSI error handling mechanism calls reset-host when
something wrong happens. But the SCSI error handling tries sending ABORT
commands and other actions before resetting host. I found that those
ABORT commands could generate more stress on the remove server. So I
need to reset SCSI host (which mean reconnecting) when the remote server
starts to become slow or have some problem to handle IO.
And I think I can use some utilities for SCSI device, such like sg3
utils, to handle srp connection.
Thank you for your reply.
Best regards,
Gioh Kim
>
> Bart.
>
--
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
^ permalink raw reply
* Re: [RFC] IB/srp: export reset-host via sysfs
From: Bart Van Assche @ 2016-10-04 14:24 UTC (permalink / raw)
To: Gioh Kim, dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1475589609-26451-1-git-send-email-gi-oh.kim-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
On 10/04/16 07:00, Gioh Kim wrote:
> Standard SCSI device has host_reset sysfs interface.
> This patch exports the host_reset interface for upper layer.
>
> Signed-off-by: Gioh Kim <gi-oh.kim-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
> ---
> drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> index 3322ed7..92e6c3f 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2628,6 +2628,15 @@ static int srp_reset_device(struct scsi_cmnd *scmnd)
> return SUCCESS;
> }
>
> +static int srp_scsi_host_reset(struct Scsi_Host *shost, int reset_type)
> +{
> + struct srp_target_port *target = host_to_target(shost);
> +
> + shost_printk(KERN_EMERG, target->scsi_host, PFX "SRP reset_host called\n");
> +
> + return srp_reconnect_rport(target->rport);
> +}
> +
> static int srp_reset_host(struct scsi_cmnd *scmnd)
> {
> struct srp_target_port *target = host_to_target(scmnd->device->host);
> @@ -2858,6 +2867,7 @@ static struct scsi_host_template srp_template = {
> .use_clustering = ENABLE_CLUSTERING,
> .shost_attrs = srp_host_attrs,
> .track_queue_depth = 1,
> + .host_reset = srp_scsi_host_reset,
> };
Hello Gioh,
A patch description should not only explain what is changed but also why
a change is considered useful. Why do you think it would be useful to
allow users to trigger a call of srp_reconnect_rport() through sysfs
instead of using the functionality that is already available through
sysfs, namely removing a SCSI host and reconnecting?
Bart.
--
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
^ permalink raw reply
* [RFC] IB/srp: export reset-host via sysfs
From: Gioh Kim @ 2016-10-04 14:00 UTC (permalink / raw)
To: bart.vanassche, dledford, sean.hefty, hal.rosenstock
Cc: linux-rdma, linux-kernel, Gioh Kim
Standard SCSI device has host_reset sysfs interface.
This patch exports the host_reset interface for upper layer.
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
---
drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 3322ed7..92e6c3f 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2628,6 +2628,15 @@ static int srp_reset_device(struct scsi_cmnd *scmnd)
return SUCCESS;
}
+static int srp_scsi_host_reset(struct Scsi_Host *shost, int reset_type)
+{
+ struct srp_target_port *target = host_to_target(shost);
+
+ shost_printk(KERN_EMERG, target->scsi_host, PFX "SRP reset_host called\n");
+
+ return srp_reconnect_rport(target->rport);
+}
+
static int srp_reset_host(struct scsi_cmnd *scmnd)
{
struct srp_target_port *target = host_to_target(scmnd->device->host);
@@ -2858,6 +2867,7 @@ static struct scsi_host_template srp_template = {
.use_clustering = ENABLE_CLUSTERING,
.shost_attrs = srp_host_attrs,
.track_queue_depth = 1,
+ .host_reset = srp_scsi_host_reset,
};
static int srp_sdev_count(struct Scsi_Host *host)
--
2.5.0
^ permalink raw reply related
* [PULL REQUEST] Please pull rdma.git
From: Doug Ledford @ 2016-10-04 13:50 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1.1: Type: text/plain, Size: 7017 bytes --]
Hi Linus,
This is the first pull request of the 4.9 merge window for the RDMA
subsystem. It is only the hfi1 driver. It had dependencies on code
that only landed late in the 4.7-rc cycle (around 4.7-rc7), so putting
this with my other for-next code would have create an ugly merge of lot
of 4.7-rc stuff. For that reason, it's being submitted individually.
It's been through 0day and linux-next. I'll be sending a different
topic branch through linux-next today and will make a new pull request
once you've picked this one up. I expect there will be three or four
pull requests this cycle as I'm somewhat splitting things up into these
broad groups:
1) hfi1 driver update (needed late 4.7-rc code)
2) hns-roce driver (new driver, still waiting on last few patch
approvals from netdev@)
3) rest of the core stack (needs to wait until after DaveM's tree has
been pulled because it needed to be based on his net-next tree from
around 4.7-rc4)
4) there are four other brand new drivers on the list undergoing review,
and it's possible some of them might complete review in time to be sent,
if so, they will be separate pull requests
Here's the boilerplate for this pull request:
The following changes since commit e4618d40eb3dc1a6d1f55f7150ea25bb23ab410a:
IB/rdmavt: Don't vfree a kzalloc'ed memory region (2016-09-16 14:14:23
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
tags/for-linus
for you to fetch changes up to 61347fa6087884305ea4a3a04501839fdb68dc76:
IB/rdmavt: Trivial function comment corrected. (2016-10-03 10:55:27 -0400)
----------------------------------------------------------------
First pull request of the 4.9 merge window
- Updates to hfi1 driver
----------------------------------------------------------------
Dean Luick (6):
IB/hfi1: Move serdes tune inside link start function
IB/hfi1: Extend i2c timeout
IB/hfi1: Act on external device timeout
IB/hfi1: Restore EPROM read ability
IB/hfi1: Add ability to read platform config from the EPROM
IB/hfi1: Use EPROM platform configuration read
Dennis Dalessandro (3):
IB/qib: Remove qpt_mask global
IB/hfi1: Cleanup tasklet refs in comments
IB/hfi1: Remove unused variable from devdata
Harish Chegondi (2):
IB/hfi1: Fix the count of user packets submitted to an SDMA engine
IB/hfi1: Adjust hardware buffering parameter
Jakub Pawlak (1):
IB/hfi1: Fix resource release in context allocation
Jianxin Xiong (2):
IB/hfi1: Increase default settings of max_cqes and max_qps
IB/hfi1: Update SMA ingress checks for response packets
Mike Marciniszyn (12):
IB/rdmavt: Add functions to get and release QP references
IB/rdmavt, IB/qib, IB/hfi1: Use new QP put get routines
IB/core: Add ib headers for general use
IB/qib,IB/hfi: Use core common header file
IB/rdmavt: Correct sparse annotation
IB/hfi1: Move iowait_init() to priv allocate
IB/rdmavt: Move reset calldown to reset path
IB/rdmavt: Add qp init function
IB/rdmavt, IB/hfi1: Add lockdep asserts for lock debug
IB/hfi1: Consolidate pio control masks into single definition
IB/hfi1: Fix defered ack race with qp destroy
IB/hfi1: Fix trace of atomic ack
Parav Pandit (1):
IB/rdmavt: Trivial function comment corrected.
Sebastian Sanchez (3):
IB/hfi1: Remove filtering of Set(PkeyTable) in HFI SMA
IB/hfi1: Do not read more than a SGE length
IB/hfi1: Combine shift copy and byte copy for SGE reads
Tadeusz Struk (6):
IB/hfi1: Fix locking scheme for affinity settings
IB/hfi1: Add sysfs interface for affinity setup
IB/hfi1: Add a new VL sysfs attribute for sdma engines
IB/hfi1: Add irq affinity notification handler
IB/hfi1: Add new debugfs sdma_cpu_list file
IB/hfi1: Document new sysfs entries for hfi1 driver
Tymoteusz Kielan (1):
IB/hfi1: Fix user-space buffers mapping with IOMMU enabled
Documentation/infiniband/sysfs.txt | 30 +++
drivers/infiniband/hw/hfi1/affinity.c | 203 ++++++++++++----
drivers/infiniband/hw/hfi1/affinity.h | 3 +-
drivers/infiniband/hw/hfi1/chip.c | 57 +++--
drivers/infiniband/hw/hfi1/chip.h | 8 +-
drivers/infiniband/hw/hfi1/common.h | 8 -
drivers/infiniband/hw/hfi1/debugfs.c | 38 +++
drivers/infiniband/hw/hfi1/driver.c | 35 ++-
drivers/infiniband/hw/hfi1/eprom.c | 185 +++++++++++++++
drivers/infiniband/hw/hfi1/eprom.h | 4 +-
drivers/infiniband/hw/hfi1/file_ops.c | 59 +++--
drivers/infiniband/hw/hfi1/hfi.h | 22 +-
drivers/infiniband/hw/hfi1/init.c | 45 ++--
drivers/infiniband/hw/hfi1/mad.c | 7 -
drivers/infiniband/hw/hfi1/pio.c | 20 +-
drivers/infiniband/hw/hfi1/pio.h | 2 +-
drivers/infiniband/hw/hfi1/pio_copy.c | 246 +++++--------------
drivers/infiniband/hw/hfi1/platform.c | 32 ++-
drivers/infiniband/hw/hfi1/qp.c | 32 +--
drivers/infiniband/hw/hfi1/qsfp.c | 2 +-
drivers/infiniband/hw/hfi1/rc.c | 146 ++++++------
drivers/infiniband/hw/hfi1/ruc.c | 10 +-
drivers/infiniband/hw/hfi1/sdma.c | 377
+++++++++++++++++++++++++++++-
drivers/infiniband/hw/hfi1/sdma.h | 13 +-
drivers/infiniband/hw/hfi1/sysfs.c | 103 +++++++-
drivers/infiniband/hw/hfi1/trace.c | 31 +--
drivers/infiniband/hw/hfi1/trace_ctxts.h | 13 +-
drivers/infiniband/hw/hfi1/trace_ibhdrs.h | 14 +-
drivers/infiniband/hw/hfi1/trace_rx.h | 4 +-
drivers/infiniband/hw/hfi1/uc.c | 15 +-
drivers/infiniband/hw/hfi1/ud.c | 61 +++--
drivers/infiniband/hw/hfi1/user_sdma.c | 40 ++--
drivers/infiniband/hw/hfi1/verbs.c | 60 +++--
drivers/infiniband/hw/hfi1/verbs.h | 93 +-------
drivers/infiniband/hw/hfi1/verbs_txreq.c | 2 +-
drivers/infiniband/hw/qib/qib.h | 2 +-
drivers/infiniband/hw/qib/qib_driver.c | 7 +-
drivers/infiniband/hw/qib/qib_iba7322.c | 2 +-
drivers/infiniband/hw/qib/qib_qp.c | 13 +-
drivers/infiniband/hw/qib/qib_rc.c | 73 +++---
drivers/infiniband/hw/qib/qib_ruc.c | 4 +-
drivers/infiniband/hw/qib/qib_uc.c | 6 +-
drivers/infiniband/hw/qib/qib_ud.c | 6 +-
drivers/infiniband/hw/qib/qib_verbs.c | 16 +-
drivers/infiniband/hw/qib/qib_verbs.h | 94 +-------
drivers/infiniband/sw/rdmavt/qp.c | 119 ++++++----
include/rdma/ib_hdrs.h | 178 ++++++++++++++
include/rdma/rdmavt_qp.h | 19 ++
48 files changed, 1660 insertions(+), 899 deletions(-)
create mode 100644 include/rdma/ib_hdrs.h
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-04 12:45 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w, Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w, leon-DgEjT+Ai2ygdnm+yROfE0A,
Doug Ledford, skc-YOWKrPYUwWM, shewa-YOWKrPYUwWM
In-Reply-To: <alpine.DEB.2.20.1610040344500.11122-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
> Summit:
> - Licensing (GPL vs. Dual licensed)
So we're finally going to bring OFA in front of an anti-trust code
to bring down their silly Dual licensing requirement for their members.
Can't see any other reason why this would be brought up again, as they
obviously can't force anyone else under a dual licensing scheme
requirement for Linux code.
--
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
^ permalink raw reply
* Re: PROBLEM: nvmet rxe : Kernel oops when running nvmf IO over rdma_rxe
From: Stephen Bates @ 2016-10-04 12:42 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, hch-jcswGhMUV9g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-VPRAkNaXOzVWk0Htik3J/w,
yonatanc-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <e50c485a-00b0-e896-34de-856714fcb454-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
Thanks for taking a look at this Sagi. BTW I did see the nvme connect
seemed pretty stable but I will do some longer waits between the
connect and the IO steps to see if I get a panic...
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from drivers/nvme/target/nvmet-rdma.ko...done.
> (gdb) l *(nvmet_rdma_free_rsps+0x80)
> 0xa20 is in nvmet_rdma_free_rsps (drivers/nvme/target/rdma.c:430).
> 425 int i, nr_rsps = queue->recv_queue_size * 2;
> 426
> 427 for (i = 0; i < nr_rsps; i++) {
> 428 struct nvmet_rdma_rsp *rsp = &queue->rsps[i];
> 429
> 430 list_del(&rsp->free_list);
> 431 nvmet_rdma_free_rsp(ndev, rsp);
> 432 }
> 433 kfree(queue->rsps);
> 434 }
> (gdb)
> --
Oh I did addr2line on the [<ffffffff814537b9>]
nvmet_rdma_free_queue+0x49/0x90 at the top of the Call Trace. I see
you looked up the RIP line (which probably makes more sense ;-)).
>
> Anyway, this looks like a use-after-free condition. The strange thing
> is that we don't see any queues being freed twice (we have a print
> there)...
>
> I suspect that either we have some problems with the draining logic in
> rxe or, we uncovered a bug in nvmet-rdma that is triggered with rxe on
> a VM (back when I tested this I didn't get this, so things must have
> changed...)
OK I will see if I can get more information on what we might be using
after the free and report back. If anyone on the RXE side has any
ideas please chip in ;-).
Cheers
Stephen
--
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
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: Doug Ledford @ 2016-10-04 12:04 UTC (permalink / raw)
To: David Miller, Yuval.Mintz
Cc: netdev, linux-rdma, Ram.Amrani, Michal.Kalderon, Ariel.Elior
In-Reply-To: <20161003.232446.1827173235395776859.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]
On 10/3/2016 11:24 PM, David Miller wrote:
> From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
> Date: Sat, 1 Oct 2016 21:59:54 +0300
>
>> In the last couple of weeks we've been sending RFCs for the qedr
>> driver - the RoCE driver for QLogic FastLinQ 4xxxx line of adapters.
>> Latest RFC can be found at [1].
>>
>> At Doug's advice [2], we've decided to split the series into two:
>> - first part contains the qed backbone that's necessary for all the
>> configurations relating to the qedr driver, as well as the qede
>> infrastructure that is used for communication between the qedr and qede.
>> - Second part consists of the actual qedr driver and introduces almost
>> no changes to qed/qede.
>>
>> This is the first of said two parts. The second half would be sent
>> later this week.
>>
>> The only 'oddity' in the devision are the Kconfig options -
>> As this series introduces both LL2 and QEDR-based logic in qed/qede,
>> I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
>> Otherwise, a lot of the code introduced would be dead-code [won't even
>> be compiled] until qedr is accepted.
>> As a result I've placed the config option in an odd place - under
>> qlogic's Kconfig. The second series would then remove that option
>> and add it in its correct place under the infiniband Kconfig.
>> [I'm fine with pushing it there to begin with, but I didn't want to
>> 'contaminate' non-qlogic configuration files with half-baked options].
>>
>> Dave - I don't think you were E-mailed with Doug's suggestion.
>> I think the notion was to have the two halves accepted side-by-side,
>> but actually the first has no dependency issues, so it's also
>> possible to simply take this first to net-next, and push the qedr
>> into rdma once it's merged. But it's basically up to you and Doug;
>> We'd align with whatever suits you best.
>
> I'll take this, series applied, thanks.
>
Are you going to merge this in 4.9 or is this going into net-next?
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Christoph Hellwig @ 2016-10-04 11:46 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Johannes Thumshirn, Robert LeBlanc, linux-rdma, linux-scsi
In-Reply-To: <5cfc7eb8-c59d-4b7a-3dee-99e17d72f251@suse.de>
On Tue, Oct 04, 2016 at 11:11:18AM +0200, Hannes Reinecke wrote:
> Hmm. Looking at the code it looks as we might miss some calls to
> 'complete'. Can you try with the attached patch?
That only looks slightly better than the original. What this really
needs is a waitqueue and and waitevent on sess->ncon. Although
that will need a bit more refactoring around that code. There also
are a few more ovbious issues around it, e.g. iscsit_close_connection
needs to use atomic_dec_and_test on sess->nconn instead of having
separate atomic_dec and atomic_read calls, and a lot of the 0 or 1
atomic_ts in this code should be replaced with atomic bitops.
Btw, there also was a fix from Lee in this area that added a missing
wakeup, make sure your tree already has that.
^ permalink raw reply
* RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Lameter @ 2016-10-04 9:16 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: ira.weiny-ral2JQCrhuEAvxtiuMwx3w, Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w, leon-DgEjT+Ai2ygdnm+yROfE0A,
Doug Ledford, skc-YOWKrPYUwWM, shewa-YOWKrPYUwWM
We now have confirmation about the meetings related to the KS and LPC. The
events will be held at the:
Hilton Santa Fe
100 Sandoval St.
Santa Fe, NM 87501
Phone: (505)988-2811
We meet specifically on the subject matter of RDMA two days:
- RDMA workshop on Tuesday, 1st of November
Meeting in Sweeney B 9am till 5pm.
See http://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
This is part of the Kernel Summit and the Linux Plumbers
Conference. Only open to KS and LPC attendees with an invitation.
- RDMA Summit on Saturday the 5th of November
Meeting in the Canyon Ballroom 9am till 4pm.
This event is sponsored by the Open Fabrics Alliance and will be
open to all
We think the workshop could be focusing more on the technical topics (some
of which could be carried over to Saturday if necessary because we have
more time then. The "Summit" would also be including management issues,
long range plans and OFA related material. We will summarize what
happened on Tuesday for those who were not able to participate earlier.
Each day we thought we could cover 6 subjects. 3 in the morning 3 in the
afternoon.
Initial ideas for sessions:
Workshop:
- New ioctl ABI and issues related to that
- Consolidated libraries. Closer integration of librdmacm to
libibverbs etc.
- Using standard network tools/techniques for IB interfaces.
- Debuggability and tracing (also can standard tools help here?)
- State of Multicast support
- Containers and RDMA
Summit:
- Licensing (GPL vs. Dual licensed)
- Integration with other subsystems (GPUs, network, PCI etc ...)
- Roadmap and future of RDMA
- Leftover issues and TODO for consolidated library.
- Submission process for multi-subsystem drivers (f.e ROCE)
Feedback would be appreciated so that we can workout an agenda that is
useful for all participants.
--
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
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Hannes Reinecke @ 2016-10-04 9:11 UTC (permalink / raw)
To: Johannes Thumshirn, Robert LeBlanc
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161004075545.j52mg3a2jckrchlp-qw2SdCWA0PpjqqEj2zc+bA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
On 10/04/2016 09:55 AM, Johannes Thumshirn wrote:
> On Fri, Sep 30, 2016 at 11:14:57AM -0600, Robert LeBlanc wrote:
>> We are having a reoccurring problem where iscsi_trx is going into D
>> state. It seems like it is waiting for a session tear down to happen
>> or something, but keeps waiting. We have to reboot these targets on
>> occasion. This is running the 4.4.12 kernel and we have seen it on
>> several previous 4.4.x and 4.2.x kernels. There is no message in dmesg
>> or /var/log/messages. This seems to happen with increased frequency
>> when we have a disruption in our Infiniband fabric, but can happen
>> without any changes to the fabric (other than hosts rebooting).
>>
>> # ps aux | grep iscsi | grep D
>> root 4185 0.0 0.0 0 0 ? D Sep29 0:00 [iscsi_trx]
>> root 18505 0.0 0.0 0 0 ? D Sep29 0:00 [iscsi_np]
>>
>> # cat /proc/4185/stack
>> [<ffffffff814cc999>] target_wait_for_sess_cmds+0x49/0x1a0
>> [<ffffffffa087292b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>> [<ffffffff814f0de2>] iscsit_close_connection+0x162/0x840
>> [<ffffffff814df8df>] iscsit_take_action_for_connection_exit+0x7f/0x100
>> [<ffffffff814effc0>] iscsi_target_rx_thread+0x5a0/0xe80
>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> # cat /proc/18505/stack
>> [<ffffffff814f0c71>] iscsit_stop_session+0x1b1/0x1c0
>> [<ffffffff814e2436>] iscsi_check_for_session_reinstatement+0x1e6/0x270
>> [<ffffffff814e4df0>] iscsi_target_check_for_existing_instances+0x30/0x40
>> [<ffffffff814e4f40>] iscsi_target_do_login+0x140/0x640
>> [<ffffffff814e62dc>] iscsi_target_start_negotiation+0x1c/0xb0
>> [<ffffffff814e402b>] iscsi_target_login_thread+0xa9b/0xfc0
>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> What can we do to help get this resolved?
>>
>> Thanks,
>>
>> ----------------
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Hi,
> I've encountered the same issue and found a hack to fix it at [1] but I think
> the correct way for handling this issue would be like you said to tear down
> the session in case a TASK ABORT times out. Unfortunately I'm not really
> familiar with the target code myself so I mainly use this reply to get me into
> the Cc loop.
>
> [1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
>
>
Hmm. Looking at the code it looks as we might miss some calls to
'complete'. Can you try with the attached patch?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
[-- Attachment #2: 0001-iscsi_target-sanitze-sess_wait_on_completion.patch --]
[-- Type: text/x-patch, Size: 2490 bytes --]
>From d481d8c27df8c09ea3798ce4a7217a26c3533161 Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Date: Tue, 4 Oct 2016 11:05:46 +0200
Subject: [PATCH] iscsi_target: sanitze sess_wait_on_completion
When closing a session we only should set 'sess_wait_on_completion'
if we are actually calling wait_for_completion(). And we should indeed
call 'complete' in these cases, too.
And add some WARN_ON() if we mess up with calculating the number
of completions, too.
Signed-off-by: Hannes Reinecke <hare-IBi9RG/b67k@public.gmane.org>
---
drivers/target/iscsi/iscsi_target.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index 39b928c..313724c 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4287,6 +4287,7 @@ int iscsit_close_connection(
if (!atomic_read(&sess->session_reinstatement) &&
atomic_read(&sess->session_fall_back_to_erl0)) {
spin_unlock_bh(&sess->conn_lock);
+ WARN_ON(atomic_read(&sess->sleep_on_sess_wait_comp));
iscsit_close_session(sess);
return 0;
@@ -4557,7 +4558,6 @@ int iscsit_free_session(struct iscsi_session *sess)
int is_last;
spin_lock_bh(&sess->conn_lock);
- atomic_set(&sess->sleep_on_sess_wait_comp, 1);
list_for_each_entry_safe(conn, conn_tmp, &sess->sess_conn_list,
conn_list) {
@@ -4585,7 +4585,10 @@ int iscsit_free_session(struct iscsi_session *sess)
if (atomic_read(&sess->nconn)) {
spin_unlock_bh(&sess->conn_lock);
+ atomic_inc(&sess->sleep_on_sess_wait_comp);
wait_for_completion(&sess->session_wait_comp);
+ atomic_dec(&sess->sleep_on_sess_wait_comp);
+ WARN_ON(atomic_read(&sess->sleep_on_sess_wait_comp));
} else
spin_unlock_bh(&sess->conn_lock);
@@ -4603,8 +4606,6 @@ void iscsit_stop_session(
int is_last;
spin_lock_bh(&sess->conn_lock);
- if (session_sleep)
- atomic_set(&sess->sleep_on_sess_wait_comp, 1);
if (connection_sleep) {
list_for_each_entry_safe(conn, conn_tmp, &sess->sess_conn_list,
@@ -4636,7 +4637,10 @@ void iscsit_stop_session(
if (session_sleep && atomic_read(&sess->nconn)) {
spin_unlock_bh(&sess->conn_lock);
+ atomic_inc(&sess->sleep_on_sess_wait_comp);
wait_for_completion(&sess->session_wait_comp);
+ atomic_dec(&sess->sleep_on_sess_wait_comp);
+ WARN_ON(atomic_read(&sess->sleep_on_sess_wait_comp);
} else
spin_unlock_bh(&sess->conn_lock);
}
--
2.6.6
^ permalink raw reply related
* Re: iscsi_trx going into D state
From: Johannes Thumshirn @ 2016-10-04 7:55 UTC (permalink / raw)
To: Robert LeBlanc
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAANLjFoj9-qscJOSf2jtKYt2+4cQxMHNJ9q2QTey4wyG5OTSAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Sep 30, 2016 at 11:14:57AM -0600, Robert LeBlanc wrote:
> We are having a reoccurring problem where iscsi_trx is going into D
> state. It seems like it is waiting for a session tear down to happen
> or something, but keeps waiting. We have to reboot these targets on
> occasion. This is running the 4.4.12 kernel and we have seen it on
> several previous 4.4.x and 4.2.x kernels. There is no message in dmesg
> or /var/log/messages. This seems to happen with increased frequency
> when we have a disruption in our Infiniband fabric, but can happen
> without any changes to the fabric (other than hosts rebooting).
>
> # ps aux | grep iscsi | grep D
> root 4185 0.0 0.0 0 0 ? D Sep29 0:00 [iscsi_trx]
> root 18505 0.0 0.0 0 0 ? D Sep29 0:00 [iscsi_np]
>
> # cat /proc/4185/stack
> [<ffffffff814cc999>] target_wait_for_sess_cmds+0x49/0x1a0
> [<ffffffffa087292b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
> [<ffffffff814f0de2>] iscsit_close_connection+0x162/0x840
> [<ffffffff814df8df>] iscsit_take_action_for_connection_exit+0x7f/0x100
> [<ffffffff814effc0>] iscsi_target_rx_thread+0x5a0/0xe80
> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> # cat /proc/18505/stack
> [<ffffffff814f0c71>] iscsit_stop_session+0x1b1/0x1c0
> [<ffffffff814e2436>] iscsi_check_for_session_reinstatement+0x1e6/0x270
> [<ffffffff814e4df0>] iscsi_target_check_for_existing_instances+0x30/0x40
> [<ffffffff814e4f40>] iscsi_target_do_login+0x140/0x640
> [<ffffffff814e62dc>] iscsi_target_start_negotiation+0x1c/0xb0
> [<ffffffff814e402b>] iscsi_target_login_thread+0xa9b/0xfc0
> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> What can we do to help get this resolved?
>
> Thanks,
>
> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I've encountered the same issue and found a hack to fix it at [1] but I think
the correct way for handling this issue would be like you said to tear down
the session in case a TASK ABORT times out. Unfortunately I'm not really
familiar with the target code myself so I mainly use this reply to get me into
the Cc loop.
[1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
--
Johannes Thumshirn Storage
jthumshirn-l3A5Bk7waGM@public.gmane.org +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: David Miller @ 2016-10-04 3:24 UTC (permalink / raw)
To: Yuval.Mintz
Cc: netdev, linux-rdma, Ram.Amrani, Michal.Kalderon, Ariel.Elior,
dledford
In-Reply-To: <1475348401-31392-1-git-send-email-Yuval.Mintz@caviumnetworks.com>
From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Date: Sat, 1 Oct 2016 21:59:54 +0300
> In the last couple of weeks we've been sending RFCs for the qedr
> driver - the RoCE driver for QLogic FastLinQ 4xxxx line of adapters.
> Latest RFC can be found at [1].
>
> At Doug's advice [2], we've decided to split the series into two:
> - first part contains the qed backbone that's necessary for all the
> configurations relating to the qedr driver, as well as the qede
> infrastructure that is used for communication between the qedr and qede.
> - Second part consists of the actual qedr driver and introduces almost
> no changes to qed/qede.
>
> This is the first of said two parts. The second half would be sent
> later this week.
>
> The only 'oddity' in the devision are the Kconfig options -
> As this series introduces both LL2 and QEDR-based logic in qed/qede,
> I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
> Otherwise, a lot of the code introduced would be dead-code [won't even
> be compiled] until qedr is accepted.
> As a result I've placed the config option in an odd place - under
> qlogic's Kconfig. The second series would then remove that option
> and add it in its correct place under the infiniband Kconfig.
> [I'm fine with pushing it there to begin with, but I didn't want to
> 'contaminate' non-qlogic configuration files with half-baked options].
>
> Dave - I don't think you were E-mailed with Doug's suggestion.
> I think the notion was to have the two halves accepted side-by-side,
> but actually the first has no dependency issues, so it's also
> possible to simply take this first to net-next, and push the qedr
> into rdma once it's merged. But it's basically up to you and Doug;
> We'd align with whatever suits you best.
I'll take this, series applied, thanks.
^ permalink raw reply
* RE: [PATCH] ibacm: move Documentation to Documentation/
From: Hefty, Sean @ 2016-10-03 18:04 UTC (permalink / raw)
To: Jason Gunthorpe, Christoph Hellwig
Cc: Christoph Hellwig,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161003175257.GA9620-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> > > Who is merging patches that are submitted to the mailing list?
> > > AFAIK, I don't have write access to the repo.
>
> Doug and Leon - however I belive Leon is on a break right now.
>
> Sean, do you want write access too?
Either way, really. I could merge in changes to ibacm and librdmacm, but those haven't gotten many updates recently. So, if Doug is already going to pull in mailing list patches for verbs, I'm fine with him pulling those changes in as well.
- Sean
--
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
^ permalink raw reply
* Re: [PATCH] ibacm: move Documentation to Documentation/
From: Jason Gunthorpe @ 2016-10-03 17:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Hefty, Sean, Christoph Hellwig,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161003163611.GA1496-jcswGhMUV9g@public.gmane.org>
On Mon, Oct 03, 2016 at 06:36:11PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 03, 2016 at 02:44:27PM +0000, Hefty, Sean wrote:
> > Who is merging patches that are submitted to the mailing list?
> > AFAIK, I don't have write access to the repo.
Doug and Leon - however I belive Leon is on a break right now.
Sean, do you want write access too?
> Doug should eventually apply it I think, although previous patches
> were staged by Jason and sent on to Doug.
Right, I grabbed a bunch of stuff at the start and handled rebasing
them/etc. Expect Doug or Leon in future to handle that stuff.
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
^ permalink raw reply
* Re: [PATCH] ibacm: move Documentation to Documentation/
From: Christoph Hellwig @ 2016-10-03 16:36 UTC (permalink / raw)
To: Hefty, Sean
Cc: Christoph Hellwig, Christoph Hellwig,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB092274-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Mon, Oct 03, 2016 at 02:44:27PM +0000, Hefty, Sean wrote:
> Who is merging patches that are submitted to the mailing list? AFAIK, I don't have write access to the repo.
Doug should eventually apply it I think, although previous patches
were staged by Jason and sent on to Doug.
--
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
^ permalink raw reply
* Re: [PATCH 0/4] Two fixes for prev 4.9 and two new fixes
From: Doug Ledford @ 2016-10-03 15:33 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mike Marciniszyn, Ira Weiny,
Jianxin Xiong
In-Reply-To: <20161001030935.15264.34730.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1220 bytes --]
On 9/30/2016 11:10 PM, Dennis Dalessandro wrote:
> Doug,
>
> The first two patches here are fixes for patches you picked up in your hfi1
> branch for 4.9. You may want to squash them. The commit SHAs referrenced are
> from your GitHub repo.
>
> Pathces 3 and 4 are new fixes for 4.9.
Thanks, I squashed the two fixes in and applied the other two.
> Patches can also be viewed in my repo at:
> https://github.com/ddalessa/kernel/tree/for-4.9
>
> ---
>
> Ira Weiny (1):
> IB/hfi1: Fix invalid lockdep assert
>
> Jianxin Xiong (1):
> IB/hfi1: Update SMA ingress checks for response packets
>
> Mike Marciniszyn (2):
> IB/core: Fix atomic regression with ib_hdrs
> IB/hfi1: Fix trace of atomic ack
>
>
> drivers/infiniband/hw/hfi1/qp.c | 1 -
> drivers/infiniband/hw/hfi1/trace.c | 4 +--
> drivers/infiniband/hw/hfi1/ud.c | 49 ++++++++++++++++++------------------
> drivers/infiniband/hw/hfi1/verbs.c | 2 +
> include/rdma/ib_hdrs.h | 6 ++--
> 5 files changed, 30 insertions(+), 32 deletions(-)
>
> --
> -Denny
>
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/rdmavt: Trivial function comment corrected.
From: Doug Ledford @ 2016-10-03 14:55 UTC (permalink / raw)
To: Parav Pandit, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1473775850-11991-1-git-send-email-pandit.parav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]
On 9/13/2016 10:10 AM, Parav Pandit wrote:
> Corrected function name in comment from qib_ to rvt_.
>
> Signed-off-by: Parav Pandit <pandit.parav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/infiniband/sw/rdmavt/qp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rdmavt/qp.c b/drivers/infiniband/sw/rdmavt/qp.c
> index bdb540f..40186ca 100644
> --- a/drivers/infiniband/sw/rdmavt/qp.c
> +++ b/drivers/infiniband/sw/rdmavt/qp.c
> @@ -996,7 +996,7 @@ static void rvt_insert_qp(struct rvt_dev_info *rdi, struct rvt_qp *qp)
> }
>
> /**
> - * qib_modify_qp - modify the attributes of a queue pair
> + * rvt_modify_qp - modify the attributes of a queue pair
> * @ibqp: the queue pair who's attributes we're modifying
> * @attr: the new attributes
> * @attr_mask: the mask of attributes to modify
>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] cxgb4 FR_NSMR_TPTE_WR support
From: Doug Ledford @ 2016-10-03 14:50 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, linux-rdma, 'David Miller'
In-Reply-To: <023401d2190b$03b00e50$0b102af0$@opengridcomputing.com>
[-- Attachment #1.1: Type: text/plain, Size: 710 bytes --]
On 9/27/2016 6:03 PM, Steve Wise wrote:
>>
>>>
>>>>
>>>> From: Steve Wise <swise@opengridcomputing.com>
>>>> Date: Fri, 16 Sep 2016 07:54:55 -0700
>>>>
>>>>> This series enables a new work request to optimize small REG_MR
>>>>> operations. This is intended for 4.9. If everyone agrees, I suggest
>>>>> Doug take both the cxgb4 and iw_cxgb4 patches through his tree.
>>>>
>>>> I'm assuming this mean that I do _not_ apply these to my tree.
>>>
>>> Yes, if you're ok with that.
>>
>> I am.
>
> Doug, please include this for 4.9 if it looks good to you. Let me know.
>
> Thanks,
>
> Steve.
>
Applied, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] IB/hfi1: Read platform configuration file from EPROM
From: Doug Ledford @ 2016-10-03 14:46 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Easwar Hariharan, Dean Luick
In-Reply-To: <20160930114009.12716.95241.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1016 bytes --]
On 9/30/2016 7:41 AM, Dennis Dalessandro wrote:
> Doug,
>
> This series adds the capability to read configuration information used to init
> the link from the EPROM.
>
> It partially undoes some of the work that was removed when we removed the
> user access. This is not done though in support of user access. This is only so
> the driver can read the EPROM. All user access is still only through resource0.
>
> Series applies on previously submitted patches and should apply cleanly to your
> for-4.9 branch. Can also be seen in GitHub at:
> https://github.com/ddalessa/kernel/tree/for-4.9
>
> Changes from v1:
> Squash the first two patches per Jason's request
>
> ---
>
> Dean Luick (3):
> IB/hfi1: Restore EPROM read ability
> IB/hfi1: Add ability to read platform config from the EPROM
> IB/hfi1: Use EPROM platform configuration read
Thanks, series applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* RE: [PATCH] ibacm: move Documentation to Documentation/
From: Hefty, Sean @ 2016-10-03 14:44 UTC (permalink / raw)
To: Christoph Hellwig, Christoph Hellwig
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161003143412.GA18210-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Who is merging patches that are submitted to the mailing list? AFAIK, I don't have write access to the repo.
> ping?
>
> On Fri, Sep 23, 2016 at 05:34:39PM -0700, Christoph Hellwig wrote:
> > And drop various bits that aren't relevant for our unified tree
> > (Windows support, build instructions, etc).
> >
> > Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> > ---
> > Documentation/ibacm.md | 109 ++++++++++++++++++++++++++++++++++++++
> > ibacm/acm_notes.txt | 141 ---------------------------------------
> ----------
> > 2 files changed, 109 insertions(+), 141 deletions(-)
> > create mode 100644 Documentation/ibacm.md
> > delete mode 100644 ibacm/acm_notes.txt
> >
> > diff --git a/Documentation/ibacm.md b/Documentation/ibacm.md
> > new file mode 100644
> > index 0000000..8ed293d
> > --- /dev/null
> > +++ b/Documentation/ibacm.md
> > @@ -0,0 +1,109 @@
> > +# The Assistant for InfiniBand Communication Management (IB ACM)
> > +
> > +The IB ACM library implements and provides a framework for name,
> address, and
> > +route resolution services over InfiniBand. The IB ACM provides
> information
> > +needed to establish a connection, but does not implement the CM
> protocol.
> > +
> > +IB ACM services are used by librdmacm to implement the
> rdma_resolve_addr,
> > +rdma_resolve_route, and rdma_getaddrinfo routines.
> > +
> > +The IB ACM is focused on being scalable and efficient. The current
> > +implementation limits network traffic, SA interactions, and
> centralized
> > +services. ACM supports multiple resolution protocols in order to
> handle
> > +different fabric topologies.
> > +
> > +This release is limited in its handling of dynamic changes.
> > +
> > +The IB ACM package is comprised of two components: the ibacm service
> > +and a test/configuration utility - ib_acme.
> > +
> > +# Details
> > +
> > +### ib_acme
> > +
> > +The ib_acme program serves a dual role. It acts as a utility to
> test
> > +ibacm operation and help verify if the ibacm service and selected
> > +protocol is usable for a given cluster configuration.
> Additionally,
> > +it automatically generates ibacm configuration files to assist with
> > +or eliminate manual setup.
> > +
> > +
> > +### acm configuration files
> > +
> > +The ibacm service relies on two configuration files.
> > +
> > +The acm_addr.cfg file contains name and address mappings for each IB
> > +<device, port, pkey> endpoint. Although the names in the
> acm_addr.cfg
> > +file can be anything, ib_acme maps the host name and IP addresses to
> > +the IB endpoints.
> > +
> > +The acm_opts.cfg file provides a set of configurable options for the
> > +ibacm service, such as timeout, number of retries, logging level,
> etc.
> > +ib_acme generates the acm_opts.cfg file using static information. A
> > +future enhancement would adjust options based on the current system
> > +and cluster size.
> > +
> > +### ibacm
> > +
> > +The ibacm service is responsible for resolving names and addresses
> to
> > +InfiniBand path information and caching such data. It is implemented
> as a
> > +daemon that execute with administrative privileges.
> > +
> > +The ibacm implements a client interface over TCP sockets, which is
> > +abstracted by the librdmacm library. One or more back-end protocols
> are
> > +used by the ibacm service to satisfy user requests. Although the
> > +ibacm supports standard SA path record queries on the back-end, it
> > +provides an experimental multicast resolution protocol in hope of
> > +achieving greater scalability. The latter is not usable on all
> fabric
> > +topologies, specifically ones that may not have reversible paths.
> > +Users should use the ib_acme utility to verify that multicast
> protocol
> > +is usable before running other applications.
> > +
> > +Conceptually, the ibacm service implements an ARP like protocol and
> either
> > +uses IB multicast records to construct path record data or queries
> the
> > +SA directly, depending on the selected route protocol. By default,
> the
> > +ibacm services uses and caches SA path record queries.
> > +
> > +Specifically, all IB endpoints join a number of multicast groups.
> > +Multicast groups differ based on rates, mtu, sl, etc., and are
> prioritized.
> > +All participating endpoints must be able to communicate on the
> lowest
> > +priority multicast group. The ibacm assigns one or more
> names/addresses
> > +to each IB endpoint using the acm_addr.cfg file. Clients provide
> source
> > +and destination names or addresses as input to the service, and
> receive
> > +as output path record data.
> > +
> > +The service maps a client's source name/address to a local IB
> endpoint.
> > +If a client does not provide a source address, then the ibacm
> service
> > +will select one based on the destination and local routing tables.
> If the
> > +destination name/address is not cached locally, it sends a multicast
> > +request out on the lowest priority multicast group on the local
> endpoint.
> > +The request carries a list of multicast groups that the sender can
> use.
> > +The recipient of the request selects the highest priority multicast
> group
> > +that it can use as well and returns that information directly to the
> sender.
> > +The request data is cached by all endpoints that receive the
> multicast
> > +request message. The source endpoint also caches the response and
> uses
> > +the multicast group that was selected to construct or obtain path
> record
> > +data, which is returned to the client.
> > +
> > +The current implementation of the IB ACM has several additional
> restrictions:
> > +- The ibacm is limited in its handling of dynamic changes;
> > + the ibacm should be stopped and restarted if a cluster is
> reconfigured.
> > +- Support for IPv6 has not been verified.
> > +- The number of addresses that can be assigned to a single endpoint
> is
> > + limited to 4.
> > +- The number of multicast groups that an endpoint can support is
> limited to 2.
> > +
> > +The ibacm contains several internal caches. These include caches
> for
> > +GID and LID destination addresses. These caches can be
> optionally
> > +preloaded. ibacm supports the OpenSM dump_pr plugin "full"
> PathRecord
> > +format which is used to preload these caches. The file format is
> specified
> > +in the ibacm_opts.cfg file via the route_preload setting which
> should
> > +be set to opensm_full_v1 for this file format. Default format is
> > +none which does not preload these caches. See dump_pr.notes.txt in
> dump_pr
> > +for more information on the opensm_full_v1 file format and how to
> configure
> > +OpenSM to generate this file.
> > +
> > +Additionally, the name, IPv4, and IPv6 caches can be be preloaded by
> using
> > +the addr_preload option. The default is none which does not preload
> these
> > +caches. To preload these caches, set this option to acm_hosts and
> > +configure the addr_data_file appropriately.
> > diff --git a/ibacm/acm_notes.txt b/ibacm/acm_notes.txt
> > deleted file mode 100644
> > index c975555..0000000
> > --- a/ibacm/acm_notes.txt
> > +++ /dev/null
> > @@ -1,141 +0,0 @@
> > -Assistant for InfiniBand Communication Management (IB ACM)
> > -
> > -Note: The IB ACM should be considered experimental.
> > -
> > -
> > -Overview
> > ---------
> > -The IB ACM package implements and provides a framework for
> experimental name,
> > -address, and route resolution services over InfiniBand. It is
> intended to
> > -address connection setup scalability issues running MPI applications
> on
> > -large clusters. The IB ACM provides information needed to establish
> a
> > -connection, but does not implement the CM protocol.
> > -
> > -The librdmacm can invoke IB ACM services when built using the --
> with-ib_acm
> > -option. The IB ACM services tie in under the rdma_resolve_addr,
> > -rdma_resolve_route, and rdma_getaddrinfo routines. For maximum
> benefit,
> > -the rdma_getaddrinfo routine should be used, however existing
> applications
> > -should still see significant connection scaling benefits using the
> calls
> > -available in librdmacm 1.0.11 and previous releases.
> > -
> > -The IB ACM is focused on being scalable and efficient. The current
> > -implementation limits network traffic, SA interactions, and
> centralized
> > -services. ACM supports multiple resolution protocols in order to
> handle
> > -different fabric topologies.
> > -
> > -This release is limited in its handling of dynamic changes.
> > -
> > -The IB ACM package is comprised of two components: the ibacm service
> > -and a test/configuration utility - ib_acme. Both are userspace
> components
> > -and are available for Linux and Windows. Additional details are
> given below.
> > -
> > -
> > -Quick Start Guide
> > ------------------
> > -1. Prerequisites: libibverbs and libibumad must be installed.
> > - The IB stack should be running with IPoIB configured.
> > - These steps assume that the user has administrative privileges.
> > -2. Install the IB ACM package
> > - This installs ibacm, and ib_acme.
> > -3. Run ib_acme -A -O
> > - This will generate IB ACM address and options configuration
> files.
> > - (acm_addr.cfg and acm_opts.cfg)
> > -4. Run ibacm -D
> > - This will run ibacm as service/daemon.
> > - Because ibacm uses the libibumad interfaces, it should be run
> with
> > - administrative privileges.
> > -5. Optionally, run ib_acme -s <source_ip> -d <dest_ip> -v
> > - This will verify that the ibacm service is running.
> > -5. Install librdmacm.
> > - The librdmacm will automatically use the ibacm service.
> > - On failures, the librdmacm will fall back to normal resolution.
> > -
> > -
> > -Details
> > --------
> > -ib_acme:
> > -The ib_acme program serves a dual role. It acts as a utility to
> test
> > -ibacm operation and help verify if the ibacm service and selected
> > -protocol is usable for a given cluster configuration.
> Additionally,
> > -it automatically generates ibacm configuration files to assist with
> > -or eliminate manual setup.
> > -
> > -
> > -acm configuration files:
> > -The ibacm service relies on two configuration files.
> > -
> > -The acm_addr.cfg file contains name and address mappings for each IB
> > -<device, port, pkey> endpoint. Although the names in the
> acm_addr.cfg
> > -file can be anything, ib_acme maps the host name and IP addresses to
> > -the IB endpoints.
> > -
> > -The acm_opts.cfg file provides a set of configurable options for the
> > -ibacm service, such as timeout, number of retries, logging level,
> etc.
> > -ib_acme generates the acm_opts.cfg file using static information. A
> > -future enhancement would adjust options based on the current system
> > -and cluster size.
> > -
> > -
> > -ibacm:
> > -The ibacm service is responsible for resolving names and addresses
> to
> > -InfiniBand path information and caching such data. It is implemented
> as a
> > -daemon that execute with administrative privileges.
> > -
> > -The ibacm implements a client interface over TCP sockets, which is
> > -abstracted by the librdmacm library. One or more back-end protocols
> are
> > -used by the ibacm service to satisfy user requests. Although the
> > -ibacm supports standard SA path record queries on the back-end, it
> > -provides an experimental multicast resolution protocol in hope of
> > -achieving greater scalability. The latter is not usable on all
> fabric
> > -topologies, specifically ones that may not have reversible paths.
> > -Users should use the ib_acme utility to verify that multicast
> protocol
> > -is usable before running other applications.
> > -
> > -Conceptually, the ibacm service implements an ARP like protocol and
> either
> > -uses IB multicast records to construct path record data or queries
> the
> > -SA directly, depending on the selected route protocol. By default,
> the
> > -ibacm services uses and caches SA path record queries.
> > -
> > -Specifically, all IB endpoints join a number of multicast groups.
> > -Multicast groups differ based on rates, mtu, sl, etc., and are
> prioritized.
> > -All participating endpoints must be able to communicate on the
> lowest
> > -priority multicast group. The ibacm assigns one or more
> names/addresses
> > -to each IB endpoint using the acm_addr.cfg file. Clients provide
> source
> > -and destination names or addresses as input to the service, and
> receive
> > -as output path record data.
> > -
> > -The service maps a client's source name/address to a local IB
> endpoint.
> > -If a client does not provide a source address, then the ibacm
> service
> > -will select one based on the destination and local routing tables.
> If the
> > -destination name/address is not cached locally, it sends a multicast
> > -request out on the lowest priority multicast group on the local
> endpoint.
> > -The request carries a list of multicast groups that the sender can
> use.
> > -The recipient of the request selects the highest priority multicast
> group
> > -that it can use as well and returns that information directly to the
> sender.
> > -The request data is cached by all endpoints that receive the
> multicast
> > -request message. The source endpoint also caches the response and
> uses
> > -the multicast group that was selected to construct or obtain path
> record
> > -data, which is returned to the client.
> > -
> > -The current implementation of the IB ACM has several additional
> restrictions:
> > -- The ibacm is limited in its handling of dynamic changes;
> > - the ibacm should be stopped and restarted if a cluster is
> reconfigured.
> > -- Support for IPv6 has not been verified.
> > -- The number of addresses that can be assigned to a single endpoint
> is
> > - limited to 4.
> > -- The number of multicast groups that an endpoint can support is
> limited to 2.
> > -
> > -The ibacm contains several internal caches. These include caches
> for
> > -GID and LID destination addresses. These caches can be
> optionally
> > -preloaded. ibacm supports the OpenSM dump_pr plugin "full"
> PathRecord
> > -format which is used to preload these caches. The file format is
> specified
> > -in the ibacm_opts.cfg file via the route_preload setting which
> should
> > -be set to opensm_full_v1 for this file format. Default format is
> > -none which does not preload these caches. See dump_pr.notes.txt in
> dump_pr
> > -for more information on the opensm_full_v1 file format and how to
> configure
> > -OpenSM to generate this file.
> > -
> > -Additionally, the name, IPv4, and IPv6 caches can be be preloaded by
> using
> > -the addr_preload option. The default is none which does not preload
> these
> > -caches. To preload these caches, set this option to acm_hosts and
> > -configure the addr_data_file appropriately.
> > --
> > 2.1.4
> >
> > --
> > 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
> ---end quoted text---
> --
> 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
--
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
^ permalink raw reply
* Re: [PATCH] IB/core: correctly handle rdma_rw_init_mrs() failure
From: Doug Ledford @ 2016-10-03 14:44 UTC (permalink / raw)
To: Steve Wise
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ
In-Reply-To: <20160929143217.F2C8DE0BD1-/5N3P9jjx0xzbRFIqnYvSA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2910 bytes --]
On 9/29/2016 10:31 AM, Steve Wise wrote:
> Function ib_create_qp() was failing to return an error when
> rdma_rw_init_mrs() fails, causing a crash further down in ib_create_qp()
> when trying to dereferece the qp pointer which was actually a negative
> errno.
>
> The crash:
>
> crash> log|grep BUG
> [ 136.458121] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
> crash> bt
> PID: 3736 TASK: ffff8808543215c0 CPU: 2 COMMAND: "kworker/u64:2"
> #0 [ffff88084d323340] machine_kexec at ffffffff8105fbb0
> #1 [ffff88084d3233b0] __crash_kexec at ffffffff81116758
> #2 [ffff88084d323480] crash_kexec at ffffffff8111682d
> #3 [ffff88084d3234b0] oops_end at ffffffff81032bd6
> #4 [ffff88084d3234e0] no_context at ffffffff8106e431
> #5 [ffff88084d323530] __bad_area_nosemaphore at ffffffff8106e610
> #6 [ffff88084d323590] bad_area_nosemaphore at ffffffff8106e6f4
> #7 [ffff88084d3235a0] __do_page_fault at ffffffff8106ebdc
> #8 [ffff88084d323620] do_page_fault at ffffffff8106f057
> #9 [ffff88084d323660] page_fault at ffffffff816e3148
> [exception RIP: ib_create_qp+427]
> RIP: ffffffffa02554fb RSP: ffff88084d323718 RFLAGS: 00010246
> RAX: 0000000000000004 RBX: fffffffffffffff4 RCX: 000000018020001f
> RDX: ffff880830997fc0 RSI: 0000000000000001 RDI: ffff88085f407200
> RBP: ffff88084d323778 R8: 0000000000000001 R9: ffffea0020bae210
> R10: ffffea0020bae218 R11: 0000000000000001 R12: ffff88084d3237c8
> R13: 00000000fffffff4 R14: ffff880859fa5000 R15: ffff88082eb89800
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #10 [ffff88084d323780] rdma_create_qp at ffffffffa0782681 [rdma_cm]
> #11 [ffff88084d3237b0] nvmet_rdma_create_queue_ib at ffffffffa07c43f3 [nvmet_rdma]
> #12 [ffff88084d323860] nvmet_rdma_alloc_queue at ffffffffa07c5ba9 [nvmet_rdma]
> #13 [ffff88084d323900] nvmet_rdma_queue_connect at ffffffffa07c5c96 [nvmet_rdma]
> #14 [ffff88084d323980] nvmet_rdma_cm_handler at ffffffffa07c6450 [nvmet_rdma]
> #15 [ffff88084d3239b0] iw_conn_req_handler at ffffffffa0787480 [rdma_cm]
> #16 [ffff88084d323a60] cm_conn_req_handler at ffffffffa0775f06 [iw_cm]
> #17 [ffff88084d323ab0] process_event at ffffffffa0776019 [iw_cm]
> #18 [ffff88084d323af0] cm_work_handler at ffffffffa0776170 [iw_cm]
> #19 [ffff88084d323cb0] process_one_work at ffffffff810a1483
> #20 [ffff88084d323d90] worker_thread at ffffffff810a211d
> #21 [ffff88084d323ec0] kthread at ffffffff810a6c5c
> #22 [ffff88084d323f50] ret_from_fork at ffffffff816e1ebf
>
> Fixes: 632bc3f65081 ("IB/core, RDMA RW API: Do not exceed QP SGE send limit")
> Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ 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