Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1468750 > unrolled thread

[REGRESSION] Select hang with zero sized UDP packets

Started byLaura Abbott <labbott@redhat.com>
First post2016-08-23 20:00 +0200
Last post2016-08-24 15:50 +0200
Articles 8 — 5 participants

Back to article view | Back to linux.kernel


Contents

  [REGRESSION] Select hang with zero sized UDP packets Laura Abbott <labbott@redhat.com> - 2016-08-23 20:00 +0200
    Re: [REGRESSION] Select hang with zero sized UDP packets David Miller <davem@davemloft.net> - 2016-08-23 20:30 +0200
      Re: [REGRESSION] Select hang with zero sized UDP packets Eric Dumazet <eric.dumazet@gmail.com> - 2016-08-23 21:10 +0200
        Re: [REGRESSION] Select hang with zero sized UDP packets Laura Abbott <labbott@redhat.com> - 2016-08-23 22:10 +0200
          Re: [REGRESSION] Select hang with zero sized UDP packets Eric Dumazet <eric.dumazet@gmail.com> - 2016-08-23 22:50 +0200
      Re: [REGRESSION] Select hang with zero sized UDP packets "Dan Akunis" <dan.akunis@gmail.com> - 2016-08-24 10:40 +0200
        Re: [REGRESSION] Select hang with zero sized UDP packets Eric Dumazet <eric.dumazet@gmail.com> - 2016-08-24 15:10 +0200
        Re: [REGRESSION] Select hang with zero sized UDP packets One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-24 15:50 +0200

#1468750 — [REGRESSION] Select hang with zero sized UDP packets

FromLaura Abbott <labbott@redhat.com>
Date2016-08-23 20:00 +0200
Subject[REGRESSION] Select hang with zero sized UDP packets
Message-ID<s9o9r-7dn-5@gated-at.bofh.it>
Hi,

Fedora received a report[1] of a unit test failing on Ruby when using the
4.7 kernel. This was a test to send a zero sized UDP packet. With the
4.7 kernel, the test now timing out on a select instead of completing.
The reduced ruby test is

   def test_udp_recvfrom_nonblock
     u1 = UDPSocket.new
     u2 = UDPSocket.new
     u1.bind("127.0.0.1", 0)
     u2.send("", 0, u1.getsockname)
     IO.select [u1]  # test gets stuck here
   ensure
     u1.close if u1
     u2.close if u2
   end


which roughly corresponds to this in C

int main()
{
         int fd1, fd2;
         struct sockaddr_in addr1;
         unsigned int len1;
         int ret;
         fd_set rfds;

         fd1 = socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP);
         fd2 = socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP);

         if (fd1 < 0 || fd2 < 0) {
                 printf("socket fail");
                 exit(1);
         }

         len1 = sizeof(addr1);

         memset(&addr1, 0, sizeof(addr1));
         addr1.sin_family = AF_INET;
         addr1.sin_addr.s_addr = inet_addr("127.0.0.1");
         addr1.sin_port = htons(0);
         ret = bind(fd1, (struct sockaddr *)&addr1, len1);
         if (ret < 0) {
                 printf("fu %d\n", errno);
                 exit(1);
         }

         ret = getsockname(fd1, (struct sockaddr *)&addr1, &len1);
         if (ret < 0) {
                 printf("getsockname failed %d\n", errno);
                 exit(1);
         }
         ret = sendto(fd2, "", 0, 0, (struct sockaddr *)&addr1, len1);
         if (ret < 0) {
                 printf("sendto failed %d\n", errno);
                 exit(1);
         }

         FD_ZERO(&rfds);
         FD_SET(fd1, &rfds);
	// hang here
         select(fd1+1, &rfds, NULL, NULL, NULL);
}


Bisection showed

commit e6afc8ace6dd5cef5e812f26c72579da8806f5ac
Author: samanthakumar <samanthakumar@google.com>
Date:   Tue Apr 5 12:41:15 2016 -0400

     udp: remove headers from UDP packets before queueing
     
     Remove UDP transport headers before queueing packets for reception.
     This change simplifies a follow-up patch to add MSG_PEEK support.
     
     Signed-off-by: Sam Kumar <samanthakumar@google.com>
     Signed-off-by: Willem de Bruijn <willemb@google.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>


As the offending commit. The issue is still reproducible on master
as of this morning and I don't see anything explicitly tagged in
net-next as fixing this.

Any ideas?

Thanks,
Laura

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1365940

[toc] | [next] | [standalone]


#1468765

FromDavid Miller <davem@davemloft.net>
Date2016-08-23 20:30 +0200
Message-ID<s9oCt-7Dc-5@gated-at.bofh.it>
In reply to#1468750
From: Laura Abbott <labbott@redhat.com>
Date: Tue, 23 Aug 2016 10:53:26 -0700

> Fedora received a report[1] of a unit test failing on Ruby when using
> the
> 4.7 kernel. This was a test to send a zero sized UDP packet. With the
> 4.7 kernel, the test now timing out on a select instead of completing.
> The reduced ruby test is
> 
>   def test_udp_recvfrom_nonblock
>     u1 = UDPSocket.new
>     u2 = UDPSocket.new
>     u1.bind("127.0.0.1", 0)
>     u2.send("", 0, u1.getsockname)
>     IO.select [u1]  # test gets stuck here
>   ensure
>     u1.close if u1
>     u2.close if u2
>   end

Well, if there is no data, should select really wake up?

I think it's valid not to.

[toc] | [prev] | [next] | [standalone]


#1468785

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-08-23 21:10 +0200
Message-ID<s9pfc-880-45@gated-at.bofh.it>
In reply to#1468765
On Tue, 2016-08-23 at 11:25 -0700, David Miller wrote:
> From: Laura Abbott <labbott@redhat.com>
> Date: Tue, 23 Aug 2016 10:53:26 -0700
> 
> > Fedora received a report[1] of a unit test failing on Ruby when using
> > the
> > 4.7 kernel. This was a test to send a zero sized UDP packet. With the
> > 4.7 kernel, the test now timing out on a select instead of completing.
> > The reduced ruby test is
> > 
> >   def test_udp_recvfrom_nonblock
> >     u1 = UDPSocket.new
> >     u2 = UDPSocket.new
> >     u1.bind("127.0.0.1", 0)
> >     u2.send("", 0, u1.getsockname)
> >     IO.select [u1]  # test gets stuck here
> >   ensure
> >     u1.close if u1
> >     u2.close if u2
> >   end
> 
> Well, if there is no data, should select really wake up?
> 
> I think it's valid not to.
There are skb in receive queue, with skb->len = 0

This looks like a bug in first_packet_length() or poll logic.

Definitely something we can fix.

Maybe with :

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index e61f7cd65d08..380c05a84041 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1184,11 +1184,11 @@ out:
  *	Drops all bad checksum frames, until a valid one is found.
  *	Returns the length of found skb, or 0 if none is found.
  */
-static unsigned int first_packet_length(struct sock *sk)
+static int first_packet_length(struct sock *sk)
 {
 	struct sk_buff_head list_kill, *rcvq = &sk->sk_receive_queue;
 	struct sk_buff *skb;
-	unsigned int res;
+	int res;
 
 	__skb_queue_head_init(&list_kill);
 
@@ -1203,7 +1203,7 @@ static unsigned int first_packet_length(struct sock *sk)
 		__skb_unlink(skb, rcvq);
 		__skb_queue_tail(&list_kill, skb);
 	}
-	res = skb ? skb->len : 0;
+	res = skb ? skb->len : -1;
 	spin_unlock_bh(&rcvq->lock);
 
 	if (!skb_queue_empty(&list_kill)) {
@@ -1232,7 +1232,7 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long arg)
 
 	case SIOCINQ:
 	{
-		unsigned int amount = first_packet_length(sk);
+		int amount = max(0, first_packet_length(sk));
 
 		return put_user(amount, (int __user *)arg);
 	}
@@ -2184,7 +2184,7 @@ unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait)
 
 	/* Check for false positives due to checksum errors */
 	if ((mask & POLLRDNORM) && !(file->f_flags & O_NONBLOCK) &&
-	    !(sk->sk_shutdown & RCV_SHUTDOWN) && !first_packet_length(sk))
+	    !(sk->sk_shutdown & RCV_SHUTDOWN) && first_packet_length(sk) == -1)
 		mask &= ~(POLLIN | POLLRDNORM);
 
 	return mask;

[toc] | [prev] | [next] | [standalone]


#1468812

FromLaura Abbott <labbott@redhat.com>
Date2016-08-23 22:10 +0200
Message-ID<s9qbg-ls-25@gated-at.bofh.it>
In reply to#1468785
On 08/23/2016 12:03 PM, Eric Dumazet wrote:
> On Tue, 2016-08-23 at 11:25 -0700, David Miller wrote:
>> From: Laura Abbott <labbott@redhat.com>
>> Date: Tue, 23 Aug 2016 10:53:26 -0700
>>
>>> Fedora received a report[1] of a unit test failing on Ruby when using
>>> the
>>> 4.7 kernel. This was a test to send a zero sized UDP packet. With the
>>> 4.7 kernel, the test now timing out on a select instead of completing.
>>> The reduced ruby test is
>>>
>>>   def test_udp_recvfrom_nonblock
>>>     u1 = UDPSocket.new
>>>     u2 = UDPSocket.new
>>>     u1.bind("127.0.0.1", 0)
>>>     u2.send("", 0, u1.getsockname)
>>>     IO.select [u1]  # test gets stuck here
>>>   ensure
>>>     u1.close if u1
>>>     u2.close if u2
>>>   end
>>
>> Well, if there is no data, should select really wake up?
>>
>> I think it's valid not to.
> There are skb in receive queue, with skb->len = 0
>
> This looks like a bug in first_packet_length() or poll logic.
>
> Definitely something we can fix.
>
> Maybe with :
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index e61f7cd65d08..380c05a84041 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1184,11 +1184,11 @@ out:
>   *	Drops all bad checksum frames, until a valid one is found.
>   *	Returns the length of found skb, or 0 if none is found.
>   */
> -static unsigned int first_packet_length(struct sock *sk)
> +static int first_packet_length(struct sock *sk)
>  {
>  	struct sk_buff_head list_kill, *rcvq = &sk->sk_receive_queue;
>  	struct sk_buff *skb;
> -	unsigned int res;
> +	int res;
>
>  	__skb_queue_head_init(&list_kill);
>
> @@ -1203,7 +1203,7 @@ static unsigned int first_packet_length(struct sock *sk)
>  		__skb_unlink(skb, rcvq);
>  		__skb_queue_tail(&list_kill, skb);
>  	}
> -	res = skb ? skb->len : 0;
> +	res = skb ? skb->len : -1;
>  	spin_unlock_bh(&rcvq->lock);
>
>  	if (!skb_queue_empty(&list_kill)) {
> @@ -1232,7 +1232,7 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long arg)
>
>  	case SIOCINQ:
>  	{
> -		unsigned int amount = first_packet_length(sk);
> +		int amount = max(0, first_packet_length(sk));
>
>  		return put_user(amount, (int __user *)arg);
>  	}
> @@ -2184,7 +2184,7 @@ unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait)
>
>  	/* Check for false positives due to checksum errors */
>  	if ((mask & POLLRDNORM) && !(file->f_flags & O_NONBLOCK) &&
> -	    !(sk->sk_shutdown & RCV_SHUTDOWN) && !first_packet_length(sk))
> +	    !(sk->sk_shutdown & RCV_SHUTDOWN) && first_packet_length(sk) == -1)
>  		mask &= ~(POLLIN | POLLRDNORM);
>
>  	return mask;
>
>

Fixes the test for me. You're welcome to take this as a Tested-by.

Thanks,
Laura

[toc] | [prev] | [next] | [standalone]


#1468838

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-08-23 22:50 +0200
Message-ID<s9qNY-Dm-19@gated-at.bofh.it>
In reply to#1468812
On Tue, 2016-08-23 at 13:06 -0700, Laura Abbott wrote:

> 
> Fixes the test for me. You're welcome to take this as a Tested-by.

Thanks Laura, I will submit an official patch immediately.

[toc] | [prev] | [next] | [standalone]


#1469210

From"Dan Akunis" <dan.akunis@gmail.com>
Date2016-08-24 10:40 +0200
Message-ID<s9BT4-89D-35@gated-at.bofh.it>
In reply to#1468765
When select wakes up on a UDP socket, user is expecting to get data. Getting 
0 from recvfrom() or whatever read function she uses, is a wrong attitude.
I agree with David.

The unit test that expects select to wake up is wrong and should be changed.

-----Original Message----- 
From: David Miller
Sent: Tuesday, August 23, 2016 9:25 PM
To: labbott@redhat.com
Cc: kuznet@ms2.inr.ac.ru ; jmorris@namei.org ; yoshfuji@linux-ipv6.org ; 
kaber@trash.net ; samanthakumar@google.com ; willemb@google.com ; 
netdev@vger.kernel.org ; linux-kernel@vger.kernel.org
Subject: Re: [REGRESSION] Select hang with zero sized UDP packets

From: Laura Abbott <labbott@redhat.com>
Date: Tue, 23 Aug 2016 10:53:26 -0700

> Fedora received a report[1] of a unit test failing on Ruby when using
> the
> 4.7 kernel. This was a test to send a zero sized UDP packet. With the
> 4.7 kernel, the test now timing out on a select instead of completing.
> The reduced ruby test is
>
>   def test_udp_recvfrom_nonblock
>     u1 = UDPSocket.new
>     u2 = UDPSocket.new
>     u1.bind("127.0.0.1", 0)
>     u2.send("", 0, u1.getsockname)
>     IO.select [u1]  # test gets stuck here
>   ensure
>     u1.close if u1
>     u2.close if u2
>   end

Well, if there is no data, should select really wake up?

I think it's valid not to. 

[toc] | [prev] | [next] | [standalone]


#1469402

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-08-24 15:10 +0200
Message-ID<s9G6m-2EF-27@gated-at.bofh.it>
In reply to#1469210
On Wed, 2016-08-24 at 11:22 +0300, Dan Akunis wrote:
> When select wakes up on a UDP socket, user is expecting to get data. Getting 
> 0 from recvfrom() or whatever read function she uses, is a wrong attitude.
> I agree with David.
> 
> The unit test that expects select to wake up is wrong and should be changed.
> 

Please do not top post on netdev mailing list.

Program is fine and wont be changed to work around a kernel bug.

We definitely can send and receive UDP messages with 0 payload.

So select() should unblock when one such frame is received, otherwise
you could fill up the receive queue with a lot of frames like that and
when SO_RCVBUF limit is reached, block future messages.

UDP is a datagram protocol.

Bug fix is merged :
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=e83c6744e81abc93a20d0eb3b7f504a176a6126a

[toc] | [prev] | [next] | [standalone]


#1469460

FromOne Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Date2016-08-24 15:50 +0200
Message-ID<s9GJ4-2Tn-21@gated-at.bofh.it>
In reply to#1469210
On Wed, 24 Aug 2016 11:22:09 +0300
"Dan Akunis" <dan.akunis@gmail.com> wrote:

> When select wakes up on a UDP socket, user is expecting to get data. Getting 
> 0 from recvfrom() or whatever read function she uses, is a wrong attitude.
> I agree with David.
> 
> The unit test that expects select to wake up is wrong and should be changed.

The unit test is correct.

The behaviour of a 0 byte frame is actually well established and a 0 byte
data frame is a meaningful message is several protocols. It is distinct
from no pending data because that would report EWOULDBLOCK. It's more fun
with regard to EOF but UDP has no EOF semantics. If you want to
understand how to handle zero length datagrams in a connection oriented
protocol the old DECnet documentation covers it in all its pain 8)

Alan

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web