lkml.org 
[lkml]   [2010]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] UDPCP Communication Protocol
From
Date
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/

\
 
 \ /
  Last update: 2010-12-31 11:43    [W:1.192 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site