RE: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Simmons, James A.]

>Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
>
>Signed-off-by: Nilesh Kokane 
>---
> drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)

Bad idea. I also made this mistake and it broke LNet really badly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Nilesh Kokane]

On Fri, Oct 23, 2015 at 5:10 PM, Dilger, Andreas
 wrote:
> On 2015/10/22, 22:30, "Nilesh Kokane"  wrote:
>>Fixed- Return of an errno should typically be negative (ie: return
>>-EAGAIN)
>
> Nak. Please do not change these function return values.  They are
> converted as necessary by the callers before returning to userspace, but
> allow the code to distinguish between errors generated internally or from
> lower networking layers.
>
> As you will note, many of them are explicitly annotated with comments that
> they are returning positive values.  The patch as it stands would totally
> break the code.

Ok. I'll take care next time.

-- 
//Nilesh Kokane
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dilger, Andreas]

On 2015/10/22, 22:30, "Nilesh Kokane"  wrote:
>Fixed- Return of an errno should typically be negative (ie: return
>-EAGAIN)

Nak. Please do not change these function return values.  They are
converted as necessary by the callers before returning to userspace, but
allow the code to distinguish between errors generated internally or from
lower networking layers.

As you will note, many of them are explicitly annotated with comments that
they are returning positive values.  The patch as it stands would totally
break the code.

Cheers, Andreas

>Signed-off-by: Nilesh Kokane 
>---
> drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
>b/drivers/staging/lustre/lnet/lnet/lib-move.c
>index 433faae..10f886f 100644
>--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
>+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
>@@ -808,7 +808,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   lnet_finalize(ni, msg, -EHOSTUNREACH);
> 
>   lnet_net_lock(cpt);
>-  return EHOSTUNREACH;
>+  return -EHOSTUNREACH;
>   }
> 
>   if (msg->msg_md != NULL &&
>@@ -821,7 +821,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   lnet_finalize(ni, msg, -ECANCELED);
> 
>   lnet_net_lock(cpt);
>-  return ECANCELED;
>+  return -ECANCELED;
>   }
> 
>   if (!msg->msg_peertxcredit) {
>@@ -838,7 +838,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   if (lp->lp_txcredits < 0) {
>   msg->msg_tx_delayed = 1;
>   list_add_tail(>msg_list, >lp_txq);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -855,7 +855,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   if (tq->tq_credits < 0) {
>   msg->msg_tx_delayed = 1;
>   list_add_tail(>msg_list, >tq_delayed);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -922,7 +922,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int
>do_recv)
>   LASSERT(msg->msg_rx_ready_delay);
>   msg->msg_rx_delayed = 1;
>   list_add_tail(>msg_list, >lp_rtrq);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -942,7 +942,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int
>do_recv)
>   LASSERT(msg->msg_rx_ready_delay);
>   msg->msg_rx_delayed = 1;
>   list_add_tail(>msg_list, >rbp_msgs);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -1426,7 +1426,7 @@ lnet_parse_put(lnet_ni_t *ni, lnet_msg_t *msg)
>   libcfs_id2str(info.mi_id), info.mi_portal,
>   info.mi_mbits, info.mi_roffset, info.mi_rlength, rc);
> 
>-  return ENOENT;  /* +ve: OK but no match */
>+  return -ENOENT; /* +ve: OK but no match */
>   }
> }
> 
>@@ -1457,7 +1457,7 @@ lnet_parse_get(lnet_ni_t *ni, lnet_msg_t *msg, int
>rdma_get)
>   CNETERR("Dropping GET from %s portal %d match %llu offset %d 
> length
>%d\n",
>   libcfs_id2str(info.mi_id), info.mi_portal,
>   info.mi_mbits, info.mi_roffset, info.mi_rlength);
>-  return ENOENT;  /* +ve: OK but no match */
>+  return -ENOENT; /* +ve: OK but no match */
>   }
> 
>   LASSERT(rc == LNET_MATCHMD_OK);
>@@ -1524,7 +1524,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
>  md->md_me->me_portal);
> 
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve: OK but no match */
>+  return -ENOENT;   /* +ve: OK but no match */
>   }
> 
>   LASSERT(md->md_offset == 0);
>@@ -1539,7 +1539,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
>   rlength, hdr->msg.reply.dst_wmd.wh_object_cookie,
>   mlength);
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve: OK but no match */
>+  return -ENOENT;   /* +ve: OK but no match */
>   }
> 
>   CDEBUG(D_NET, "%s: Reply from %s of length %d/%d into md %#llx\n",
>@@ -1592,7 +1592,7 @@ lnet_parse_ack(lnet_ni_t *ni, lnet_msg_t *msg)
>  md->md_me->me_portal);
> 
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve! */
>+  return -ENOENT;   /* +ve! */
>   }
> 
>   CDEBUG(D_NET, "%s: ACK from %s into md %#llx\n",
>-- 
>1.9.1
>
>


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High 

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dan Carpenter]

On Fri, Oct 23, 2015 at 08:00:09AM +0300, Dan Carpenter wrote:
> On Fri, Oct 23, 2015 at 10:00:03AM +0530, Nilesh Kokane wrote:
> > Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
> > 
> 
> The changelog needs to describe the use visible effects of this change.
> 

I was expecting you to respond to my email saying that you had seen the
mistake...  Anyway, bugs like this are why the process requires that
user visible changes need documentation.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dilger, Andreas]

On 2015/10/22, 22:30, "Nilesh Kokane"  wrote:
>Fixed- Return of an errno should typically be negative (ie: return
>-EAGAIN)

Nak. Please do not change these function return values.  They are
converted as necessary by the callers before returning to userspace, but
allow the code to distinguish between errors generated internally or from
lower networking layers.

As you will note, many of them are explicitly annotated with comments that
they are returning positive values.  The patch as it stands would totally
break the code.

Cheers, Andreas

>Signed-off-by: Nilesh Kokane 
>---
> drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
>b/drivers/staging/lustre/lnet/lnet/lib-move.c
>index 433faae..10f886f 100644
>--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
>+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
>@@ -808,7 +808,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   lnet_finalize(ni, msg, -EHOSTUNREACH);
> 
>   lnet_net_lock(cpt);
>-  return EHOSTUNREACH;
>+  return -EHOSTUNREACH;
>   }
> 
>   if (msg->msg_md != NULL &&
>@@ -821,7 +821,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   lnet_finalize(ni, msg, -ECANCELED);
> 
>   lnet_net_lock(cpt);
>-  return ECANCELED;
>+  return -ECANCELED;
>   }
> 
>   if (!msg->msg_peertxcredit) {
>@@ -838,7 +838,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   if (lp->lp_txcredits < 0) {
>   msg->msg_tx_delayed = 1;
>   list_add_tail(>msg_list, >lp_txq);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -855,7 +855,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   if (tq->tq_credits < 0) {
>   msg->msg_tx_delayed = 1;
>   list_add_tail(>msg_list, >tq_delayed);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -922,7 +922,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int
>do_recv)
>   LASSERT(msg->msg_rx_ready_delay);
>   msg->msg_rx_delayed = 1;
>   list_add_tail(>msg_list, >lp_rtrq);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -942,7 +942,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int
>do_recv)
>   LASSERT(msg->msg_rx_ready_delay);
>   msg->msg_rx_delayed = 1;
>   list_add_tail(>msg_list, >rbp_msgs);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -1426,7 +1426,7 @@ lnet_parse_put(lnet_ni_t *ni, lnet_msg_t *msg)
>   libcfs_id2str(info.mi_id), info.mi_portal,
>   info.mi_mbits, info.mi_roffset, info.mi_rlength, rc);
> 
>-  return ENOENT;  /* +ve: OK but no match */
>+  return -ENOENT; /* +ve: OK but no match */
>   }
> }
> 
>@@ -1457,7 +1457,7 @@ lnet_parse_get(lnet_ni_t *ni, lnet_msg_t *msg, int
>rdma_get)
>   CNETERR("Dropping GET from %s portal %d match %llu offset %d 
> length
>%d\n",
>   libcfs_id2str(info.mi_id), info.mi_portal,
>   info.mi_mbits, info.mi_roffset, info.mi_rlength);
>-  return ENOENT;  /* +ve: OK but no match */
>+  return -ENOENT; /* +ve: OK but no match */
>   }
> 
>   LASSERT(rc == LNET_MATCHMD_OK);
>@@ -1524,7 +1524,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
>  md->md_me->me_portal);
> 
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve: OK but no match */
>+  return -ENOENT;   /* +ve: OK but no match */
>   }
> 
>   LASSERT(md->md_offset == 0);
>@@ -1539,7 +1539,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
>   rlength, hdr->msg.reply.dst_wmd.wh_object_cookie,
>   mlength);
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve: OK but no match */
>+  return -ENOENT;   /* +ve: OK but no match */
>   }
> 
>   CDEBUG(D_NET, "%s: Reply from %s of length %d/%d into md %#llx\n",
>@@ -1592,7 +1592,7 @@ lnet_parse_ack(lnet_ni_t *ni, lnet_msg_t *msg)
>  md->md_me->me_portal);
> 
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve! */
>+  return -ENOENT;   /* +ve! */
>   }
> 
>   CDEBUG(D_NET, "%s: ACK from %s into md %#llx\n",
>-- 
>1.9.1
>
>


Cheers, Andreas
-- 
Andreas 

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Nilesh Kokane]

On Fri, Oct 23, 2015 at 5:10 PM, Dilger, Andreas
 wrote:
> On 2015/10/22, 22:30, "Nilesh Kokane"  wrote:
>>Fixed- Return of an errno should typically be negative (ie: return
>>-EAGAIN)
>
> Nak. Please do not change these function return values.  They are
> converted as necessary by the callers before returning to userspace, but
> allow the code to distinguish between errors generated internally or from
> lower networking layers.
>
> As you will note, many of them are explicitly annotated with comments that
> they are returning positive values.  The patch as it stands would totally
> break the code.

Ok. I'll take care next time.

-- 
//Nilesh Kokane
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Simmons, James A.]

>Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
>
>Signed-off-by: Nilesh Kokane 
>---
> drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)

Bad idea. I also made this mistake and it broke LNet really badly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dan Carpenter]

On Fri, Oct 23, 2015 at 08:00:09AM +0300, Dan Carpenter wrote:
> On Fri, Oct 23, 2015 at 10:00:03AM +0530, Nilesh Kokane wrote:
> > Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
> > 
> 
> The changelog needs to describe the use visible effects of this change.
> 

I was expecting you to respond to my email saying that you had seen the
mistake...  Anyway, bugs like this are why the process requires that
user visible changes need documentation.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dan Carpenter]

On Fri, Oct 23, 2015 at 10:00:03AM +0530, Nilesh Kokane wrote:
> Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
> 

The changelog needs to describe the use visible effects of this change.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dan Carpenter]

On Fri, Oct 23, 2015 at 10:00:03AM +0530, Nilesh Kokane wrote:
> Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
> 

The changelog needs to describe the use visible effects of this change.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/