Messages in this thread | | | Subject | Re: [PATCH] UDPCP Communication Protocol | From | Eric Dumazet <> | Date | Fri, 31 Dec 2010 11:41:06 +0100 |
| |
Le vendredi 31 décembre 2010 à 11:22 +0100, Stefani Seibold a écrit : > Am Freitag, den 31.12.2010, 11:00 +0100 schrieb Eric Dumazet: > > Le vendredi 31 décembre 2010 à 10:29 +0100, stefani@seibold.net a > > écrit : > > > From: Stefani Seibold <stefani@seibold.net> > > > > > > > > > /* > > > * Handle MSG_ERRQUEUE > > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c > > > index 2d3ded4..f9890a2 100644 > > > --- a/net/ipv4/udp.c > > > +++ b/net/ipv4/udp.c > > > @@ -1310,7 +1310,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) > > > if (inet_sk(sk)->inet_daddr) > > > sock_rps_save_rxhash(sk, skb->rxhash); > > > > > > - rc = ip_queue_rcv_skb(sk, skb); > > > + rc = sock_queue_rcv_skb(sk, skb); > > > > Ouch... Care to explain why you changed this part ??? > > > > You just destroyed commit f84af32cbca70a intent, without any word in > > your changelog. Making UDP slower, while others try to speed it must be > > explained and advertised. > > > > In general, we prefer a preliminary patch introducing all the changes in > > current stack, then another one with the new protocol. > > > > I reverted this for two reasons: > > First ip_queue_rcv_skb drops the dst entry, which breaks the user land > application which expect packet info after a > > setsockopt(handle, IPPROTO_IP, IP_PKTINFO, &const_int_1, sizeof(int)); > > But for packets already in the queue this information will be lost. So > it is a potential race condition. >
Exactly same race with packet filters.
If your life depends on that, you must flush incoming queue _after_ issuing setsockopt(handle, IPPROTO_IP, IP_PKTINFO, &const_int_1, sizeof(int)). So that all following packets have the information needed.
> Second it breaks my UDPCP communication protocol stack module, which > works very well till 2.6.35. I need this information in the data_ready() > function to generate an ACK. > >
See now why you should not proceed like that ?
You know _perfectly_ there is a problem but prefer to keep it for you, and hope this bit will be unnoticed ?
This is not how things are dealed in linux, really.
You'll have to find a way so that things work well for everybody, not only for you.
I guess you must fix UDPCP protocol stack, not 'fix linux'
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |