[PATCH 4/5] sparc64: skip control packet while processing LDC RX queue

[PATCH 4/5] sparc64: skip control packet while processing LDC RX queue

[Jag Raman]

Skip the control-only packet while processing the RX queue, for LDC
channels in UNRELIABLE mode.

Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Aaron Young <aaron.young@oracle.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Reviewed-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
---
 arch/sparc/kernel/ldc.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/sparc/kernel/ldc.c b/arch/sparc/kernel/ldc.c
index 04996cc..3dc8467 100644
--- a/arch/sparc/kernel/ldc.c
+++ b/arch/sparc/kernel/ldc.c
@@ -1815,9 +1815,14 @@ static int read_nonraw(struct ldc_channel *lp, void *buf, unsigned int size)
 
 		lp->rcv_nxt = p->seqid;
 
+		/*
+		 * If this is a control-only packet, there is nothing
+		 * else to do but advance the rx queue since the packet
+		 * was already processed above.
+		 */
 		if (!(p->type & LDC_DATA)) {
 			new = rx_advance(lp, new);
-			goto no_data;
+			break;
 		}
 		if (p->stype & (LDC_ACK | LDC_NACK)) {
 			err = data_ack_nack(lp, p);
-- 
1.7.1

Re: [PATCH 4/5] sparc64: skip control packet while processing LDC RX queue

[David Miller]

From: Jag Raman <jag.raman@oracle.com>
Date: Wed, 29 Mar 2017 17:51:45 -0400

> Skip the control-only packet while processing the RX queue, for LDC
> channels in UNRELIABLE mode.
> 
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Reviewed-by: Aaron Young <aaron.young@oracle.com>
> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
> Reviewed-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com>
> Reviewed-by: Liam Merwick <liam.merwick@oracle.com>

This changes the semantics of read_nonraw().

The idea is that the caller only wants us to return if there is an
error, or actual data arrives (soon).

This is why the loop processes control packets and continues the loop.

Now, the routine can return without an error condition even if no
data is available.

I think you need to justify and explain more thoroughly this semantic
change in behavior.