On 1/29/15, 1:38 PM, Mike Christie wrote:
On 1/29/15, 7:02 AM, Bart Van Assche wrote:
Delay REQ_PREEMPT requests submitted against a blocked device
until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
to the SCSI mid-layer. This avoids that a rescan shortly after a
cable pull sporad
On Thu, Jan 29, 2015 at 1:59 PM, Yann Droneaud wrote:
>> Roland: I agree with Yann, these patches need to go in, or the ODP
>> patches reverted.
> Reverting all On Demand Paging patches seems overkill:
> if something as to be reverted it should be commit 5a77abf9a97a
> ("IB/core: Add support for
Le jeudi 29 janvier 2015 à 19:43 +0100, Yann Droneaud a écrit :
> Le jeudi 29 janvier 2015 à 11:28 -0700, Jason Gunthorpe a écrit :
> > On Thu, Jan 29, 2015 at 06:59:58PM +0100, Yann Droneaud wrote:
> > > - resp.odp_caps.general_caps = attr.odp_caps.general_caps;
> > > - resp.odp_c
Hi,
Le jeudi 29 janvier 2015 à 11:36 -0700, Jason Gunthorpe a écrit :
> On Thu, Jan 29, 2015 at 06:59:59PM +0100, Yann Droneaud wrote:
> > This patch ensures the extended QUERY_DEVICE uverbs request's
> > comp_mask has only known and supported bits (currently none).
>
> I think I would be happy t
Hi,
Le jeudi 29 janvier 2015 à 11:38 -0700, Jason Gunthorpe a écrit :
> On Thu, Jan 29, 2015 at 07:00:00PM +0100, Yann Droneaud wrote:
> > As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
> > during OFA International Developer Workshop 2013, the request's
> > comp_mask should d
Hi,
Le jeudi 29 janvier 2015 à 11:28 -0700, Jason Gunthorpe a écrit :
> On Thu, Jan 29, 2015 at 06:59:58PM +0100, Yann Droneaud wrote:
> > As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
> > during OFA International Developer Workshop 2013, the request's
> > comp_mask should d
On Thu, Jan 29, 2015 at 10:14:29PM +0100, Yann Droneaud wrote:
> > > Unfortunately, the userspace don't get the size of the returned data:
> > > it's only a single "write()" syscall after all.
> >
> > A write syscall that behaves nothing like write() actually should, so
> > I don't see why we can'
Le jeudi 29 janvier 2015 à 12:14 -0700, Jason Gunthorpe a écrit :
> On Thu, Jan 29, 2015 at 07:35:14PM +0100, Yann Droneaud wrote:
>
> > Unfortunately, the userspace don't get the size of the returned data:
> > it's only a single "write()" syscall after all.
>
> A write syscall that behaves nothi
On Thu, Jan 29, 2015 at 09:50:38PM +0100, Yann Droneaud wrote:
> Anyway, I recognize that uverb way of abusing write() syscall is
> borderline (at best) regarding other Linux subsystems and Unix paradigm
> in general. But it's not enough to screw it more.
Then we must return the correct output
Hi,
Le jeudi 29 janvier 2015 à 12:18 -0700, Jason Gunthorpe a écrit :
> On Thu, Jan 29, 2015 at 07:43:29PM +0100, Yann Droneaud wrote:
>
> > The write() syscall must return the size buffer passed to it, or
> > less, but in such case it would ask for trouble as userspace would
> > be allowed to wr
On Thu, Jan 29, 2015 at 11:23:22AM -0800, Roland Dreier wrote:
> On Thu, Jan 29, 2015 at 7:34 AM, Doug Ledford wrote:
> >
> > > So lets close the 3.19 saga, again, either revert your eight patches
> >
> > I would support that option.
>
> I think at this point we have to do the revert, and get it
On Thu, Jan 29, 2015 at 11:36:48AM -0700, Jason Gunthorpe wrote:
> Also, the _ex varients were supposed to be supersets of the base call,
> so it is wrong that query_device_ex doesn't return all the same data
> as query_device, layed out so that the original response structure is
> a prefix of the
On 1/29/15, 7:02 AM, Bart Van Assche wrote:
Delay REQ_PREEMPT requests submitted against a blocked device
until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
to the SCSI mid-layer. This avoids that a rescan shortly after a
cable pull sporadically triggers the following kernel oops:
On Thu, 2015-01-29 at 11:23 -0800, Roland Dreier wrote:
> On Thu, Jan 29, 2015 at 7:34 AM, Doug Ledford wrote:
> >
> > > So lets close the 3.19 saga, again, either revert your eight patches
> >
> > I would support that option.
>
> I think at this point we have to do the revert, and get it right f
On Thu, Jan 29, 2015 at 7:34 AM, Doug Ledford wrote:
>
> > So lets close the 3.19 saga, again, either revert your eight patches
>
> I would support that option.
I think at this point we have to do the revert, and get it right for
3.20. There's just too much noise floating around and I can't tell
On Thu, Jan 29, 2015 at 07:43:29PM +0100, Yann Droneaud wrote:
> The write() syscall must return the size buffer passed to it, or
> less, but in such case it would ask for trouble as userspace would
> be allowed to write() the remaining bytes. Returning a size bigger
> than the one passed to writ
On Thu, Jan 29, 2015 at 07:35:14PM +0100, Yann Droneaud wrote:
> Unfortunately, the userspace don't get the size of the returned data:
> it's only a single "write()" syscall after all.
A write syscall that behaves nothing like write() actually should, so
I don't see why we can't have
resp_len =
Hi,
Le jeudi 29 janvier 2015 à 11:28 -0700, Jason Gunthorpe a écrit :
> On Thu, Jan 29, 2015 at 06:59:58PM +0100, Yann Droneaud wrote:
> > As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
> > during OFA International Developer Workshop 2013, the request's
> > comp_mask should d
On Thu, Jan 29, 2015 at 07:00:01PM +0100, Yann Droneaud wrote:
> As only the requested fields are set and copied to userspace,
> there's no need to clear the content of the response structure
> beforehand.
Agreed.
Reviewed-By: Jason Gunthorpe
Jason
--
To unsubscribe from this list: send the lin
On Thu, Jan 29, 2015 at 07:00:00PM +0100, Yann Droneaud wrote:
> As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
> during OFA International Developer Workshop 2013, the request's
> comp_mask should describe the request data: it's describe the
> availability of extended fields i
On Thu, Jan 29, 2015 at 06:59:59PM +0100, Yann Droneaud wrote:
> This patch ensures the extended QUERY_DEVICE uverbs request's
> comp_mask has only known and supported bits (currently none).
I think I would be happy to see the input comp_mask removed
entirely. I can't see a possible use for input
Hi,
Le jeudi 29 janvier 2015 à 11:09 -0700, Jason Gunthorpe a écrit :
> On Wed, Jan 28, 2015 at 02:19:11PM +0100, Yann Droneaud wrote:
>
> > But the same program (either binary or source code) might fail on
> > newer kernel where some bits in comp_mask gain a meaning not supported
> > by the prog
On Thu, Jan 29, 2015 at 06:59:58PM +0100, Yann Droneaud wrote:
> As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
> during OFA International Developer Workshop 2013, the request's
> comp_mask should describe the request data: it's describe the
> availability of extended fields i
On Wed, Jan 28, 2015 at 02:19:11PM +0100, Yann Droneaud wrote:
> But the same program (either binary or source code) might fail on
> newer kernel where some bits in comp_mask gain a meaning not supported
> by the program.
To clarify some of this:
The intention of the comp_mask scheme was to defi
As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
during OFA International Developer Workshop 2013, the request's
comp_mask should describe the request data: it's describe the
availability of extended fields in the request.
Conversely, the response's comp_mask should describe the
As only the requested fields are set and copied to userspace,
there's no need to clear the content of the response structure
beforehand.
Link: http://mid.gmane.org/cover.1422553023.git.ydrone...@opteya.com
Cc: Sagi Grimberg
Cc: Shachar Raindel
Cc: Eli Cohen
Cc: Haggai Eran
Signed-off-by: Yann
As specified in "Extending Verbs API" presentation [1] by Tzahi Oved
during OFA International Developer Workshop 2013, the request's
comp_mask should describe the request data: it's describe the
availability of extended fields in the request.
Conversely, the response's comp_mask should describe the
While ib_copy_to_udata() should check for the available output
space as already proposed in some other patches [1][2][3], the
changes brought by commit 5a77abf9a97a ("IB/core: Add support for
extended query device caps") are silently truncating the data to
be written to userspace if the output buff
This patch ensures the extended QUERY_DEVICE uverbs request's
comp_mask has only known and supported bits (currently none).
If userspace set unknown features bits, -EINVAL will be returned,
ensuring current programs are not allowed to set random feature
bits: such bits could enable new extended fe
Hi,
Le mercredi 28 janvier 2015 à 17:40 +0200, Haggai Eran a écrit :
> On 28/01/2015 15:19, Yann Droneaud wrote:
> > Le mardi 27 janvier 2015 à 08:50 +0200, Haggai Eran a écrit :
> >> On 26/01/2015 13:17, Yann Droneaud wrote:
> >>> ...
> >>> Le dimanche 25 janvier 2015 à 17:23 +0200, Haggai Eran a
Hi,
Following discussions in thread "[PATCH v3 06/17] IB/core: Add support
for extended query device caps" [1] and further comments on previous
patch in "[PATCH 3/4] IB/uverbs: ex_query_device: check request's
comp_mask" thread [2], I'm proposing an updated patchset to implement
a slighly differen
On Thu, Jan 29, 2015 at 11:14:30AM +0200, Or Gerlitz wrote:
> From: Majd Dibbiny
>
> The rq/sq->psn is 24 bits as defined in the IB spec, therefore ULPs and User
> space applications shouldn't use the 8 most significant bits in the 32 bits
> variables to avoid overflow in modify_qp.
>
> Fixed th
On Thu, Jan 29, 2015 at 11:14:29AM +0200, Or Gerlitz wrote:
> From: Majd Dibbiny
>
> When ib_register_mad_agent fails, it returns a pointer with error which is not
> NULL, therefore when calling ib_unregister_mad_agent we need to check that the
> passed mad_agent is valid and not erroneous.
This
On Thu, 2015-01-29 at 14:51 +0200, Or Gerlitz wrote:
> On 1/27/2015 7:02 PM, Doug Ledford wrote:
> > [...]
> > I haven't heard an argument from you yet that I believe beats the points
> > I've made above. So I believe a solution that does not revert back to
> > having two separate code paths to be
On 1/29/2015 3:02 PM, Bart Van Assche wrote:
Delay REQ_PREEMPT requests submitted against a blocked device
until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
to the SCSI mid-layer. This avoids that a rescan shortly after a
cable pull sporadically triggers the following kernel oops:
Delay REQ_PREEMPT requests submitted against a blocked device
until the device is unblocked by returning SCSI_MLQUEUE_HOST_BUSY
to the SCSI mid-layer. This avoids that a rescan shortly after a
cable pull sporadically triggers the following kernel oops:
BUG: unable to handle kernel paging request a
On 1/27/2015 7:02 PM, Doug Ledford wrote:
[...]
I haven't heard an argument from you yet that I believe beats the points
I've made above. So I believe a solution that does not revert back to
having two separate code paths to be maintained is preferable to your patch.
Doug,
It's not going to w
On Mon, Dec 15, 2014 at 06:14:31PM +0200, Or Gerlitz wrote:
> >>
> >> NO, as Matan wrote you "except for Or's comments" - we do want to dump
> > Sure, was not ignoring this one, it was just a warn :)
> >> what is supported by both the device (firmware) and the driver, and
> >> not more. A subset of
From: Ilya Nelkenbaum
When marsheling a user path to the kernel struct ib_sa_path, need
to zero smac, dmac and set the vlan id to the "no vlan" value.
This is to ensure that Ethernet attributes are not used with
InfiniBand QPs.
Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm s
Hi Roland,
This is a batch with IB core fixes, please apply for 3.20
The patch that deals with PSN touches the HW drivers b/c we added
the qp attributes provided by the ULP as a param to the
ib_modify_qp_is_ok() IB core helper.
Or.
Ilya Nelkenbaum (1):
IB/core: When marshaling ucma path fro
From: Majd Dibbiny
When ib_register_mad_agent fails, it returns a pointer with error which is not
NULL, therefore when calling ib_unregister_mad_agent we need to check that the
passed mad_agent is valid and not erroneous.
Signed-off-by: Majd Dibbiny
Signed-off-by: Or Gerlitz
---
drivers/infin
From: Majd Dibbiny
The rq/sq->psn is 24 bits as defined in the IB spec, therefore ULPs and User
space applications shouldn't use the 8 most significant bits in the 32 bits
variables to avoid overflow in modify_qp.
Fixed the PSN usage for kernel ULPs and masked out the 8 most significant bits
for
From: Moshe Lazer
The deadlock occurs on __uverbs_modify_qp, we take a lock (idr_read_qp)
and in case of failure in ib_resolve_eth_l2_attrs we don't release
it (put_qp_read). Fix that.
Issue: 355606
Fixes: ed4c54e5b4ba ("IB/core: Resolve Ethernet L2 addresses when modifying QP")
Signed-off-by: M
From: Moshe Lazer
The deadlock occurs on __uverbs_modify_qp, we take a lock (idr_read_qp)
and in case of failure in ib_resolve_eth_l2_attrs we don't release
it (put_qp_read). Fix that.
Issue: 355606
Fixes: ed4c54e5b4ba ("IB/core: Resolve Ethernet L2 addresses when modifying QP")
Signed-off-by: M
From: Majd Dibbiny
The rq/sq->psn is 24 bits as defined in the IB spec, therefore ULPs and User
space applications shouldn't use the 8 most significant bits in the 32 bits
variables to avoid overflow in modify_qp.
Fixed the PSN usage for kernel ULPs and masked out the 8 most significant bits
for
Sending V1 as the wrong instance was sent for patch #2 (Gerrit hardows)
Hi Roland,
This is a batch with IB core fixes, please apply for 3.20
The patch that deals with PSN touches the HW drivers b/c we added the
qp attributes provided by the ULP as a param to the ib_modify_qp_is_ok()
IB core he
From: Ilya Nelkenbaum
When marsheling a user path to the kernel struct ib_sa_path, need
to zero smac, dmac and set the vlan id to the "no vlan" value.
This is to ensure that Ethernet attributes are not used with
InfiniBand QPs.
Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm s
From: Majd Dibbiny
When ib_register_mad_agent fails, it returns a pointer with error which is not
NULL, therefore when calling ib_unregister_mad_agent we need to check that the
passed mad_agent is valid and not erroneous.
Signed-off-by: Majd Dibbiny
Signed-off-by: Or Gerlitz
---
drivers/infin
From: Majd Dibbiny
1. Before the entries alignment, we need to check that the entries doesn't
exceed the device's max cqe.
2. After the alignment, we need to make sure that the aligned number doesn't
exceed the max cqes+1. The additional cqe is used to denote that the resizing
operation has comp
From: Jack Morgenstein
If a GUID is not found, the 64-bit GUID printed in the message log
warning should converted to host-endian order for printing.
Found by Doug Ledford and Hal Rosenstock. Fix suggested by Hal.
Signed-off-by: Hal Rosenstock
Signed-off-by: Jack Morgenstein
Signed-off-by: O
Hi Roland,
This is small batch of mlx4 IB driver fixes, please apply for for 3.20
Note that there's another mlx4 IB driver fix I sent for 3.19 and you
didn't pick yet, "IB/mlx4: Fix wrong usage of IPv4 protocol for multicast
attach/detach" https://patchwork.kernel.org/patch/5507181 -- add it to
From: Majd Dibbiny
In case handle_eth_ud_smac_index fails, we need to free the allocated resources.
Fixes: 2f5bb473 ('mlx4: Add ref counting to port MAC table for RoCE')
Signed-off-by: Majd Dibbiny
Signed-off-by: Or Gerlitz
---
drivers/infiniband/hw/mlx4/qp.c |6 --
1 files changed, 4
52 matches
Mail list logo
