Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp273188img; Thu, 21 Mar 2019 20:06:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqwCqgtEnIYAoX58cMsVQECMz/1ZK0FkXo77qWZttFZ8zLC9Ck6pxyrd5R9yk305XB9xABRk X-Received: by 2002:a63:da56:: with SMTP id l22mr6763742pgj.127.1553224013741; Thu, 21 Mar 2019 20:06:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553224013; cv=none; d=google.com; s=arc-20160816; b=PCDv5DM3P+EDLBBD7EkM4+jjsFne7jYXIZC1irktQmeBPeOENjte1wknBWfkaSa133 3r34r4MAu4NMiTzqEINHJOurTb4btlmQmT1L0hKiT+7oFfE3SO75p/9zn1uNG0M8ka7T ttqbrgR4dMyRKmv5SU7m6pO8A/XfqV3bJmEFjlV1Cbtdf085chiy1SAvYQ8yb6Aljs6s EFk75a352jdpzMR57rb4c2Pnt5y//PgYkIpeKy+AQLto5CeoOBE7NRohJVsE583+NXR0 VwQvmzM/y3zZ/dozBqBuXOEYBOh6y6aOEMXv9oaPpJFmHmpkpnCjKKgxS9ayj+9hJA1M EXPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=BIae8moISIM7t/XdRXpyvQNSin4W7NkmN125B85ZYAc=; b=f+qImhfVDDpjeCL5aXcgYEEZsVdFwyaRtbjnt0ipqIr6+p5gk2HG6QX+4BbE9JqiPV BU4Rw/9bimw1vhSKLltG1q79w4XpWK3+kmUy3dpyDBwVoowZK1BJjrDiYJcoFY2bN1jh nPEddhBzhif+2FkszpqX2Al0o1gHj8/xYkRBknjEBVixfXwgX/LL8pbsS8+T9Wai3n+B Cc8jBNT9ad5iEZcFO1Vr1vI9ZfV1xR1Vw7Z/51QI6JHtu5+fY/oeU6teQtaNSM9AeiIs tmIR1XiE2OJ9ZNovx5coTqh9TfwBGE1DAUxB4xuM5eOoMXCh+L9dLEEF96ujA5/jWm0c ThfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iMqsNa4K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1si5725897pgm.45.2019.03.21.20.06.36; Thu, 21 Mar 2019 20:06:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iMqsNa4K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727607AbfCVDFk (ORCPT + 99 others); Thu, 21 Mar 2019 23:05:40 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:34664 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727490AbfCVDFk (ORCPT ); Thu, 21 Mar 2019 23:05:40 -0400 Received: by mail-pf1-f193.google.com with SMTP id v64so510939pfb.1; Thu, 21 Mar 2019 20:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BIae8moISIM7t/XdRXpyvQNSin4W7NkmN125B85ZYAc=; b=iMqsNa4Kj58wHxZllNpD9jZXil4szL1fU7eS5BxZqRozWgv7qcQlHu3J4yHpJOWYs8 xdd9nB2PmtPPbXwi9inO+BLf0ZkCtV/aJiEnFvib5ooLphotd9LJp7QYu4AWv4pTkB+u 81zwvShwXW7qAIxzm9xQfX++GIJYwgcJLHVm/R5Ekxb1vok1ZoCtEIeE3C3wbZJuia1B abHPjRglE4SApHf465VMk1JI0oPx8zb7C1uEOND9Yxm3Rq/wH+Kd/XuRIvmBXzoToE6O TBMlxy71S6ehJ2KmI2WOLd4ZB2tNAYNQRxDFNlo6XUwfejC5Z2Nsf9J2LKGq3gT91X8q 344w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BIae8moISIM7t/XdRXpyvQNSin4W7NkmN125B85ZYAc=; b=tYnBc0ayuEy2o2jlqyBpXuDSr0P0Sax95kctmHhwT30Dqq3onuiT0wH9IC6xasjLxd iCbEtQNmoH1/YnQljYtLzr5evtpkE6VjoMc1tef+DzTzk7/eo7HsKEa0UEglop2DpxZr hvPFDGZLtQN+hMZpRgiCFw5xSa5QkPRF+4m9T/7Lk9p3rlByB2ILYCI5eKXMj1hwuCB2 9x2rDCno7W6FrCt8Tw0iW5FE+qDZoeduyjI4E1bX4EnP1isFV+eqrUuttRsqfzEUVAkr VuzMC21G3yiUsJB3YX3qvQQUEGh1ngNrLJcw3LNT1xuq6sHA42uxsuTfzFAUbRUImpVf EdtQ== X-Gm-Message-State: APjAAAV9haukz2EnKKETj90sj+iHhp5bCKauARxRfY57jqBq/auvEihb tnOCu4FlD6We7dC3Et+Ifrs4S7X9TprzwSQUfgw= X-Received: by 2002:a62:4815:: with SMTP id v21mr6612709pfa.167.1553223938403; Thu, 21 Mar 2019 20:05:38 -0700 (PDT) MIME-Version: 1.0 References: <20170324164902.15226.48358.stgit@localhost.localdomain> <20170324170812.15226.97497.stgit@localhost.localdomain> In-Reply-To: From: Christoph Paasch Date: Thu, 21 Mar 2019 23:05:27 -0400 Message-ID: Subject: Re: [net-next PATCH v3 4/8] net: Change return type of sk_busy_loop from bool to void To: Alexander Duyck , Paolo Abeni Cc: netdev , LKML , "Samudrala, Sridhar" , Eric Dumazet , David Miller , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Mar 21, 2019 at 12:43 PM Alexander Duyck wrote: > > On Thu, Mar 21, 2019 at 2:45 AM Paolo Abeni wrote: > > > > Hi, > > > > On Wed, 2019-03-20 at 11:35 -0700, Christoph Paasch wrote: > > > Hello, > > > > > > On Fri, Mar 24, 2017 at 3:23 PM Alexander Duyck > > > wrote: > > > > From: Alexander Duyck > > > > > > > > > From what I can tell there is only a couple spots where we are actually > > > > checking the return value of sk_busy_loop. As there are only a few > > > > consumers of that data, and the data being checked for can be replaced > > > > with a check for !skb_queue_empty() we might as well just pull the code > > > > out of sk_busy_loop and place it in the spots that actually need it. > > > > > > > > Signed-off-by: Alexander Duyck > > > > Acked-by: Eric Dumazet > > > > --- > > > > include/net/busy_poll.h | 5 ++--- > > > > net/core/datagram.c | 8 ++++++-- > > > > net/core/dev.c | 25 +++++++++++-------------- > > > > net/sctp/socket.c | 9 ++++++--- > > > > 4 files changed, 25 insertions(+), 22 deletions(-) > > > > > > > > diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h > > > > index b82d6ba70a14..c55760f4820f 100644 > > > > --- a/include/net/busy_poll.h > > > > +++ b/include/net/busy_poll.h > > > > @@ -74,7 +74,7 @@ static inline bool busy_loop_timeout(unsigned long end_time) > > > > return time_after(now, end_time); > > > > } > > > > > > > > -bool sk_busy_loop(struct sock *sk, int nonblock); > > > > +void sk_busy_loop(struct sock *sk, int nonblock); > > > > > > > > #else /* CONFIG_NET_RX_BUSY_POLL */ > > > > static inline unsigned long net_busy_loop_on(void) > > > > @@ -97,9 +97,8 @@ static inline bool busy_loop_timeout(unsigned long end_time) > > > > return true; > > > > } > > > > > > > > -static inline bool sk_busy_loop(struct sock *sk, int nonblock) > > > > +static inline void sk_busy_loop(struct sock *sk, int nonblock) > > > > { > > > > - return false; > > > > } > > > > > > > > #endif /* CONFIG_NET_RX_BUSY_POLL */ > > > > diff --git a/net/core/datagram.c b/net/core/datagram.c > > > > index ea633342ab0d..4608aa245410 100644 > > > > --- a/net/core/datagram.c > > > > +++ b/net/core/datagram.c > > > > @@ -256,8 +256,12 @@ struct sk_buff *__skb_try_recv_datagram(struct > > > > sock *sk, unsigned int flags, > > > > } > > > > > > > > spin_unlock_irqrestore(&queue->lock, cpu_flags); > > > > - } while (sk_can_busy_loop(sk) && > > > > - sk_busy_loop(sk, flags & MSG_DONTWAIT)); > > > > + > > > > + if (!sk_can_busy_loop(sk)) > > > > + break; > > > > + > > > > + sk_busy_loop(sk, flags & MSG_DONTWAIT); > > > > + } while (!skb_queue_empty(&sk->sk_receive_queue)); > > > > > > since this change I am hitting stalls where it's looping in this > > > while-loop with syzkaller. > > > > > > It worked prior to this change because sk->sk_napi_id was not set thus > > > sk_busy_loop would make us get out of the loop. > > > > > > Now, it keeps on looping because there is an skb in the queue with > > > skb->len == 0 and we are peeking with an offset, thus > > > __skb_try_recv_from_queue will return NULL and thus we have no way of > > > getting out of the loop. > > > > > > I'm not sure what would be the best way to fix it. I don't see why we > > > end up with an skb in the list with skb->len == 0. So, shooting a > > > quick e-mail, maybe somebody has an idea :-) > > > > > > I have the syzkaller-reproducer if needed. > > > > IIRC we can have 0 len UDP packet sitting on sk_receive_queue since: > > > > commit e6afc8ace6dd5cef5e812f26c72579da8806f5ac > > Author: samanthakumar > > Date: Tue Apr 5 12:41:15 2016 -0400 > > > > udp: remove headers from UDP packets before queueing > > > > Both __skb_try_recv_datagram() and napi_busy_loop() assume that we > > received some packets if the queue is not empty. When peeking such > > assumption is not true, we should check if the last packet is changed, > > as __skb_recv_datagram() already does. So I *think* the root cause of > > this issue is older than Alex's patch. > > I agree. > > > The following - completely untested - should avoid the unbounded loop, > > but it's not a complete fix, I *think* we should also change > > sk_busy_loop_end() in a similar way, but that is a little more complex > > due to the additional indirections. > > As far as sk_busy_loop_end we could look at just forking sk_busy_loop > and writing a separate implementation for datagram sockets that uses a > different loop_end function. It shouldn't take much to change since > all we would need to do is pass a structure containing the sk and last > pointers instead of just passing the sk directly as the loop_end > argument. > > > Could you please test it? > > > > Any feedback welcome! > > The change below looks good to me. I just tried it out. Worked for me! You can add my Tested-by if you do a formal patch-submission: Tested-by: Christoph Paasch Christoph > > > Could you please test it? > > > > Paolo > > --- > > diff --git a/net/core/datagram.c b/net/core/datagram.c > > index b2651bb6d2a3..e657289db4ac 100644 > > --- a/net/core/datagram.c > > +++ b/net/core/datagram.c > > @@ -279,7 +279,7 @@ struct sk_buff *__skb_try_recv_datagram(struct sock > > *sk, unsigned int flags, > > break; > > > > sk_busy_loop(sk, flags & MSG_DONTWAIT); > > - } while (!skb_queue_empty(&sk->sk_receive_queue)); > > + } while (sk->sk_receive_queue.prev != *last); > > > > error = -EAGAIN; > > > >