Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp270940yba; Wed, 8 May 2019 20:21:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqxP5Z1tSK/brwXQX/YCrlJGWVgMP1MaprGmbUOHXEPeewCQGXTyV9+cJY9lXcaNxBMlJhay X-Received: by 2002:a62:2506:: with SMTP id l6mr1853214pfl.250.1557372109097; Wed, 08 May 2019 20:21:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557372109; cv=none; d=google.com; s=arc-20160816; b=NATL+J6xH+YXvfApLvZ6ultHT9Mne9jQBGHQH2wPqoZ9Hc9IfEB0Bjxp9G1xV6cbBO EysM9KNMMuFXitGc7g0zqpdVh4+KWGc+av9jOxEGJySCu7Y8i8vLzzQsJsIZ+KL8sklj Fo/C6CdTbLmER++NAfyOzNNiYnXkP+P2/gYuS+JmUD31/qSIO47A0JNQHn2KqJxlY7mw TFJsWn4QVsfCXN2GUKKEDOQCzOZOXr+sk6FblVxdkU2E2wTPAOFBqdkJwav+8D3wY8ub 2uX8bX0NWxV629FebKJX3bAhrAXCWJyKevhVciUhDGALDvk/EW162hB0J5JMHltbGWQB 9Wpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=NA7s0kJld6R8NSWtGQkiJz9xN/yYIemFCvBVW31JLKk=; b=xUqkXWIKnjYQUOT0+GR/xdF+y2XSqXQwahzgsM6lN04eEOy0Zr4m5gNDcYJwscOFuW n9JfMn2k4FYW2Uhac7w346bKpW1QhMkSaaX2d4uF2S9w+4pnNZ88rLomQaWiYY8vNIv9 BB1bUIWI4kKkzIKjCy8Y9L313QXpY48PnyTCGQqLPe7GKDmFPmp4NCwIGENCurqaIeEP d4e9ynXj9i+prCiBxhORrxCfr9EJU2pImhzQ3SGoUu7WiDHK7ThZkWDkjXsEBhmyNieO fzfxB/JMDwm7LCeg1UsndnRLbDSq+u/FG1xOZycngvtpqU9k1dHpFVgnXNBpgAcvzp+J 6kBg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o15si1472155pgh.181.2019.05.08.20.21.33; Wed, 08 May 2019 20:21:49 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726787AbfEIDU0 (ORCPT + 99 others); Wed, 8 May 2019 23:20:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41160 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726251AbfEIDUZ (ORCPT ); Wed, 8 May 2019 23:20:25 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 69F688665F; Thu, 9 May 2019 03:20:25 +0000 (UTC) Received: from hp-dl380pg8-02.lab.eng.pek2.redhat.com (hp-dl380pg8-02.lab.eng.pek2.redhat.com [10.73.8.12]) by smtp.corp.redhat.com (Postfix) with ESMTP id 48A355C221; Thu, 9 May 2019 03:20:23 +0000 (UTC) From: Jason Wang To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: yuehaibing@huawei.com, xiyou.wangcong@gmail.com, weiyongjun1@huawei.com, eric.dumazet@gmail.com, Jason Wang Subject: [PATCH net V3 2/2] tuntap: synchronize through tfiles array instead of tun->numqueues Date: Wed, 8 May 2019 23:20:18 -0400 Message-Id: <1557372018-18544-2-git-send-email-jasowang@redhat.com> In-Reply-To: <1557372018-18544-1-git-send-email-jasowang@redhat.com> References: <1557372018-18544-1-git-send-email-jasowang@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 09 May 2019 03:20:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a queue(tfile) is detached through __tun_detach(), we move the last enabled tfile to the position where detached one sit but don't NULL out last position. We expect to synchronize the datapath through tun->numqueues. Unfortunately, this won't work since we're lacking sufficient mechanism to order or synchronize the access to tun->numqueues. To fix this, NULL out the last position during detaching and check RCU protected tfile against NULL instead of checking tun->numqueues in datapath. Cc: YueHaibing Cc: Cong Wang Cc: weiyongjun (A) Cc: Eric Dumazet Fixes: c8d68e6be1c3b ("tuntap: multiqueue support") Signed-off-by: Jason Wang --- Changes from V2: - resample during detach in tun_xdp_xmit() Changes from V1: - keep the check in tun_xdp_xmit() --- drivers/net/tun.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index dc62fc3..f4c933a 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -705,6 +705,8 @@ static void __tun_detach(struct tun_file *tfile, bool clean) tun->tfiles[tun->numqueues - 1]); ntfile = rtnl_dereference(tun->tfiles[index]); ntfile->queue_index = index; + rcu_assign_pointer(tun->tfiles[tun->numqueues - 1], + NULL); --tun->numqueues; if (clean) { @@ -1087,7 +1089,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev) tfile = rcu_dereference(tun->tfiles[txq]); /* Drop packet if interface is not attached */ - if (txq >= tun->numqueues) + if (!tfile) goto drop; if (!rcu_dereference(tun->steering_prog)) @@ -1310,6 +1312,7 @@ static int tun_xdp_xmit(struct net_device *dev, int n, rcu_read_lock(); +resample: numqueues = READ_ONCE(tun->numqueues); if (!numqueues) { rcu_read_unlock(); @@ -1318,6 +1321,8 @@ static int tun_xdp_xmit(struct net_device *dev, int n, tfile = rcu_dereference(tun->tfiles[smp_processor_id() % numqueues]); + if (unlikely(!tfile)) + goto resample; spin_lock(&tfile->tx_ring.producer_lock); for (i = 0; i < n; i++) { -- 1.8.3.1