Re: [PATCH v2] IB/rxe: don't crash, if allocation of crc algorithm failed

[Moni Shoua]

On Tue, Oct 31, 2017 at 12:16 PM, Thomas Bogendoerfer
<tbogendoer...@suse.de> wrote:
> Following crash happens, if crc algorithm couldn't be allocated:
>
> [ 1087.989072] rdma_rxe: loaded
> [ 1097.855397] PCLMULQDQ-NI instructions are not detected.
> [ 1097.901220] rdma_rxe: failed to allocate crc algorithmi err:-2
> [ 1097.901248] BUG: unable to handle kernel
> [ 1097.901249] NULL pointer dereference
> [ 1097.901250]  at 0046
> [...]
>
> Reason is that rxe->tfm is assigned the error return, which will then
> be used for crypto_free_shash() in rxe_cleanup. Fix by using a
> temporary variable and assigning it rxe->tfm after allocation succeeded.
>
> Fixes: cee2688e3cd6 ("IB/rxe: Offload CRC calculation when possible")
> Signed-off-by: Thomas Bogendoerfer <tbogendoer...@suse.de>
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index ff77f4f66970..d03002b9d84d 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -1192,6 +1192,7 @@ int rxe_register_device(struct rxe_dev *rxe)
> int err;
> int i;
> struct ib_device *dev = >ib_dev;
> +   struct crypto_shash *tfm;
>
> strlcpy(dev->name, "rxe%d", IB_DEVICE_NAME_MAX);
> strlcpy(dev->node_desc, "rxe", sizeof(dev->node_desc));
> @@ -1289,12 +1290,13 @@ int rxe_register_device(struct rxe_dev *rxe)
> dev->get_hw_stats = rxe_ib_get_hw_stats;
> dev->alloc_hw_stats = rxe_ib_alloc_hw_stats;
>
> -   rxe->tfm = crypto_alloc_shash("crc32", 0, 0);
> -   if (IS_ERR(rxe->tfm)) {
> +   tfm = crypto_alloc_shash("crc32", 0, 0);
> +   if (IS_ERR(tfm)) {
> pr_err("failed to allocate crc algorithm err:%ld\n",
> -  PTR_ERR(rxe->tfm));
> -   return PTR_ERR(rxe->tfm);
> +  PTR_ERR(tfm));
> +   return PTR_ERR(tfm);
> }
> +   rxe->tfm = tfm;
>
> err = ib_register_device(dev, NULL);
> if (err) {
> --
> 2.12.3
>
> --
Thanks

Acked-by: Moni Shoua <mo...@mellanox.com>

Re: [PATCH v2] IB/rxe: don't crash, if allocation of crc algorithm failed

[Moni Shoua]

On Tue, Oct 31, 2017 at 12:16 PM, Thomas Bogendoerfer
 wrote:
> Following crash happens, if crc algorithm couldn't be allocated:
>
> [ 1087.989072] rdma_rxe: loaded
> [ 1097.855397] PCLMULQDQ-NI instructions are not detected.
> [ 1097.901220] rdma_rxe: failed to allocate crc algorithmi err:-2
> [ 1097.901248] BUG: unable to handle kernel
> [ 1097.901249] NULL pointer dereference
> [ 1097.901250]  at 0046
> [...]
>
> Reason is that rxe->tfm is assigned the error return, which will then
> be used for crypto_free_shash() in rxe_cleanup. Fix by using a
> temporary variable and assigning it rxe->tfm after allocation succeeded.
>
> Fixes: cee2688e3cd6 ("IB/rxe: Offload CRC calculation when possible")
> Signed-off-by: Thomas Bogendoerfer 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index ff77f4f66970..d03002b9d84d 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -1192,6 +1192,7 @@ int rxe_register_device(struct rxe_dev *rxe)
> int err;
> int i;
> struct ib_device *dev = >ib_dev;
> +   struct crypto_shash *tfm;
>
> strlcpy(dev->name, "rxe%d", IB_DEVICE_NAME_MAX);
> strlcpy(dev->node_desc, "rxe", sizeof(dev->node_desc));
> @@ -1289,12 +1290,13 @@ int rxe_register_device(struct rxe_dev *rxe)
> dev->get_hw_stats = rxe_ib_get_hw_stats;
> dev->alloc_hw_stats = rxe_ib_alloc_hw_stats;
>
> -   rxe->tfm = crypto_alloc_shash("crc32", 0, 0);
> -   if (IS_ERR(rxe->tfm)) {
> +   tfm = crypto_alloc_shash("crc32", 0, 0);
> +   if (IS_ERR(tfm)) {
> pr_err("failed to allocate crc algorithm err:%ld\n",
> -  PTR_ERR(rxe->tfm));
> -   return PTR_ERR(rxe->tfm);
> +  PTR_ERR(tfm));
> +   return PTR_ERR(tfm);
> }
> +   rxe->tfm = tfm;
>
> err = ib_register_device(dev, NULL);
> if (err) {
> --
> 2.12.3
>
> --
Thanks

Acked-by: Moni Shoua 

Re: [PATCH 2/2] IB/rxe: don't crash, if allocation of crc algorithm failed

[Moni Shoua]

On Fri, Oct 27, 2017 at 6:59 PM, Thomas Bogendoerfer
 wrote:
> Following crash happens, if crc algorithm couldn't be allocated:
>
> [ 1087.989072] rdma_rxe: loaded
> [ 1097.855397] PCLMULQDQ-NI instructions are not detected.
> [ 1097.901220] rdma_rxe: failed to allocate crc algorithmi err:-2
> [ 1097.901248] BUG: unable to handle kernel
> [ 1097.901249] NULL pointer dereference
> [ 1097.901250]  at 0046
> [...]
>
> Reason is that rxe->tfm is assigned the error return, which will then
> be used for crypto_free_shash() in rxe_cleanup. Fix by using a
> temporay variable and assigning it rxe->tfm after allocation succeeded.
>
> Signed-off-by: Thomas Bogendoerfer 
Fix looks good only a Fixes line is missing from the commit message. Please add.

Re: [PATCH 2/2] IB/rxe: don't crash, if allocation of crc algorithm failed

[Moni Shoua]

On Fri, Oct 27, 2017 at 6:59 PM, Thomas Bogendoerfer
 wrote:
> Following crash happens, if crc algorithm couldn't be allocated:
>
> [ 1087.989072] rdma_rxe: loaded
> [ 1097.855397] PCLMULQDQ-NI instructions are not detected.
> [ 1097.901220] rdma_rxe: failed to allocate crc algorithmi err:-2
> [ 1097.901248] BUG: unable to handle kernel
> [ 1097.901249] NULL pointer dereference
> [ 1097.901250]  at 0046
> [...]
>
> Reason is that rxe->tfm is assigned the error return, which will then
> be used for crypto_free_shash() in rxe_cleanup. Fix by using a
> temporay variable and assigning it rxe->tfm after allocation succeeded.
>
> Signed-off-by: Thomas Bogendoerfer 
Fix looks good only a Fixes line is missing from the commit message. Please add.

Re: [PATCH v06 30/36] uapi rdma/rdma_user_rxe.h: include in.h and in6.h

[Moni Shoua]

>
> I'm not sure this is a good idea, linux/in.h should not be included in
> userspace users of this file, 'sockaddr_in' needs to come from glibc's
> 'netinet/in.h' instead..
>
> Jason
Is it wrong to include include/uapi/linux/in.h from userspace?

Re: [PATCH v06 30/36] uapi rdma/rdma_user_rxe.h: include in.h and in6.h

[Moni Shoua]

>
> I'm not sure this is a good idea, linux/in.h should not be included in
> userspace users of this file, 'sockaddr_in' needs to come from glibc's
> 'netinet/in.h' instead..
>
> Jason
Is it wrong to include include/uapi/linux/in.h from userspace?

Re: [PATCH] infiniband: avoid overflow warning

[Moni Shoua]

On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann  wrote:
> A sockaddr_in structure on the stack getting passed into rdma_ip2gid
> triggers this warning, since we memcpy into a larger sockaddr_in6
> structure:
>
> In function 'memcpy',
> inlined from 'rdma_ip2gid' at include/rdma/ib_addr.h:175:3,
> inlined from 'addr_event.isra.4.constprop' at 
> drivers/infiniband/core/roce_gid_mgmt.c:693:2,
> inlined from 'inetaddr_event' at 
> drivers/infiniband/core/roce_gid_mgmt.c:716:9:
> include/linux/string.h:305:4: error: call to '__read_overflow2' declared with 
> attribute error: detected read beyond size of object passed as 2nd parameter
>
> The warning seems appropriate here, but the code is also clearly
> correct, so we really just want to shut up this instance of the
> output.
>
> The best way I found so far is to avoid the memcpy() call and instead
> replace it with a struct assignment.
>
> Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified 
> string.h functions")
> Cc: Daniel Micay 
> Cc: Kees Cook 
> Signed-off-by: Arnd Bergmann 
> ---
>  include/rdma/ib_addr.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
> index 7aca12188ef3..ec5008cf5d51 100644
> --- a/include/rdma/ib_addr.h
> +++ b/include/rdma/ib_addr.h
> @@ -172,7 +172,8 @@ static inline int rdma_ip2gid(struct sockaddr *addr, 
> union ib_gid *gid)
>(struct in6_addr *)gid);
> break;
> case AF_INET6:
> -   memcpy(gid->raw, &((struct sockaddr_in6 *)addr)->sin6_addr, 
> 16);
> +   *(struct in6_addr *)>raw =
> +   ((struct sockaddr_in6 *)addr)->sin6_addr;
> break;
> default:
> return -EINVAL;
what happens if you replace 16 with sizeof(struct in6_addr)?

Re: [PATCH] infiniband: avoid overflow warning

[Moni Shoua]

On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann  wrote:
> A sockaddr_in structure on the stack getting passed into rdma_ip2gid
> triggers this warning, since we memcpy into a larger sockaddr_in6
> structure:
>
> In function 'memcpy',
> inlined from 'rdma_ip2gid' at include/rdma/ib_addr.h:175:3,
> inlined from 'addr_event.isra.4.constprop' at 
> drivers/infiniband/core/roce_gid_mgmt.c:693:2,
> inlined from 'inetaddr_event' at 
> drivers/infiniband/core/roce_gid_mgmt.c:716:9:
> include/linux/string.h:305:4: error: call to '__read_overflow2' declared with 
> attribute error: detected read beyond size of object passed as 2nd parameter
>
> The warning seems appropriate here, but the code is also clearly
> correct, so we really just want to shut up this instance of the
> output.
>
> The best way I found so far is to avoid the memcpy() call and instead
> replace it with a struct assignment.
>
> Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified 
> string.h functions")
> Cc: Daniel Micay 
> Cc: Kees Cook 
> Signed-off-by: Arnd Bergmann 
> ---
>  include/rdma/ib_addr.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
> index 7aca12188ef3..ec5008cf5d51 100644
> --- a/include/rdma/ib_addr.h
> +++ b/include/rdma/ib_addr.h
> @@ -172,7 +172,8 @@ static inline int rdma_ip2gid(struct sockaddr *addr, 
> union ib_gid *gid)
>(struct in6_addr *)gid);
> break;
> case AF_INET6:
> -   memcpy(gid->raw, &((struct sockaddr_in6 *)addr)->sin6_addr, 
> 16);
> +   *(struct in6_addr *)>raw =
> +   ((struct sockaddr_in6 *)addr)->sin6_addr;
> break;
> default:
> return -EINVAL;
what happens if you replace 16 with sizeof(struct in6_addr)?

Re: [PATCH] drivers/rxe: improve rxe loopback

[Moni Shoua]

>> Have you considered using ip_route_output_key() for IPv4 or
>> ip6_route_output() for IPv6 to decide if  this is a loopback?
>> For reference you can check the flow starting at  rdma_resolve_ip()
>>
>
> Hi Moni,
>
> Yes, I had looked into it, but I haven't seen how I can find
> out if the destination IP belongs to the same RXE.
> The loopback flag will give us the "same host"
> confirmation, but not the same rxe instance, right?
>
> Any ideas would be welcomed.
>
> Thanks,
> Marcel
>
Hi Marcel

You are right about that. IFF_LOOPBACK tells you that the source and
destination addresses are on the same host but not necessarily on the
same RXE device.

As Leon mentioned, calling addrX_same_rxe() for each packet seems to
heavy , especially when the use case that justifies it (instead of
calling memcmp() on src and dst) is rare. Do you agree?
If so I think that marking a connection as loopback once is the right approach
For RC/UC - when modified to RTR
For UD - this is harder. IsLoopback() is function of the WQE (or at
least the QP and AH together( but not the QP. I think you can add an
improvement that will work for the majority of cases. This is a sketch
of what I have in mind. Let me know what you think please

1. Add bool last_used_qp to AH structure
2. Add bool is_loopback_with_last_qp to AH structure
3. Set values to AH.last_used_qp and AH.is_loopback_with_last_qp in
post_send() modify_ah(),...
4. Mark WQE as loopback depending on the above

Re: [PATCH] drivers/rxe: improve rxe loopback

[Moni Shoua]

>> Have you considered using ip_route_output_key() for IPv4 or
>> ip6_route_output() for IPv6 to decide if  this is a loopback?
>> For reference you can check the flow starting at  rdma_resolve_ip()
>>
>
> Hi Moni,
>
> Yes, I had looked into it, but I haven't seen how I can find
> out if the destination IP belongs to the same RXE.
> The loopback flag will give us the "same host"
> confirmation, but not the same rxe instance, right?
>
> Any ideas would be welcomed.
>
> Thanks,
> Marcel
>
Hi Marcel

You are right about that. IFF_LOOPBACK tells you that the source and
destination addresses are on the same host but not necessarily on the
same RXE device.

As Leon mentioned, calling addrX_same_rxe() for each packet seems to
heavy , especially when the use case that justifies it (instead of
calling memcmp() on src and dst) is rare. Do you agree?
If so I think that marking a connection as loopback once is the right approach
For RC/UC - when modified to RTR
For UD - this is harder. IsLoopback() is function of the WQE (or at
least the QP and AH together( but not the QP. I think you can add an
improvement that will work for the majority of cases. This is a sketch
of what I have in mind. Let me know what you think please

1. Add bool last_used_qp to AH structure
2. Add bool is_loopback_with_last_qp to AH structure
3. Set values to AH.last_used_qp and AH.is_loopback_with_last_qp in
post_send() modify_ah(),...
4. Mark WQE as loopback depending on the above

Re: [PATCH] drivers/rxe: improve rxe loopback

[Moni Shoua]

On Wed, Jul 26, 2017 at 10:57 PM, Yuval Shaia  wrote:
> On Wed, Jul 26, 2017 at 05:52:48PM +0300, Marcel Apfelbaum wrote:
>> Currently a packet is marked for loopback only if the source and
>> destination address match. This is not enough when multiple
>> gids are present in rxe's gid table and the traffic is
>> from one gid to another.
>>
>> Fix it by marking the packet for loopback if the destination
>> address appears in rxe's gid table.
>>
>> Signed-off-by: Marcel Apfelbaum 
>
Have you considered using ip_route_output_key() for IPv4 or
ip6_route_output() for IPv6 to decide if  this is a loopback?
For reference you can check the flow starting at  rdma_resolve_ip()

Re: [PATCH] drivers/rxe: improve rxe loopback

[Moni Shoua]

On Wed, Jul 26, 2017 at 10:57 PM, Yuval Shaia  wrote:
> On Wed, Jul 26, 2017 at 05:52:48PM +0300, Marcel Apfelbaum wrote:
>> Currently a packet is marked for loopback only if the source and
>> destination address match. This is not enough when multiple
>> gids are present in rxe's gid table and the traffic is
>> from one gid to another.
>>
>> Fix it by marking the packet for loopback if the destination
>> address appears in rxe's gid table.
>>
>> Signed-off-by: Marcel Apfelbaum 
>
Have you considered using ip_route_output_key() for IPv4 or
ip6_route_output() for IPv6 to decide if  this is a loopback?
For reference you can check the flow starting at  rdma_resolve_ip()

Re: [PATCH V5] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

Acked-by: Moni Shoua <mo...@mellanox.com>

thanks

Re: [PATCH V5] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

Acked-by: Moni Shoua 

thanks

Re: [PATCH V3] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

> I agree.
> So, it is fine to me to remove this line, as you said in the former email:
>
Thanks.
Can you please send a patch like that?

Re: [PATCH V3] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

> I agree.
> So, it is fine to me to remove this line, as you said in the former email:
>
Thanks.
Can you please send a patch like that?

Re: [PATCH V3] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

> -   if (qp->is_user && copy_from_user(p, (__user void *)
> -   (uintptr_t)sge->addr, 
> sge->length))
> +   spin_unlock_irqrestore(>sq.sq_lock, *flags);
> +   err = copy_from_user(p, (__user void *)
> +   (uintptr_t)sge->addr, sge->length);
> +   spin_lock_irqsave(>sq.sq_lock, *flags);
> +   if (qp->is_user && err)
> return -EFAULT;
qp-_is_user is always false in this function (flow starts from
rxe_post_send_kernel) so this line is a dead code
In fact, this patch seems to add a serious bug when it uses
copy_from_user() from a non user pointer.
Do you agree?

Re: [PATCH V3] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

> -   if (qp->is_user && copy_from_user(p, (__user void *)
> -   (uintptr_t)sge->addr, 
> sge->length))
> +   spin_unlock_irqrestore(>sq.sq_lock, *flags);
> +   err = copy_from_user(p, (__user void *)
> +   (uintptr_t)sge->addr, sge->length);
> +   spin_lock_irqsave(>sq.sq_lock, *flags);
> +   if (qp->is_user && err)
> return -EFAULT;
qp-_is_user is always false in this function (flow starts from
rxe_post_send_kernel) so this line is a dead code
In fact, this patch seems to add a serious bug when it uses
copy_from_user() from a non user pointer.
Do you agree?

Re: [PATCH V3] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

On Thu, Jun 1, 2017 at 11:28 AM, Jia-Ju Bai  wrote:
> The driver may sleep under a spin lock, and the function call path is:
> post_one_send (acquire the lock by spin_lock_irqsave)
>   init_send_wqe
> copy_from_user --> may sleep
>
> To fix it, the lock is released before copy_from_user, and the lock is
> acquired again after this function. The parameter "flags" is used to
> restore and save the irq status.
> Thank Leon for good advice.
>
> This patch corrects the mistakes in V2. (Thank Ram for pointing it out)
>
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c |   13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index 83d709e..5293d15 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -721,11 +721,11 @@ static void init_send_wr(struct rxe_qp *qp, struct 
> rxe_send_wr *wr,
>
>  static int init_send_wqe(struct rxe_qp *qp, struct ib_send_wr *ibwr,
>  unsigned int mask, unsigned int length,
> -struct rxe_send_wqe *wqe)
> +struct rxe_send_wqe *wqe, unsigned long *flags)
>  {
> int num_sge = ibwr->num_sge;
> struct ib_sge *sge;
> -   int i;
> +   int i, err;
> u8 *p;
>
> init_send_wr(qp, >wr, ibwr);
> @@ -740,8 +740,11 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
> ib_send_wr *ibwr,
>
> sge = ibwr->sg_list;
> for (i = 0; i < num_sge; i++, sge++) {
> -   if (qp->is_user && copy_from_user(p, (__user void *)
> -   (uintptr_t)sge->addr, 
> sge->length))
> +   spin_unlock_irqrestore(>sq.sq_lock, *flags);

Before the patch, copy_from_user() was called only if qp->is_user was
true. After the patch it is always called.
Second, I think that  there is no flow that leads to this function
when qp->is user is true so maybe the correct action is to remove this
line completely

if (qp->is_user && copy_from_user(p, (__user void *)

Re: [PATCH V3] rxe: Fix a sleep-in-atomic bug in post_one_send

[Moni Shoua]

On Thu, Jun 1, 2017 at 11:28 AM, Jia-Ju Bai  wrote:
> The driver may sleep under a spin lock, and the function call path is:
> post_one_send (acquire the lock by spin_lock_irqsave)
>   init_send_wqe
> copy_from_user --> may sleep
>
> To fix it, the lock is released before copy_from_user, and the lock is
> acquired again after this function. The parameter "flags" is used to
> restore and save the irq status.
> Thank Leon for good advice.
>
> This patch corrects the mistakes in V2. (Thank Ram for pointing it out)
>
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c |   13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index 83d709e..5293d15 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -721,11 +721,11 @@ static void init_send_wr(struct rxe_qp *qp, struct 
> rxe_send_wr *wr,
>
>  static int init_send_wqe(struct rxe_qp *qp, struct ib_send_wr *ibwr,
>  unsigned int mask, unsigned int length,
> -struct rxe_send_wqe *wqe)
> +struct rxe_send_wqe *wqe, unsigned long *flags)
>  {
> int num_sge = ibwr->num_sge;
> struct ib_sge *sge;
> -   int i;
> +   int i, err;
> u8 *p;
>
> init_send_wr(qp, >wr, ibwr);
> @@ -740,8 +740,11 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
> ib_send_wr *ibwr,
>
> sge = ibwr->sg_list;
> for (i = 0; i < num_sge; i++, sge++) {
> -   if (qp->is_user && copy_from_user(p, (__user void *)
> -   (uintptr_t)sge->addr, 
> sge->length))
> +   spin_unlock_irqrestore(>sq.sq_lock, *flags);

Before the patch, copy_from_user() was called only if qp->is_user was
true. After the patch it is always called.
Second, I think that  there is no flow that leads to this function
when qp->is user is true so maybe the correct action is to remove this
line completely

if (qp->is_user && copy_from_user(p, (__user void *)

Re: [PATCH][V2] IB/rxe: fix typo: "algorithmi" -> "algorithm"

[Moni Shoua]

On Mon, Apr 24, 2017 at 12:26 PM, Colin King  wrote:
> From: Colin Ian King 
>
> trivial fix to typo in pr_err message
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index 486035a85bac..6a4b02470d21 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -1324,7 +1324,7 @@ int rxe_register_device(struct rxe_dev *rxe)
>
> rxe->tfm = crypto_alloc_shash("crc32", 0, 0);
> if (IS_ERR(rxe->tfm)) {
> -   pr_err("failed to allocate crc algorithmi err:%ld",
> +   pr_err("failed to allocate crc algorithm err:%ld",
>PTR_ERR(rxe->tfm));
> return PTR_ERR(rxe->tfm);
> }
> --
> 2.11.0

Thanks (for both patches)

Re: [PATCH][V2] IB/rxe: fix typo: "algorithmi" -> "algorithm"

[Moni Shoua]

On Mon, Apr 24, 2017 at 12:26 PM, Colin King  wrote:
> From: Colin Ian King 
>
> trivial fix to typo in pr_err message
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index 486035a85bac..6a4b02470d21 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -1324,7 +1324,7 @@ int rxe_register_device(struct rxe_dev *rxe)
>
> rxe->tfm = crypto_alloc_shash("crc32", 0, 0);
> if (IS_ERR(rxe->tfm)) {
> -   pr_err("failed to allocate crc algorithmi err:%ld",
> +   pr_err("failed to allocate crc algorithm err:%ld",
>PTR_ERR(rxe->tfm));
> return PTR_ERR(rxe->tfm);
> }
> --
> 2.11.0

Thanks (for both patches)

Re: [PATCH] IB/rxe: Don't clamp residual length to mtu

[Moni Shoua]

On Thu, Apr 6, 2017 at 3:49 PM, Johannes Thumshirn <jthumsh...@suse.de> wrote:
> When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
> header into the qp->resp.resid variable for later use. Later in check_rkey()
> we clamp it to the MTU if the packet is an  RDMA WRITE packet and has a
> residual length bigger than the MTU. Later in write_data_in() we subtract the
> payload of the packet from the residual length. If the packet happens to have 
> a
> payload of exactly the MTU size we end up with a residual length of 0 despite
> the packet not being the last in the conversation. When the next packet in the
> conversation arrives, we don't have any residual length left and thus set the 
> QP
> into an error state.
>
> This broke NVMe over Fabrics functionality over rdma_rxe.ko
>
> The patch was verified using the following test.
>
>  # echo eth0 > /sys/module/rdma_rxe/parameters/add
>  # nvme connect -t rdma -a 192.168.155.101 -s 1023 -n nvmf-test
>  # mkfs.xfs -fK /dev/nvme0n1
>  meta-data=/dev/nvme0n1   isize=256agcount=4, agsize=65536 blks
>   =   sectsz=4096  attr=2, projid32bit=1
>   =   crc=0finobt=0, sparse=0
>  data =   bsize=4096   blocks=262144, imaxpct=25
>   =   sunit=0  swidth=0 blks
>  naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
>  log  =internal log   bsize=4096   blocks=2560, version=2
>   =   sectsz=4096  sunit=1 blks, lazy-count=1
>  realtime =none   extsz=4096   blocks=0, rtextents=0
>  # mount /dev/nvme0n1 /tmp/
>  [  148.923263] XFS (nvme0n1): Mounting V4 Filesystem
>  [  148.961196] XFS (nvme0n1): Ending clean mount
>  # dd if=/dev/urandom of=test.bin bs=1M count=128
>  128+0 records in
>  128+0 records out
>  134217728 bytes (134 MB, 128 MiB) copied, 0.437991 s, 306 MB/s
>  # sha256sum test.bin
>  cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a  test.bin
>  # cp test.bin /tmp/
>  sha256sum /tmp/test.bin
>  cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a  
> /tmp/test.bin
>
> Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
> Cc: Hannes Reinecke <h...@suse.de>
> Cc: Sagi Grimberg <s...@grimberg.me>
> Cc: Max Gurtovoy <m...@mellanox.com>
> ---
>  drivers/infiniband/sw/rxe/rxe_resp.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c 
> b/drivers/infiniband/sw/rxe/rxe_resp.c
> index c9dd385..58764df 100644
> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> @@ -478,8 +478,6 @@ static enum resp_states check_rkey(struct rxe_qp *qp,
> state = RESPST_ERR_LENGTH;
> goto err;
> }
> -
> -       qp->resp.resid = mtu;
> } else {
> if (pktlen != resid) {
> state = RESPST_ERR_LENGTH;
> --
> 2.10.2
>
> --
Thanks Johannes

Acked-by: Moni Shoua <mo...@mellanox.com>

Re: [PATCH] IB/rxe: Don't clamp residual length to mtu

[Moni Shoua]

On Thu, Apr 6, 2017 at 3:49 PM, Johannes Thumshirn  wrote:
> When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
> header into the qp->resp.resid variable for later use. Later in check_rkey()
> we clamp it to the MTU if the packet is an  RDMA WRITE packet and has a
> residual length bigger than the MTU. Later in write_data_in() we subtract the
> payload of the packet from the residual length. If the packet happens to have 
> a
> payload of exactly the MTU size we end up with a residual length of 0 despite
> the packet not being the last in the conversation. When the next packet in the
> conversation arrives, we don't have any residual length left and thus set the 
> QP
> into an error state.
>
> This broke NVMe over Fabrics functionality over rdma_rxe.ko
>
> The patch was verified using the following test.
>
>  # echo eth0 > /sys/module/rdma_rxe/parameters/add
>  # nvme connect -t rdma -a 192.168.155.101 -s 1023 -n nvmf-test
>  # mkfs.xfs -fK /dev/nvme0n1
>  meta-data=/dev/nvme0n1   isize=256agcount=4, agsize=65536 blks
>   =   sectsz=4096  attr=2, projid32bit=1
>   =   crc=0finobt=0, sparse=0
>  data =   bsize=4096   blocks=262144, imaxpct=25
>   =   sunit=0  swidth=0 blks
>  naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
>  log  =internal log   bsize=4096   blocks=2560, version=2
>   =   sectsz=4096  sunit=1 blks, lazy-count=1
>  realtime =none   extsz=4096   blocks=0, rtextents=0
>  # mount /dev/nvme0n1 /tmp/
>  [  148.923263] XFS (nvme0n1): Mounting V4 Filesystem
>  [  148.961196] XFS (nvme0n1): Ending clean mount
>  # dd if=/dev/urandom of=test.bin bs=1M count=128
>  128+0 records in
>  128+0 records out
>  134217728 bytes (134 MB, 128 MiB) copied, 0.437991 s, 306 MB/s
>  # sha256sum test.bin
>  cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a  test.bin
>  # cp test.bin /tmp/
>  sha256sum /tmp/test.bin
>  cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a  
> /tmp/test.bin
>
> Signed-off-by: Johannes Thumshirn 
> Cc: Hannes Reinecke 
> Cc: Sagi Grimberg 
> Cc: Max Gurtovoy 
> ---
>  drivers/infiniband/sw/rxe/rxe_resp.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c 
> b/drivers/infiniband/sw/rxe/rxe_resp.c
> index c9dd385..58764df 100644
> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> @@ -478,8 +478,6 @@ static enum resp_states check_rkey(struct rxe_qp *qp,
> state = RESPST_ERR_LENGTH;
> goto err;
> }
> -
> -   qp->resp.resid = mtu;
> } else {
> if (pktlen != resid) {
> state = RESPST_ERR_LENGTH;
> --
> 2.10.2
>
> --
Thanks Johannes

Acked-by: Moni Shoua 

Re: [PATCH] IB/rxe: fix GFP_KERNEL in spinlock context

[Moni Shoua]

On Fri, Sep 2, 2016 at 11:46 PM, Alexey Khoroshilov
<khoroshi...@ispras.ru> wrote:
> There is skb_clone(skb, GFP_KERNEL) in spinlock context
> in rxe_rcv_mcast_pkt().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshi...@ispras.ru>
> ---
>  drivers/infiniband/sw/rxe/rxe_recv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_recv.c 
> b/drivers/infiniband/sw/rxe/rxe_recv.c
> index 3d464c23e08b..144d2f129fcd 100644
> --- a/drivers/infiniband/sw/rxe/rxe_recv.c
> +++ b/drivers/infiniband/sw/rxe/rxe_recv.c
> @@ -312,7 +312,7 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
> sk_buff *skb)
>  * make a copy of the skb to post to the next qp
>  */
> skb_copy = (mce->qp_list.next != >qp_list) ?
> -   skb_clone(skb, GFP_KERNEL) : NULL;
> +   skb_clone(skb, GFP_ATOMIC) : NULL;
>
>     pkt->qp = qp;
> rxe_add_ref(qp);
> --
> 2.7.4
>
Acked-by: Moni Shoua <mo...@mellanox.com>

Re: [PATCH] IB/rxe: fix GFP_KERNEL in spinlock context

[Moni Shoua]

On Fri, Sep 2, 2016 at 11:46 PM, Alexey Khoroshilov
 wrote:
> There is skb_clone(skb, GFP_KERNEL) in spinlock context
> in rxe_rcv_mcast_pkt().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov 
> ---
>  drivers/infiniband/sw/rxe/rxe_recv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_recv.c 
> b/drivers/infiniband/sw/rxe/rxe_recv.c
> index 3d464c23e08b..144d2f129fcd 100644
> --- a/drivers/infiniband/sw/rxe/rxe_recv.c
> +++ b/drivers/infiniband/sw/rxe/rxe_recv.c
> @@ -312,7 +312,7 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
> sk_buff *skb)
>  * make a copy of the skb to post to the next qp
>  */
> skb_copy = (mce->qp_list.next != >qp_list) ?
> -   skb_clone(skb, GFP_KERNEL) : NULL;
> +   skb_clone(skb, GFP_ATOMIC) : NULL;
>
> pkt->qp = qp;
> rxe_add_ref(qp);
> --
> 2.7.4
>
Acked-by: Moni Shoua 

Re: [PATCH v05 61/72] include/uapi/rdma/rdma_user_rxe.h: include in.h and in6.h

[Moni Shoua]

Acked-by: Moni Shoua <mo...@mellanox.com>

On Mon, Aug 22, 2016 at 9:33 PM, Mikko Rapeli <mikko.rap...@iki.fi> wrote:
> Fixes these userspace compilation errors when rdma_user_rxe.h is compiled
> alone:
>
> rdma/rdma_user_rxe.h:59:20: error: field ‘_sockaddr’ has incomplete type
>struct sockaddr  _sockaddr;
> ^
> rdma/rdma_user_rxe.h:60:22: error: field ‘_sockaddr_in’ has incomplete type
>struct sockaddr_in _sockaddr_in;
>   ^~~~
> rdma/rdma_user_rxe.h:61:23: error: field ‘_sockaddr_in6’ has incomplete type
>struct sockaddr_in6 _sockaddr_in6;
>^
>
> Signed-off-by: Mikko Rapeli <mikko.rap...@iki.fi>
> ---
>  include/uapi/rdma/rdma_user_rxe.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/rdma/rdma_user_rxe.h 
> b/include/uapi/rdma/rdma_user_rxe.h
> index 1de99cf..ce6c929 100644
> --- a/include/uapi/rdma/rdma_user_rxe.h
> +++ b/include/uapi/rdma/rdma_user_rxe.h
> @@ -34,6 +34,8 @@
>  #define RDMA_USER_RXE_H
>
>  #include 
> +#include 
> +#include 
>
>  union rxe_gid {
> __u8raw[16];
> --
> 2.8.1
>
> --
> 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

Re: [PATCH v05 61/72] include/uapi/rdma/rdma_user_rxe.h: include in.h and in6.h

[Moni Shoua]

Acked-by: Moni Shoua 

On Mon, Aug 22, 2016 at 9:33 PM, Mikko Rapeli  wrote:
> Fixes these userspace compilation errors when rdma_user_rxe.h is compiled
> alone:
>
> rdma/rdma_user_rxe.h:59:20: error: field ‘_sockaddr’ has incomplete type
>struct sockaddr  _sockaddr;
> ^
> rdma/rdma_user_rxe.h:60:22: error: field ‘_sockaddr_in’ has incomplete type
>struct sockaddr_in _sockaddr_in;
>   ^~~~
> rdma/rdma_user_rxe.h:61:23: error: field ‘_sockaddr_in6’ has incomplete type
>struct sockaddr_in6 _sockaddr_in6;
>^
>
> Signed-off-by: Mikko Rapeli 
> ---
>  include/uapi/rdma/rdma_user_rxe.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/rdma/rdma_user_rxe.h 
> b/include/uapi/rdma/rdma_user_rxe.h
> index 1de99cf..ce6c929 100644
> --- a/include/uapi/rdma/rdma_user_rxe.h
> +++ b/include/uapi/rdma/rdma_user_rxe.h
> @@ -34,6 +34,8 @@
>  #define RDMA_USER_RXE_H
>
>  #include 
> +#include 
> +#include 
>
>  union rxe_gid {
> __u8raw[16];
> --
> 2.8.1
>
> --
> 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

Re: [PATCH 3/3] infiniband: rxe: fix 32-bit build warnings

[Moni Shoua]

thanks. will be applied to next series.

On Mon, Jun 13, 2016 at 3:54 PM, Arnd Bergmann  wrote:
> The new rxe infinband driver passes around pointers that have been
> converted to 64-bit integers. This is valid, but causes compile-time
> warnings on all 32-bit architectures:
>
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_map_single':
> infiniband/hw/rxe/rxe_dma.c:49:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
>   return (u64)cpu_addr;
>  ^
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_map_page':
> infiniband/hw/rxe/rxe_dma.c:73:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_map_sg':
> infiniband/hw/rxe/rxe_dma.c:99:10: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_alloc_coherent':
> infiniband/hw/rxe/rxe_dma.c:143:17: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
>
> This changes the cast to use 'uintptr_t', which can always be
> cast to and from pointer, and can be assigned to and from 64-bit
> integers.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/hw/rxe/rxe_dma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/rxe/rxe_dma.c 
> b/drivers/infiniband/hw/rxe/rxe_dma.c
> index f080bc5bda43..7634c1a81b2b 100644
> --- a/drivers/infiniband/hw/rxe/rxe_dma.c
> +++ b/drivers/infiniband/hw/rxe/rxe_dma.c
> @@ -46,7 +46,7 @@ static u64 rxe_dma_map_single(struct ib_device *dev,
>   enum dma_data_direction direction)
>  {
> WARN_ON(!valid_dma_direction(direction));
> -   return (u64)cpu_addr;
> +   return (uintptr_t)cpu_addr;
>  }
>
>  static void rxe_dma_unmap_single(struct ib_device *dev,
> @@ -70,7 +70,7 @@ static u64 rxe_dma_map_page(struct ib_device *dev,
> goto done;
> }
>
> -   addr = (u64)page_address(page);
> +   addr = (uintptr_t)page_address(page);
> if (addr)
> addr += offset;
>
> @@ -96,7 +96,7 @@ static int rxe_map_sg(struct ib_device *dev, struct 
> scatterlist *sgl,
> WARN_ON(!valid_dma_direction(direction));
>
> for_each_sg(sgl, sg, nents, i) {
> -   addr = (u64)page_address(sg_page(sg));
> +   addr = (uintptr_t)page_address(sg_page(sg));
> if (!addr) {
> ret = 0;
> break;
> @@ -140,7 +140,7 @@ static void *rxe_dma_alloc_coherent(struct ib_device 
> *dev, size_t size,
> addr = page_address(p);
>
> if (dma_handle)
> -   *dma_handle = (u64)addr;
> +   *dma_handle = (uintptr_t)addr;
>
> return addr;
>  }
> --
> 2.7.0
>
> --
> 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

Re: [PATCH 3/3] infiniband: rxe: fix 32-bit build warnings

[Moni Shoua]

thanks. will be applied to next series.

On Mon, Jun 13, 2016 at 3:54 PM, Arnd Bergmann  wrote:
> The new rxe infinband driver passes around pointers that have been
> converted to 64-bit integers. This is valid, but causes compile-time
> warnings on all 32-bit architectures:
>
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_map_single':
> infiniband/hw/rxe/rxe_dma.c:49:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
>   return (u64)cpu_addr;
>  ^
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_map_page':
> infiniband/hw/rxe/rxe_dma.c:73:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_map_sg':
> infiniband/hw/rxe/rxe_dma.c:99:10: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_alloc_coherent':
> infiniband/hw/rxe/rxe_dma.c:143:17: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
>
> This changes the cast to use 'uintptr_t', which can always be
> cast to and from pointer, and can be assigned to and from 64-bit
> integers.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/hw/rxe/rxe_dma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/rxe/rxe_dma.c 
> b/drivers/infiniband/hw/rxe/rxe_dma.c
> index f080bc5bda43..7634c1a81b2b 100644
> --- a/drivers/infiniband/hw/rxe/rxe_dma.c
> +++ b/drivers/infiniband/hw/rxe/rxe_dma.c
> @@ -46,7 +46,7 @@ static u64 rxe_dma_map_single(struct ib_device *dev,
>   enum dma_data_direction direction)
>  {
> WARN_ON(!valid_dma_direction(direction));
> -   return (u64)cpu_addr;
> +   return (uintptr_t)cpu_addr;
>  }
>
>  static void rxe_dma_unmap_single(struct ib_device *dev,
> @@ -70,7 +70,7 @@ static u64 rxe_dma_map_page(struct ib_device *dev,
> goto done;
> }
>
> -   addr = (u64)page_address(page);
> +   addr = (uintptr_t)page_address(page);
> if (addr)
> addr += offset;
>
> @@ -96,7 +96,7 @@ static int rxe_map_sg(struct ib_device *dev, struct 
> scatterlist *sgl,
> WARN_ON(!valid_dma_direction(direction));
>
> for_each_sg(sgl, sg, nents, i) {
> -   addr = (u64)page_address(sg_page(sg));
> +   addr = (uintptr_t)page_address(sg_page(sg));
> if (!addr) {
> ret = 0;
> break;
> @@ -140,7 +140,7 @@ static void *rxe_dma_alloc_coherent(struct ib_device 
> *dev, size_t size,
> addr = page_address(p);
>
> if (dma_handle)
> -   *dma_handle = (u64)addr;
> +   *dma_handle = (uintptr_t)addr;
>
> return addr;
>  }
> --
> 2.7.0
>
> --
> 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

Re: [PATCH 1/3] infiniband: rxe: avoid 64-bit division

[Moni Shoua]

thanks. will be applied to next series

On Mon, Jun 13, 2016 at 4:18 PM, Leon Romanovsky  wrote:
> On Mon, Jun 13, 2016 at 02:54:53PM +0200, Arnd Bergmann wrote:
>> The rxe driver fails to build on 32-bit because of a 64-bit division:
>>
>> In function `rxe_qp_from_attr':
>> :(.text+0x53158): undefined reference to `__aeabi_uldivmod'
>>
>> We can easily avoid this division by converting the nanosecond value
>> into jiffies directly rather than converting to microseconds first.
>>
>> Signed-off-by: Arnd Bergmann 
>
> Thanks Arnd,
> All three patches are applied on topic/rxe now.

Re: [PATCH 1/3] infiniband: rxe: avoid 64-bit division

[Moni Shoua]

thanks. will be applied to next series

On Mon, Jun 13, 2016 at 4:18 PM, Leon Romanovsky  wrote:
> On Mon, Jun 13, 2016 at 02:54:53PM +0200, Arnd Bergmann wrote:
>> The rxe driver fails to build on 32-bit because of a 64-bit division:
>>
>> In function `rxe_qp_from_attr':
>> :(.text+0x53158): undefined reference to `__aeabi_uldivmod'
>>
>> We can easily avoid this division by converting the nanosecond value
>> into jiffies directly rather than converting to microseconds first.
>>
>> Signed-off-by: Arnd Bergmann 
>
> Thanks Arnd,
> All three patches are applied on topic/rxe now.

Re: [PATCH 2/3] infiniband: rxe: add UDP_TUNNEL dependency

[Moni Shoua]

thanks. will be applied to next series

On Mon, Jun 13, 2016 at 3:54 PM, Arnd Bergmann  wrote:
> The newly added rxe driver links against the UDP tunneling code,
> which causes build errors when CONFIG_UDP_TUNNEL is disabled:
>
> ERROR: "setup_udp_tunnel_sock" [drivers/infiniband/hw/rxe/ib_rxe.ko] 
> undefined!
> ERROR: "udp_tunnel_sock_release" [drivers/infiniband/hw/rxe/ib_rxe.ko] 
> undefined!
> ERROR: "udp_sock_create4" [drivers/infiniband/hw/rxe/ib_rxe.ko] undefined!
>
> This adds a Kconfig dependency to prevent the invalid configuration.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/hw/rxe/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/hw/rxe/Kconfig 
> b/drivers/infiniband/hw/rxe/Kconfig
> index 649b7be11eb8..a199d0df31d0 100644
> --- a/drivers/infiniband/hw/rxe/Kconfig
> +++ b/drivers/infiniband/hw/rxe/Kconfig
> @@ -1,6 +1,7 @@
>  config INFINIBAND_RXE
> tristate "Software RDMA over Ethernet (RoCE) driver"
> depends on INET && PCI && INFINIBAND
> +   depends on NET_UDP_TUNNEL
> ---help---
> This driver implements the InfiniBand RDMA transport over
> the Linux network stack. It enables a system with a
> --
> 2.7.0
>
> --
> 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

Re: [PATCH 2/3] infiniband: rxe: add UDP_TUNNEL dependency

[Moni Shoua]

thanks. will be applied to next series

On Mon, Jun 13, 2016 at 3:54 PM, Arnd Bergmann  wrote:
> The newly added rxe driver links against the UDP tunneling code,
> which causes build errors when CONFIG_UDP_TUNNEL is disabled:
>
> ERROR: "setup_udp_tunnel_sock" [drivers/infiniband/hw/rxe/ib_rxe.ko] 
> undefined!
> ERROR: "udp_tunnel_sock_release" [drivers/infiniband/hw/rxe/ib_rxe.ko] 
> undefined!
> ERROR: "udp_sock_create4" [drivers/infiniband/hw/rxe/ib_rxe.ko] undefined!
>
> This adds a Kconfig dependency to prevent the invalid configuration.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/hw/rxe/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/hw/rxe/Kconfig 
> b/drivers/infiniband/hw/rxe/Kconfig
> index 649b7be11eb8..a199d0df31d0 100644
> --- a/drivers/infiniband/hw/rxe/Kconfig
> +++ b/drivers/infiniband/hw/rxe/Kconfig
> @@ -1,6 +1,7 @@
>  config INFINIBAND_RXE
> tristate "Software RDMA over Ethernet (RoCE) driver"
> depends on INET && PCI && INFINIBAND
> +   depends on NET_UDP_TUNNEL
> ---help---
> This driver implements the InfiniBand RDMA transport over
> the Linux network stack. It enables a system with a
> --
> 2.7.0
>
> --
> 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

Re: [patch] IB/rxe: fix error code in rxe_srq_from_init()

[Moni Shoua]

On Mon, Jun 13, 2016 at 9:53 AM, Dan Carpenter  wrote:
> If copy_to_user() fails then it returns the number of bytes not copied.
> It would be between 1-4 here.  Later the callers dereference it leading
> to an Oops.
>
> It was sort of hard to fix this without making the code confusing so I
> did a little cleanup.
>
> Fixes: 443c15d23220 ('IB/rxe: Shared Receive Queue (SRQ) manipulation 
> functions')
> Signed-off-by: Dan Carpenter 

Thanks Dan
I'll merge it to next series

Re: [patch] IB/rxe: fix error code in rxe_srq_from_init()

[Moni Shoua]

On Mon, Jun 13, 2016 at 9:53 AM, Dan Carpenter  wrote:
> If copy_to_user() fails then it returns the number of bytes not copied.
> It would be between 1-4 here.  Later the callers dereference it leading
> to an Oops.
>
> It was sort of hard to fix this without making the code confusing so I
> did a little cleanup.
>
> Fixes: 443c15d23220 ('IB/rxe: Shared Receive Queue (SRQ) manipulation 
> functions')
> Signed-off-by: Dan Carpenter 

Thanks Dan
I'll merge it to next series