quoted

However, protocol families wishing to receive dropcount should call
sock_queue_rcv_skb() or set the dropcount specifically (as done
in packet_rcv()). This was not done for rxrpc and thus this feature
never worked on these sockets.

Formalizing this by not calling sock_recv_ts_and_drops() in rxrpc as
part of an effort to move skb->dropcount into skb->cb[]

Signed-off-by: Eyal Birger <redacted>
---
 net/rxrpc/ar-recvmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/ar-recvmsg.c b/net/rxrpc/ar-recvmsg.c
index 4575485..d58ba70 100644
--- a/net/rxrpc/ar-recvmsg.c
+++ b/net/rxrpc/ar-recvmsg.c

@@ -150,7 +150,7 @@ int rxrpc_recvmsg(struct kiocb *iocb, struct socket *sock,
                                     &call->conn->trans->peer->srx, len);
                              msg->msg_namelen = len;
                      }
-                     sock_recv_ts_and_drops(msg, &rx->sk, skb);
+                     sock_recv_timestamp(msg, &rx->sk, skb);
              }

I guess this should be the last patch of the serie, as this will
overwrite skb->mark, and rxrpc seems to care about skb->mark

Maybe I didn't understand your comment. Note this patch does not fix
SO_RXQ_OVFL on rxrpc sockets.

I essentially reverted 3b885787ea4112 for these sockets.

It may be possible to compact rxrpc skb->cb[] usage by tricking the size
of the resend_at variable as you suggested.

However, since SO_RXQ_OVFL never really worked on these sockets,
I limited the patch series scope to moving skb->dropcount; This patch only
signals that rxrpc can't support this feature unless some space is freed in its
skb->cb[] use.