linux-kernel - Re: [PATCH] UDPCP Communication Protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1293794589.5285.16.camel@wall-e>
Date:	Fri, 31 Dec 2010 12:23:09 +0100
From:	Stefani Seibold <stefani@...bold.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] UDPCP Communication Protocol

Am Freitag, den 31.12.2010, 11:41 +0100 schrieb Eric Dumazet:
> 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@...bold.net a
> > > écrit :
> > > > From: Stefani Seibold <stefani@...bold.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.
> 
> 

I though always that the linux kernel never breaks user land. This is a
break!

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

Stop to accuse me. There was a feature that was gone. An it took me six
hours to figure out whats going wrong. I did not saw and see a real
problem with this patch. It looked for me like an easy and clean
solution. It was never my intention to trick somebody, especially u.

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

I cannot fix it, because the information is still lost, and i need it. 

In my opinion it was a very bad idea to throw away important
information. I checked it and Linux handle this since 2.6.0 in this way.

It would be better not to accuse than to work on a solution. 

Question: How much performace gain does the early drop give. Are there
benchmark results?



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/