Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp42753pxj; Wed, 16 Jun 2021 19:47:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGTJQyxZMi3Bv/I03J2LNImbBvMd9G9spwCajcaR98UrEznY8U8CM1N/MkoN+Ksg3MzAqz X-Received: by 2002:a17:906:5d14:: with SMTP id g20mr2566584ejt.243.1623898019856; Wed, 16 Jun 2021 19:46:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623898019; cv=none; d=google.com; s=arc-20160816; b=0eS3djsyd76qqvqrLfvP0rRQGRdaCOt8cVPgQSThhIijqHO/JIFxUzmAlMB0Xes186 aXayQiQjjy2go09R5lMopNcADco1NsQkhUGak8HzXRI458eCKpw/uMZwZibiuXNxGr1a U8L37XcTseiD2/yeFdd8xrUw2FFlwc0zF7XpHkTLP3ms97dWBVTbFAIKGZbBEAA0s8D8 UM4a9piEMDTmBviJrf7nF9CaTSB1Tr8fAY3go4faeySiEipqH3DKMS69j/nTPspNRSyL /qqgvEE7w25woJ+UKU/ZSLZiqD3xA39PW2Sv0mxWS5ofz0KGkVvy33D4QRlzMPJBW2pY H+7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=pzwcRwnzsSnmnFBfutIvmyx3mvRD+TXK9yqI3mKsPNU=; b=qe2QbgfDGS7YRpRCcO2qEYAQjiZYVf7lfcr2t/HOtAhgCp4NTs270yRvhMTo+q+yA4 x8z30hUfKW1ZnPNKImNn2lopEkPl52RkHdWOXhmITgCmVNonmsk7hIXpgUg25YtfAHyc sNtwSayLpVXBXJcMqVlKPXB4RJi1zr19H7HBNBJIoZp4yHJ4RuqtZl0GkjEP2oPXfcWu WIQF9w7OoRUXMu4XGVh+B5i9B/oa3oUF4uGXIMIZjkFjgwJoJCUygiHY3ozcaPFntlbk JxEaJZa4vA7924v+KWgN9REk5HbWoU+moMgLjdnIjl9gzSqJvzg+fd1HLGaFquE2Zy/j zixQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f26si4248417ejl.276.2021.06.16.19.46.37; Wed, 16 Jun 2021 19:46:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235083AbhFQBGr (ORCPT + 99 others); Wed, 16 Jun 2021 21:06:47 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:7310 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231441AbhFQBGq (ORCPT ); Wed, 16 Jun 2021 21:06:46 -0400 Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4G53c642QYz1BMmV; Thu, 17 Jun 2021 08:59:34 +0800 (CST) Received: from dggpemm500005.china.huawei.com (7.185.36.74) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 17 Jun 2021 09:04:36 +0800 Received: from localhost.localdomain (10.69.192.56) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 17 Jun 2021 09:04:36 +0800 From: Yunsheng Lin To: , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH net v2] net: sched: add barrier to ensure correct ordering for lockless qdisc Date: Thu, 17 Jun 2021 09:04:14 +0800 Message-ID: <1623891854-57416-1-git-send-email-linyunsheng@huawei.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.69.192.56] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The spin_trylock() was assumed to contain the implicit barrier needed to ensure the correct ordering between STATE_MISSED setting/clearing and STATE_MISSED checking in commit a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc"). But it turns out that spin_trylock() only has load-acquire semantic, for strongly-ordered system(like x86), the compiler barrier implicitly contained in spin_trylock() seems enough to ensure the correct ordering. But for weakly-orderly system (like arm64), the store-release semantic is needed to ensure the correct ordering as clear_bit() and test_bit() is store operation, see queued_spin_lock(). So add the explicit barrier to ensure the correct ordering for the above case. Fixes: a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc") Signed-off-by: Yunsheng Lin --- V2: add the missing Fixes tag. The above ordering issue can easily cause out of order packet problem when testing lockless qdisc bypass patchset [1] with two iperf threads and one netdev queue in arm64 system. 1. https://lkml.org/lkml/2021/6/2/1417 --- include/net/sch_generic.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index 1e62551..5771030 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -163,6 +163,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) if (spin_trylock(&qdisc->seqlock)) goto nolock_empty; + /* Paired with smp_mb__after_atomic() to make sure + * STATE_MISSED checking is synchronized with clearing + * in pfifo_fast_dequeue(). + */ + smp_mb__before_atomic(); + /* If the MISSED flag is set, it means other thread has * set the MISSED flag before second spin_trylock(), so * we can return false here to avoid multi cpus doing @@ -180,6 +186,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) */ set_bit(__QDISC_STATE_MISSED, &qdisc->state); + /* spin_trylock() only has load-acquire semantic, so use + * smp_mb__after_atomic() to ensure STATE_MISSED is set + * before doing the second spin_trylock(). + */ + smp_mb__after_atomic(); + /* Retry again in case other CPU may not see the new flag * after it releases the lock at the end of qdisc_run_end(). */ -- 2.7.4