[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1424961066.5565.151.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Thu, 26 Feb 2015 06:31:06 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Eyal Birger <eyal.birger@...il.com>
Cc: David Miller <davem@...emloft.net>,
Willem de Bruijn <willemb@...gle.com>,
Eric Dumazet <edumazet@...gle.com>,
Shmulik Ladkani <shmulik.ladkani@...il.com>,
Marcel Holtmann <marcel@...tmann.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/7] net: rxrpc: change call to
sock_recv_ts_and_drops() on rxrpc recvmsg to sock_recv_timestamp()
On Thu, 2015-02-26 at 09:30 +0200, Eyal Birger wrote:
> 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)
We dont care if SO_RXQ_OVFL is broken for rxprpc : Nobody noticed yet.
But breaking rxrpc skb->mark early in the serie does not help bisection
if needed later.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists