On Thu, Feb 26, 2015 at 4:31 PM, Eric Dumazet [off-list ref] wrote:

On Thu, 2015-02-26 at 09:30 +0200, Eyal Birger wrote:

quoted

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.
--

My point is : If you stick this patch early in the serie, then skb->mark
will be overwritten by sock_recv_timestamp() (to store skb->dropcount)
and rxrpc breaks as it actively relies on skb->mark (apparently)

skb->dropcount is stored prior to enqueue in sock_queue_rcv_skb().
This function is not called in rxrpc.

sock_recv_timestamp() is called from the recvmsg code, and does not alter
skb->dropcount.

What am I missing?

We dont care if SO_RXQ_OVFL is broken for rxprpc : Nobody noticed yet.

This was my point in this patch - to make it explicit. When rxrpc called
sock_recv_ts_and_drops() it allegedly supported receiving drops, when
dropcount was never set.

But breaking rxrpc skb->mark early in the serie does not help bisection
if needed later.