HFI1 code duplication todo

The major todo for the hfi1 driver in staging is getting rid of the verbs code duplication between ipath, qib, and now hfi1. The ipath driver has been deprecated and is going to be deleted soon. So that leaves qib and hfi. To address this we have proposed rdmavt which will be a common kmod that

Re: [PATCH] IB/mad: In validate_mad, validate CM method and attribute

On Thu, Nov 12, 2015 at 08:30:55PM +, Hefty, Sean wrote: > > > + /* CM attributes other than ClassPortInfo only use Send method > > */ > > > + if (mad_hdr->mgmt_class == IB_MGMT_CLASS_CM) { > > > + if (mad_hdr->attr_id != IB_MGMT_CLASSPORTINFO_ATTR_ID) { > > > +

RE: [PATCH] IB/mad: In validate_mad, validate CM method and attribute

> > + /* CM attributes other than ClassPortInfo only use Send method > */ > > + if (mad_hdr->mgmt_class == IB_MGMT_CLASS_CM) { > > + if (mad_hdr->attr_id != IB_MGMT_CLASSPORTINFO_ATTR_ID) { > > + if (mad_hdr->method !=

RE: [PATCH] IB/mad: In validate_mad, validate CM method and attribute

> IIRC responding to Get(CPI) is mandatory? Maybe the drivers are responding? I don't believe that the CM does. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: srp state in current mainline

On 11/12/2015 09:59 AM, Christoph Hellwig wrote: [ 108.998574] WARNING: CPU: 0 PID: 1258 at kernel/sched/core.c:7389 __might_sleep+0xa7/0xb0() [ 108.998580] do not call blocking ops when !TASK_RUNNING; state=1 set Although this is most likely unrelated to the issue reported at the start of

[PATCH] IB/mad: In validate_mad, validate CM method and attribute

Receipt of CM MAD with response method for other than ClassPortInfo attribute is invalid. CM attributes other than ClassPortInfo use send method only and GetResp is valid for ClassPortInfo attribute. Note also that the CM ClassPortInfo is not currently supported. The SRP initiator does not

RE: [PATCH 12/13] staging/rdma/hfi1: Read EFI variable for device description

> -Original Message- > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, November 11, 2015 11:24 AM > > If you move the variables to the top and have the early return as you > > suggest, > then in some CONFIG cases, there will be all those automatic

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

On Wed, 28 Oct 2015 at 04:30:10 +, Weiny, Ira wrote: > Until we can remove the spinlock the current proposed patch should be applied > in the interim. Sorry for the noise before. > Reviewed-By: Ira Weiny Hi, is this patch expected to be applied ? -- To unsubscribe

Re: srp state in current mainline

On Thu, Nov 12, 2015 at 05:12:14PM -0800, Bart Van Assche wrote: > On 11/12/2015 09:59 AM, Christoph Hellwig wrote: > >[ 108.998574] WARNING: CPU: 0 PID: 1258 at kernel/sched/core.c:7389 > >__might_sleep+0xa7/0xb0() > >[ 108.998580] do not call blocking ops when !TASK_RUNNING; state=1 set > >

Fwd: [PATCH] svcrdma: Do not send XDR roundup bytes for a write chunk

I wish git send-mail had an address book. I’m really tired of misspelling the to/cc addresses on patches. Resending so there is one thread for all replies. Apologies for the noise. > Begin forwarded message: > > From: Chuck Lever > Subject: [PATCH] svcrdma: Do not send

Re: [PATCH] svcrdma: Do not send XDR roundup bytes for a write chunk

> On Nov 12, 2015, at 9:19 AM, J. Bruce Fields wrote: > > On Wed, Nov 11, 2015 at 03:20:33PM -0500, Chuck Lever wrote: >> >>> On Nov 3, 2015, at 3:10 PM, Chuck Lever wrote: >>> >>> On Oct 16, 2015, at 9:30 AM, Chuck Lever

Re: [PATCH] svcrdma: Do not send XDR roundup bytes for a write chunk

On Wed, Nov 11, 2015 at 03:20:33PM -0500, Chuck Lever wrote: > > > On Nov 3, 2015, at 3:10 PM, Chuck Lever wrote: > > > > > >> On Oct 16, 2015, at 9:30 AM, Chuck Lever wrote: > >> > >> Minor optimization: when dealing with write chunk XDR

Re: Fwd: [PATCH] svcrdma: Do not send XDR roundup bytes for a write chunk

On Thu, Nov 12, 2015 at 09:47:13AM -0500, Chuck Lever wrote: > I wish git send-mail had an address book. I’m really tired > of misspelling the to/cc addresses on patches. Hah. Yeah, my hack is a text file of addresses that I cut-and-paste from. --b. > > Resending so there is one thread for

Re: [PATCH] staging/rdma/hfi1: Reduce number of parameters passed to send handlers

On Thu, Nov 12, 2015 at 3:25 PM, Dennis Dalessandro wrote: > On Thu, Nov 12, 2015 at 08:04:01AM +0200, Or Gerlitz wrote: >> Dennis, can we have less camelcase sort of speak in this upstream driver? >> this is linux here not windowZ. > I plan to just remove this

RE: [PATCH] IB/mad: In validate_mad, validate CM method and attribute

> Receipt of CM MAD with response method for other than ClassPortInfo > attribute is invalid. > > CM attributes other than ClassPortInfo use send method only > and GetResp is valid for ClassPortInfo attribute. > Note also that the CM ClassPortInfo is not currently supported. > > The SRP

Re: srp state in current mainline

On Wed, Nov 11, 2015 at 01:07:44PM -0800, Bart Van Assche wrote: > On 11/10/2015 09:15 AM, Christoph Hellwig wrote: > >scsi host3: ib_srp: failed receive status WR flushed (5) for iu > >880313f4ca40 > > Can you also post the logs from the target system from around the time this > message was

Re: [PATCH] IB/mad: In validate_mad, validate CM method and attribute

On Thu, Nov 12, 2015 at 01:48:50PM +0200, Hal Rosenstock wrote: > > Receipt of CM MAD with response method for other than ClassPortInfo > attribute is invalid. > > CM attributes other than ClassPortInfo use send method only > and GetResp is valid for ClassPortInfo attribute. > Note also that the

Re: RDMAVT pull request

On Mon, Nov 09, 2015 at 09:25:53AM -0500, Dennis Dalessandro wrote: On Mon, Nov 09, 2015 at 01:32:03PM +, Kamal Heib wrote: Hi Dennis, I forked from your rdmavt project at Github and created pull request [1]. Could you please check my pull request for the following patches: Author:

Re: [PATCH] IB/mad: In validate_mad, validate CM method and attribute

On 11/12/2015 03:48 AM, Hal Rosenstock wrote: A new SRP target has been observed to respond to Send CM REQ with GetResp of CM REQ with bad status. This is non conformant with IBA spec but exposes a vulnerability in the current MAD/CM code which will respond to the incoming GetResp of CM REQ as

Re: Fwd: [PATCH] svcrdma: Do not send XDR roundup bytes for a write chunk

On Thu, Nov 12, 2015 at 09:47:13AM -0500, Chuck Lever wrote: > I wish git send-mail had an address book. I’m really tired > of misspelling the to/cc addresses on patches. It does: CONFIGURATION sendemail.aliasesfile To avoid typing long email addresses, point this to one or