On 19/11/2015 01:00, Bart Van Assche wrote:
If srp_connect_ch() returns a positive value then that is considered
by its caller as a connection failure but this does not result in a
scsi_host_put() call and additionally causes the srp_create_target()
function to return a positive value while it
Ensure that validate_ipv4_net_dev() calls rcu_read_unlock() if
fib_lookup() fails. Detected by sparse. Compile-tested only.
Fixes: "IB/cma: Validate routing of incoming requests" (commit f887f2ac87c2).
Cc: Haggai Eran
Cc: stable
Looks good,
Reviewed-by: Sagi Grimberg
--
To unsubscribe fro
do_div is the wrong way to divide a sector_t, as it is less
efficient when sector_t is 32-bit wide. With the upcoming
do_div optimizations, the kernel starts warning about this:
drivers/infiniband/ulp/iser/iser_verbs.c:1296:4: note: in expansion of macro
'do_div'
include/asm-generic/div64.h:22
From: Ira Weiny
sdma_select_engine_vl only needs to protect itself from an invalid VL.
Something higher up the stack should be warning the user when they try
to use an SL which maps to an invalid VL.
Reviewed-by: Dean Luick
Reviewed-by: Mike Marciniszyn
Reviewed-by: Kaike Wan
Signed-off-by: I
On Fri, Nov 20, 2015 at 09:00:23AM -0800, Greg KH wrote:
> On Fri, Nov 20, 2015 at 04:43:56PM +, Marciniszyn, Mike wrote:
> > > >
> > > > Is the inprocess branch available?
> > >
> > > I do not understand what you mean here :(
> >
> > Does it fail to apply to staging-next or staging-testing o
hfi1 driver build fails with the following error:
In function ‘handle_receive_interrupt’:
error: implicit declaration of function ‘skip_rcv_packet’
[-Werror=implicit-function-declaration]
last = skip_rcv_packet(&packet, thread);
^
This is due to the inclusion of the skip_rcv_packet() in th
On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> So, as to the hfi1/qib/rxe transport library. The qib driver is in the
> rdma tree, and we aren't going to move it to staging just because it
> depends on something in staging, so we need to start adding the library
> in the core tree
On Fri, Nov 20, 2015 at 03:21:14PM +, Marciniszyn, Mike wrote:
> > > The longest quiet timeout is now 6s. Extend the driver wait.
> >
> > To what? And why? What does this fix?
> >
>
> The driver wasn't following the our internal specification: 6 seconds.
>
> The patch corrects that issue
> > Add aeth name syndrome decode
>
> Again, why?
>
This fix is to enhance debugging.
The IBTA RC ACK contains an ACK extended transport header.
Part of that header is the syndrome field that qualifies the RC ACK as an ACK,
NAK, or RNR NAK.
Without the patch here is the syndrome decode:
aeth
Ensure that validate_ipv4_net_dev() calls rcu_read_unlock() if
fib_lookup() fails. Detected by sparse. Compile-tested only.
Fixes: "IB/cma: Validate routing of incoming requests" (commit f887f2ac87c2).
Cc: Haggai Eran
Cc: stable
---
drivers/infiniband/core/cma.c | 5 +
1 file changed, 1 ins
On Fri, Nov 20, 2015 at 04:01:18PM +, Marciniszyn, Mike wrote:
> > That sounds like a horrid hack, and this implies that a slower machine will
> > still have this problem...
>
> Greg,
>
> I'm NAK'ing this patch for two reasons:
> 1. Code underneath the CONFIG option is only used during rework
On 11/20/2015 12:13 PM, Greg KH wrote:
>>> I think it's too late for that, especially given that I have 34+ patches
>>> for the staging rdma drivers already in my tree in linux-next.
>>
>> For hfi1 rename detection should work, for the other three, patches to
>> removed files are easily resolved a
On Fri, Nov 20, 2015 at 11:58:18AM -0500, Doug Ledford wrote:
> On 11/20/2015 11:39 AM, Greg KH wrote:
> > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> >> To that end, I've opened my 4.4-rc branch and deleted the three
> >> deprecated drivers from staging and moved hfi1 to the rd
Hi Doug,
before the drivers stops overloading writev vs write (hfi1_file_ops)
it MUST not be moved to the main tree.
--
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 http://vger.kernel.org/majordo
On Fri, Nov 20, 2015 at 04:43:56PM +, Marciniszyn, Mike wrote:
> > >
> > > Is the inprocess branch available?
> >
> > I do not understand what you mean here :(
>
> Does it fail to apply to staging-next or staging-testing or something else?
As both trees are now the same, it fails to apply to
On 11/20/2015 11:39 AM, Greg KH wrote:
> On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
>> To that end, I've opened my 4.4-rc branch and deleted the three
>> deprecated drivers from staging and moved hfi1 to the rdma tree. I've
>> sent an email to Linus to see if he's ok taking thos
On 11/20/2015 02:16 AM, Christoph Hellwig wrote:
> On Wed, Nov 18, 2015 at 10:20:14AM -0800, Bart Van Assche wrote:
>> Are you perhaps referring to the sysfs CPU mask that allows to control
>> workqueue affinity ?
>
> I think he is referring to the defintion of WQ_UNBOUND:
>
>WQ_UNBOUND
>
>
> >
> > Is the inprocess branch available?
>
> I do not understand what you mean here :(
Does it fail to apply to staging-next or staging-testing or something else?
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
do_div is the wrong way to divide a sector_t, as it is less
efficient when sector_t is 32-bit wide. With the upcoming
do_div optimizations, the kernel starts warning about this:
drivers/infiniband/ulp/iser/iser_verbs.c:1296:4: note: in expansion of macro
'do_div'
include/asm-generic/div64.h:224:2
On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> To that end, I've opened my 4.4-rc branch and deleted the three
> deprecated drivers from staging and moved hfi1 to the rdma tree. I've
> sent an email to Linus to see if he's ok taking those changes, and if
> so, I'll get them submit
On Fri, Nov 20, 2015 at 03:23:55PM +, Marciniszyn, Mike wrote:
> > > drivers/staging/rdma/hfi1/sdma.c | 12 ++--
> > > 1 files changed, 10 insertions(+), 2 deletions(-)
> >
> > Doesn't apply to my tree :(
>
> Ok.
>
> Is the inprocess branch available?
I do not understand what you
> That sounds like a horrid hack, and this implies that a slower machine will
> still have this problem...
Greg,
I'm NAK'ing this patch for two reasons:
1. Code underneath the CONFIG option is only used during rework
2. It is a hack as you have noted
We are going to take this up internally to ge
> > Are you saying dev_dbg() is a better choice?
>
> Yes, why would a user ever want to see that above line? What can they do
> with it?
Will do.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> On 11/19/2015 05:23 PM, Dennis Dalessandro wrote:
> > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote:
> >> The major todo for the hfi1 driver in staging is getting rid of the
> >> verbs code duplication between ipat
>
> To that end, I've opened my 4.4-rc branch and deleted the three deprecated
> drivers from staging and moved hfi1 to the rdma tree. I've sent an email to
> Linus to see if he's ok taking those changes, and if so, I'll get them
> submitted
> and then open up my for-4.5 branch early to be able
On 11/19/2015 05:23 PM, Dennis Dalessandro wrote:
> On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote:
>> 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 g
> > The longest quiet timeout is now 6s. Extend the driver wait.
>
> To what? And why? What does this fix?
>
The driver wasn't following the our internal specification: 6 seconds.
The patch corrects that issue.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> > drivers/staging/rdma/hfi1/sdma.c | 12 ++--
> > 1 files changed, 10 insertions(+), 2 deletions(-)
>
> Doesn't apply to my tree :(
Ok.
Is the inprocess branch available?
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to major
On Fri, Nov 20, 2015 at 03:14:19PM +, Marciniszyn, Mike wrote:
> > > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n",
> > > + fname, pcie_ctrl);
> >
> > Why spam the log with this all the time? Shouldn't this be a debug line
> > instead?
>
> The current implement
> > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n",
> > + fname, pcie_ctrl);
>
> Why spam the log with this all the time? Shouldn't this be a debug line
> instead?
The current implementation is layered on dev_info().
Are you saying dev_dbg() is a better choice?
> > From: Dean Luick
> >
> > Correctly reduce the number of VLs when limited by the number of SDMA
> > engines.
>
> why? What does this "solve"?
The hardware has multiple egress mechanisms, SDMA and pio, and multiples of
those.
These mechanisms are chosen using the VL (8)
The fix corrects a
> > Clean up comments
>
> In what way?
>
The patch deleted numbering and terms internal to intel.
The information on the actual bugs is not deleted.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordom
> > Add CNP opcode decode
>
> Why?
Prior to this patch the trace appeared like:
-0 [001] d.h. 94062.578932: input_ibhdr: [:05:00.0] vl 0 lver 0
sl 0 lnh 2,LRH_BTH dlid 0003 len 6 slid 0001 op 0x80,0x80 se 0 m 0 pad 0 tver 0
pkey 0x8001 f 0 b 0 qpn 0x001234 a 0 psn 0x
Note the "o
At the beginning when hfi1 was put into staging, then it was easy enough
for Greg to take those patches but now it feels awkward. Probably
Doug and the linux-rdma@vger.kernel.org people should start maintaining
the drivers/staging/rdma directory. Like merge Greg's tree and pull in
whatever checkp
On Wed, Nov 18, 2015 at 08:32:59AM -0800, Bart Van Assche wrote:
> As you know events like a cable pull can cause some of the RDMA work
> requests to succeed and others to fail. It is essential that all RDMA work
> requests related to the same SCSI command have finished before the buffers
> thes
On Wed, Nov 18, 2015 at 10:20:14AM -0800, Bart Van Assche wrote:
> Are you perhaps referring to the sysfs CPU mask that allows to control
> workqueue affinity ?
I think he is referring to the defintion of WQ_UNBOUND:
WQ_UNBOUND
Work items queued to an unbound wq are served by the spec
Looks good,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
On Fri, Nov 20, 2015 at 3:06 AM, Greg Kroah-Hartman
wrote:
> On Thu, Nov 12, 2015 at 07:58:54AM +0200, Or Gerlitz wrote:
>> On Sat, Oct 31, 2015 at 12:41 AM, wrote:
>> So this is an wholy orthogonal mechanism for memory registrations or
>> de-registrations vs what's supported by the upstream RD
38 matches
Mail list logo