netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guoju Fang <gjfang@linux.alibaba.com>
To: linyunsheng@huawei.com
Cc: davem@davemloft.net, edumazet@google.com, eric.dumazet@gmail.com,
	gjfang@linux.alibaba.com, guoju.fgj@alibaba-inc.com,
	kuba@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com,
	rgauguey@kalrayinc.com, sjones@kalrayinc.com,
	vladimir.oltean@nxp.com, vray@kalrayinc.com, will@kernel.org
Subject: [PATCH v4 net] net: sched: add barrier to fix packet stuck problem for lockless qdisc
Date: Sat, 28 May 2022 18:16:28 +0800	[thread overview]
Message-ID: <20220528101628.120193-1-gjfang@linux.alibaba.com> (raw)
In-Reply-To: <64b3c3dc-e36d-45b6-4b3a-45e3d26e8315@huawei.com>

In qdisc_run_end(), the spin_unlock() only has store-release semantic,
which guarantees all earlier memory access are visible before it. But
the subsequent test_bit() has no barrier semantics so may be reordered
ahead of the spin_unlock(). The store-load reordering may cause a packet
stuck problem.

The concurrent operations can be described as below,
         CPU 0                      |          CPU 1
   qdisc_run_end()                  |     qdisc_run_begin()
          .                         |           .
 ----> /* may be reorderd here */   |           .
|         .                         |           .
|     spin_unlock()                 |         set_bit()
|         .                         |         smp_mb__after_atomic()
 ---- test_bit()                    |         spin_trylock()
          .                         |          .

Consider the following sequence of events:
    CPU 0 reorder test_bit() ahead and see MISSED = 0
    CPU 1 calls set_bit()
    CPU 1 calls spin_trylock() and return fail
    CPU 0 executes spin_unlock()

At the end of the sequence, CPU 0 calls spin_unlock() and does nothing
because it see MISSED = 0. The skb on CPU 1 has beed enqueued but no one
take it, until the next cpu pushing to the qdisc (if ever ...) will
notice and dequeue it.

This patch fix this by adding one explicit barrier. As spin_unlock() and
test_bit() ordering is a store-load ordering, a full memory barrier
smp_mb() is needed here.

Fixes: a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc")
Signed-off-by: Guoju Fang <gjfang@linux.alibaba.com>
---
V3 -> V4: Clarified why a full memory barrier is needed
V2 -> V3: Not split the Fixes tag across multiple lines
V1 -> V2: Rewrite comments
---
 include/net/sch_generic.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 9bab396c1f3b..93c808bd39aa 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -229,6 +229,12 @@ static inline void qdisc_run_end(struct Qdisc *qdisc)
 	if (qdisc->flags & TCQ_F_NOLOCK) {
 		spin_unlock(&qdisc->seqlock);
 
+		/* spin_unlock() only has store-release semantic. The unlock
+		 * and test_bit() ordering is a store-load ordering, so a full
+		 * memory barrier is needed here.
+		 */
+		smp_mb();
+
 		if (unlikely(test_bit(__QDISC_STATE_MISSED,
 				      &qdisc->state)))
 			__netif_schedule(qdisc);
-- 
2.34.0


  reply	other threads:[~2022-05-28 10:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1862202329.1457162.1643113633513.JavaMail.zimbra@kalray.eu>
     [not found] ` <698739062.1462023.1643115337201.JavaMail.zimbra@kalray.eu>
2022-01-28  2:36   ` packet stuck in qdisc Yunsheng Lin
2022-01-28  8:58     ` Vincent Ray
2022-01-28  9:59       ` Vincent Ray
2022-01-29  6:53         ` Yunsheng Lin
2022-01-31 18:39           ` Vincent Ray
2022-02-07  3:17             ` Yunsheng Lin
2022-03-25  6:16     ` Yunsheng Lin
2022-03-25  8:45       ` Vincent Ray
2022-04-13 13:01         ` Vincent Ray
2022-04-14  3:05           ` Guoju Fang
2022-05-23 13:54             ` packet stuck in qdisc : patch proposal Vincent Ray
2022-05-24  2:55               ` Eric Dumazet
2022-05-24  6:43               ` Yunsheng Lin
2022-05-24  8:13                 ` Vincent Ray
2022-05-24 17:00                   ` Vincent Ray
2022-05-24 20:17                     ` Eric Dumazet
2022-05-25  9:44                       ` Vincent Ray
2022-05-25 10:45                         ` Yunsheng Lin
2022-05-25 12:40                           ` Guoju Fang
2022-05-25 17:43                             ` Vincent Ray
2022-05-25 17:48                               ` Vincent Ray
2022-05-26  0:17                                 ` Eric Dumazet
2022-05-26  7:01                                   ` [PATCH v2] net: sched: add barrier to fix packet stuck problem for lockless qdisc Guoju Fang
2022-05-27  9:11                                     ` [PATCH v3 net] " Guoju Fang
2022-05-28  0:51                                       ` Yunsheng Lin
2022-05-28 10:16                                         ` Guoju Fang [this message]
2022-06-01  4:00                                           ` [PATCH v4 " patchwork-bot+netdevbpf
2022-05-30  9:36                                   ` packet stuck in qdisc : patch proposal Vincent Ray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220528101628.120193-1-gjfang@linux.alibaba.com \
    --to=gjfang@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=guoju.fgj@alibaba-inc.com \
    --cc=kuba@kernel.org \
    --cc=linyunsheng@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rgauguey@kalrayinc.com \
    --cc=sjones@kalrayinc.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=vray@kalrayinc.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).