On 2021/4/20 7:55, Michal Kubecek wrote:
> On Mon, Apr 19, 2021 at 05:29:46PM +0200, Michal Kubecek wrote:
>>
>> As pointed out in the discussion on v3, this patch may result in
>> significantly higher CPU consumption with multiple threads competing on
>> a saturated outgoing device. I missed this
On 2021/4/19 22:57, Michal Kubecek wrote:
> On Mon, Apr 19, 2021 at 10:04:27AM +0800, Yunsheng Lin wrote:
>>>
>>> I tried this patch o top of 5.12-rc7 with real devices. I used two
>>> machines with 10Gb/s Intel ixgbe NICs, sender has 16 CPUs (2 8-core CPUs
>
On 2021/4/19 10:04, Yunsheng Lin wrote:
> On 2021/4/19 6:59, Michal Kubecek wrote:
>> On Thu, Mar 25, 2021 at 11:13:11AM +0800, Yunsheng Lin wrote:
>>> Lockless qdisc has below concurrent problem:
>>> cpu0 cpu1
>>> .
On 2021/4/17 20:33, zhudi (J) wrote:
>> On 2021/4/16 11:27, zhudi (J) wrote:
dependencyOn 2021/4/15 11:35, zhudi wrote:
> From: Di Zhu
>
> We encountered a crash: in the packet receiving process, we got an
> illegal VLAN device address, but the VLAN device address saved in
>>>
On 2021/4/19 6:59, Michal Kubecek wrote:
> On Thu, Mar 25, 2021 at 11:13:11AM +0800, Yunsheng Lin wrote:
>> Lockless qdisc has below concurrent problem:
>> cpu0 cpu1
>> .
On 2021/1/6 11:32, Dongseok Yi wrote:
> On 2021-01-06 12:07, Willem de Bruijn wrote:
>>
>> On Tue, Jan 5, 2021 at 8:29 PM Dongseok Yi wrote:
>>>
>>> On 2021-01-05 06:03, Willem de Bruijn wrote:
On Mon, Jan 4, 2021 at 4:00 AM Dongseok Yi wrote:
>
> skbs in frag_list could be shar
On 2021/4/16 11:27, zhudi (J) wrote:
>> dependencyOn 2021/4/15 11:35, zhudi wrote:
>>> From: Di Zhu
>>>
>>> We encountered a crash: in the packet receiving process, we got an
>>> illegal VLAN device address, but the VLAN device address saved in
>>> vmcore is correct. After checking the code, we fo
dependencyOn 2021/4/15 11:35, zhudi wrote:
> From: Di Zhu
>
> We encountered a crash: in the packet receiving process, we got an
> illegal VLAN device address, but the VLAN device address saved in vmcore
> is correct. After checking the code, we found a possible data
> competition:
> CPU 0:
the race without calling qdisc_run() at all, so
remove the STATE_DEACTIVATED checking in qdisc_run().
After qdisc_reset(), there is no skb in qdisc to be dequeued, so
clear the STATE_MISSED in dev_reset_queue() too.
Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
S
net: sched: allow qdiscs to handle locking")
Signed-off-by: Yunsheng Lin
Tested-by: Juergen Gross
---
V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED mirroring
NAPI's NAPIF_STATE_MISSED, and add Juergen's "Tested-by"
tag for there is only renaming and typo fixing betw
]. https://lkml.org/lkml/2019/10/9/42
Yunsheng Lin (2):
net: sched: fix packet stuck problem for lockless qdisc
net: sched: fix endless tx action reschedule during deactivation
include/net/pkt_sched.h | 7 +--
include/net/sch_generic.h | 37 -
net/core
]. https://lkml.org/lkml/2019/10/9/42
Yunsheng Lin (2):
net: sched: fix packet stuck problem for lockless qdisc
net: sched: fix endless tx action reschedule during deactivation
include/net/pkt_sched.h | 7 +--
include/net/sch_generic.h | 37 -
net/core
On 2021/4/14 18:48, Paolo Abeni wrote:
> the commit 1ddc3229ad3c ("skbuff: remove some unnecessary operation
> in skb_segment_list()") introduces an issue very similar to the
> one already fixed by commit 53475c5dd856 ("net: fix use-after-free when
> UDP GRO with shared fraglist").
>
> If the GSO
On 2021/4/14 16:08, Lijun Pan wrote:
> There are chances that napi_disable can be called twice by NIC driver.
> This could generate deadlock. For example,
> the first napi_disable will spin until NAPI_STATE_SCHED is cleared
> by napi_complete_done, then set it again.
> When napi_disable is called t
On 2021/4/13 16:33, Hillf Danton wrote:
> On Tue, 13 Apr 2021 15:57:29 Yunsheng Lin wrote:
>> On 2021/4/13 15:12, Hillf Danton wrote:
>>> On Tue, 13 Apr 2021 11:34:27 Yunsheng Lin wrote:
>>>> On 2021/4/13 11:26, Hillf Danton wrote:
>>>>> On Tue, 13 Ap
On 2021/4/13 15:12, Hillf Danton wrote:
> On Tue, 13 Apr 2021 11:34:27 Yunsheng Lin wrote:
>> On 2021/4/13 11:26, Hillf Danton wrote:
>>> On Tue, 13 Apr 2021 10:56:42 Yunsheng Lin wrote:
>>>> On 2021/4/13 10:21, Hillf Danton wrote:
>>>>> On
On 2021/4/13 11:26, Hillf Danton wrote:
> On Tue, 13 Apr 2021 10:56:42 Yunsheng Lin wrote:
>> On 2021/4/13 10:21, Hillf Danton wrote:
>>> On Mon, 12 Apr 2021 20:00:43 Yunsheng Lin wrote:
>>>>
>>>> Yes, the below patch seems to fix the data race described
On 2021/4/13 10:21, Hillf Danton wrote:
> On Mon, 12 Apr 2021 20:00:43 Yunsheng Lin wrote:
>>
>> Yes, the below patch seems to fix the data race described in
>> the commit log.
>> Then what is the difference between my patch and your patch below:)
>
> Hehe, t
On 2021/4/12 15:28, Hillf Danton wrote:
> On Mon, 12 Apr 2021 11:37:24 Yunsheng Lin wrote:
>> On 2021/4/12 11:21, Hillf Danton wrote:
>>> On Mon, 12 Apr 2021 09:24:30 Yunsheng Lin wrote:
>>>> On 2021/4/9 17:09, Hillf Danton wrote:
>>>>> On Fri, 9 Apr
On 2021/4/12 11:21, Hillf Danton wrote:
> On Mon, 12 Apr 2021 09:24:30 Yunsheng Lin wrote:
>> On 2021/4/9 17:09, Hillf Danton wrote:
>>> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
>>>> On 25.03.21 04:13, Yunsheng Lin wrote:
>>>> I have a setup
On 2021/4/9 17:09, Hillf Danton wrote:
> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
>> On 25.03.21 04:13, Yunsheng Lin wrote:
>> I have a setup which is able to reproduce the issue quite reliably:
>>
>> In a Xen guest I'm mounting 8 NFS shares and run sysbenc
On 2021/4/9 13:31, Juergen Gross wrote:
> On 25.03.21 04:13, Yunsheng Lin wrote:
>> Lockless qdisc has below concurrent problem:
>> cpu0 cpu1
>> . .
>> q->enqueue .
>> .
On 2021/4/6 15:31, Michal Kubecek wrote:
> On Tue, Apr 06, 2021 at 10:46:29AM +0800, Yunsheng Lin wrote:
>> On 2021/4/6 9:49, Cong Wang wrote:
>>> On Sat, Apr 3, 2021 at 5:23 AM Jiri Kosina wrote:
>>>>
>>>> I am still planning to have Yunsheng Lin's
On 2021/4/6 18:13, Juergen Gross wrote:
> On 06.04.21 09:06, Michal Kubecek wrote:
>> On Tue, Apr 06, 2021 at 08:55:41AM +0800, Yunsheng Lin wrote:
>>>
>>> Hi, Jiri
>>> Do you have a reproducer that can be shared here?
>>> With reproducer, I can debu
On 2021/4/6 9:49, Cong Wang wrote:
> On Sat, Apr 3, 2021 at 5:23 AM Jiri Kosina wrote:
>>
>> I am still planning to have Yunsheng Lin's (CCing) fix [1] tested in the
>> coming days. If it works, then we can consider proceeding with it,
>> otherwise I am all for reverting the whole NOLOCK stuff.
>>
On 2021/4/3 20:23, Jiri Kosina wrote:
> On Sat, 3 Apr 2021, Hillf Danton wrote:
>
> Sure. Seems they crept in over time. I had some plans to write a
> lockless HTB implementation. But with fq+EDT with BPF it seems that
> it is no longer needed, we have a more generic/better solution.
qdiscs to handle locking")
Signed-off-by: Yunsheng Lin
---
V3: fix a compile error and a few comment typo, remove the
__QDISC_STATE_DEACTIVATED checking, and update the
performance data.
V2: Avoid the overhead of fixing the data race as much as
possible.
---
include/
On 2021/3/25 3:20, Cong Wang wrote:
> On Tue, Mar 23, 2021 at 7:24 PM Yunsheng Lin wrote:
>> @@ -176,8 +207,23 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc)
>> static inline void qdisc_run_end(struct Qdisc *qdisc)
>> {
>> write_seqcount_end(&
On 2021/3/24 9:49, Cong Wang wrote:
> On Sun, Mar 21, 2021 at 5:55 PM Yunsheng Lin wrote:
>>
>> On 2021/3/20 2:15, Cong Wang wrote:
>>> On Thu, Mar 18, 2021 at 12:33 AM Yunsheng Lin
>>> wrote:
>>>>
>>>> On 2021/3/17 21:45, Jason A.
qdiscs to handle locking")
Signed-off-by: Yunsheng Lin
---
V2: Avoid the overhead of fixing the data race as much as
possible.
---
include/net/sch_generic.h | 48 ++-
net/sched/sch_generic.c | 12
2 files changed, 59 insertions(+
On 2021/3/23 14:37, Ahmad Fatoum wrote:
> Hi,
>
> On 22.03.21 10:09, Yunsheng Lin wrote:
>> Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
>> flag set, but queue discipline by-pass does not work for lockless
>> qdisc because skb is always enqueued t
On 2021/3/23 8:38, Cong Wang wrote:
> From: Cong Wang
>
> This is similar to tcp_read_sock(), except we do not need
> to worry about connections, we just need to retrieve skb
> from UDP receive queue.
>
> Cc: John Fastabend
> Cc: Daniel Borkmann
> Cc: Jakub Sitnicki
> Cc: Lorenz Bauer
> Sign
On 2021/3/23 8:37, Cong Wang wrote:
> From: Cong Wang
>
> Currently we rely on lock_sock to protect ingress_msg,
> it is too big for this, we can actually just use a spinlock
> to protect this list like protecting other skb queues.
>
> __tcp_bpf_recvmsg() is still special because of peeking,
> i
igned-off-by: Yunsheng Lin
---
Hi, Vladimir and Ahmad
Please give it a test to see if there is any out of order
packet for this patch, which has removed the priv->lock added in
RFC v2.
There is a data race as below:
CPU1 CPU2
qdisc
On 2021/3/20 3:45, Cong Wang wrote:
> On Fri, Mar 19, 2021 at 2:25 AM Yunsheng Lin wrote:
>> I had done some performance test to see if there is value to
>> fix the packet stuck problem and support lockless qdisc bypass,
>> here is some result using pktgen in 'q
On 2021/3/20 3:40, Cong Wang wrote:
> On Wed, Mar 17, 2021 at 11:52 PM Yunsheng Lin wrote:
>>
>> Lockless qdisc has below concurrent problem:
>> cpu0 cpu1
>> .
On 2021/3/20 3:03, Jason A. Donenfeld wrote:
> On Thu, Mar 18, 2021 at 1:33 AM Yunsheng Lin wrote:
>>> That offer definitely still stands. Generalization sounds like a lot of fun.
>>>
>>> Keep in mind though that it's an eventually consistent queue, not an
>
On 2021/3/20 2:15, Cong Wang wrote:
> On Thu, Mar 18, 2021 at 12:33 AM Yunsheng Lin wrote:
>>
>> On 2021/3/17 21:45, Jason A. Donenfeld wrote:
>>> On 3/17/21, Toke Høiland-Jørgensen wrote:
>>>> Cong Wang writes:
>>>>
>>>>> On Mon,
On 2021/3/18 14:53, Yunsheng Lin wrote:
> Lockless qdisc has below concurrent problem:
> cpu0 cpu1
> . .
> q->enqueue .
> . .
&g
On 2021/3/18 15:10, Ahmad Fatoum wrote:
> On 15.03.21 04:10, Yunsheng Lin wrote:
>> Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
>> flag set, but queue discipline by-pass does not work for lockless
>> qdisc because skb is always enqueued to qdisc even when
On 2021/3/17 21:45, Jason A. Donenfeld wrote:
> On 3/17/21, Toke Høiland-Jørgensen wrote:
>> Cong Wang writes:
>>
>>> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
I thought pfifo was supposed to be "lockless" and this change
re-introduces a lock between producer and consu
bit() at the end of qdisc_run_end().
Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
Signed-off-by: Yunsheng Lin
---
For those who has not been following the qdsic scheduling
discussion, there is packet stuck problem for lockless qdisc,
see [1], and I has done some
On 2021/3/17 6:48, Cong Wang wrote:
> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
>>
>> I thought pfifo was supposed to be "lockless" and this change
>> re-introduces a lock between producer and consumer, no?
>
> It has never been truly lockless, it uses two spinlocks in the ring buffer
On 2021/3/17 2:41, Cong Wang wrote:
> On Mon, Mar 15, 2021 at 2:29 AM Yunsheng Lin wrote:
>>
>> Currently qdisc_lock(q) is taken before enqueuing and dequeuing
>> for lockless qdisc's skb_bad_txq/gso_skb queue, qdisc->seqlock is
>> also taken, which can provide
On 2021/3/17 2:43, Cong Wang wrote:
> On Mon, Mar 15, 2021 at 4:42 PM David Miller wrote:
>>
>> From: Yunsheng Lin
>> Date: Mon, 15 Mar 2021 17:30:10 +0800
>>
>>> Currently qdisc_lock(q) is taken before enqueuing and dequeuing
>>> for lockless qdisc&#
On 2021/3/17 5:45, David Miller wrote:
> From: Yunsheng Lin
> Date: Tue, 16 Mar 2021 10:40:56 +0800
>
>> On 2021/3/16 7:41, David Miller wrote:
>>> From: Yunsheng Lin
>>
>> At least for the fast path, taking two locks for lockless qdisc hurts
>&
On 2021/3/16 16:15, Eric Dumazet wrote:
> On Tue, Mar 16, 2021 at 1:35 AM Yunsheng Lin wrote:
>>
>> On 2021/3/16 2:53, Jakub Kicinski wrote:
>>> On Mon, 15 Mar 2021 11:10:18 +0800 Yunsheng Lin wrote:
>>>> @@ -606,6 +623,11 @@ static const u8 prio2band[TC_PRIO
On 2021/3/16 8:35, Yunsheng Lin wrote:
> On 2021/3/16 2:53, Jakub Kicinski wrote:
>> On Mon, 15 Mar 2021 11:10:18 +0800 Yunsheng Lin wrote:
>>> @@ -606,6 +623,11 @@ static const u8 prio2band[TC_PRIO_MAX + 1] = {
>>> */
>>> struct pfifo_fast_priv {
>>
On 2021/3/16 7:41, David Miller wrote:
> From: Yunsheng Lin
> Date: Mon, 15 Mar 2021 17:30:10 +0800
>
>> Currently qdisc_lock(q) is taken before enqueuing and dequeuing
>> for lockless qdisc's skb_bad_txq/gso_skb queue, qdisc->seqlock is
>> also taken, which
On 2021/3/16 2:53, Jakub Kicinski wrote:
> On Mon, 15 Mar 2021 11:10:18 +0800 Yunsheng Lin wrote:
>> @@ -606,6 +623,11 @@ static const u8 prio2band[TC_PRIO_MAX + 1] = {
>> */
>> struct pfifo_fast_priv {
>> struct skb_array q[PFIFO_FAST_BANDS];
>> +
>
he lockless qdisc is running.
Signed-off-by: Yunsheng Lin
---
include/net/sch_generic.h | 2 --
net/sched/sch_generic.c | 72 +--
2 files changed, 19 insertions(+), 55 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
i
c is scheduled at the end of qdisc_run_end() when q->empty
is false to avoid packet stuck problem.
The performance for ip_forward test increases about 10% with this
patch.
Signed-off-by: Yunsheng Lin
---
RFC V2: fix requeued skb out of order and data race problem.
---
include/net/pkt_sched.
On 2021/3/14 18:15, Marc Kleine-Budde wrote:
> Cc += linux-...@vger.kernel.org
>
> On 3/14/21 1:03 AM, Vladimir Oltean wrote:
>> On Sat, Mar 13, 2021 at 10:47:47AM +0800, Yunsheng Lin wrote:
>>> Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
>>>
false to avoid packet stuck problem.
The performance for ip_forward test increases about 10% with this
patch.
Signed-off-by: Yunsheng Lin
---
include/net/sch_generic.h | 7 +--
net/core/dev.c| 11 +++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/inclu
On 2021/2/3 11:13, Wenjia Zhao wrote:
> net: hns3: double free 'skb'
>
> The false branch of (tx_ret == NETDEV_TX_OK) free the skb. However, the
> kfree_skb(skb) in the out label will be execute when exits the function.
> So the skb has a double-free bugs.
>
> Remove the kfree_skb(skb) at line 26
On 2021/1/21 15:41, Magnus Karlsson wrote:
> On Wed, Jan 20, 2021 at 9:29 PM Alexander Lobakin wrote:
>>
>> From: Xuan Zhuo
>> Date: Wed, 20 Jan 2021 16:30:56 +0800
>>
>>> This patch is used to construct skb based on page to save memory copy
>>> overhead.
>>>
>>> This function is implemented base
On 2021/1/16 10:44, Xuan Zhuo wrote:
> This patch is used to construct skb based on page to save memory copy
> overhead.
>
> This has one problem:
>
> We construct the skb by fill the data page as a frag into the skb. In
> this way, the linear space is empty, and the header information is also
>
On 2020/11/29 3:36, Jakub Kicinski wrote:
> On Sat, 28 Nov 2020 16:20:54 +1100 Stephen Rothwell wrote:
>> On Fri, 27 Nov 2020 17:56:42 -0800 Jakub Kicinski wrote:
>>>
>>> What's the offending structure in hisilicon? I'd rather have a look
>>> packing structs with pointers in 'em sounds questionabl
On 2020/11/28 9:56, Jakub Kicinski wrote:
> On Sat, 28 Nov 2020 12:28:19 +1100 Stephen Rothwell wrote:
>> There are 2 drivers that have arrays of packed structures that contain
>> pointers that end up at unaligned offsets. These produce warnings in
>> the PowerPC allyesconfig build like this:
>>
>
t can be interrupted by hard IRQ or NMI
context, lockdep_assert_in_softirq() need to assert about hard
IRQ or NMI context too.
Suggested-by: Jakub Kicinski
Signed-off-by: Yunsheng Lin
---
V3: add comment to emphasize the ambiguous semantics.
---
include/linux/lockdep.h | 8
1 file chang
Use napi_consume_skb() to assert the case when it is not called
in a atomic softirq context.
Signed-off-by: Yunsheng Lin
---
net/core/skbuff.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ffe3dcc..effa19d 100644
--- a/net/core/skbuff.c
+++ b
This patch introduces a lockdep_assert_in_softirq() interface and
uses it to assert the case when napi_consume_skb() is not called in
the softirq context.
Changelog:
V3: add comment to emphasize the ambiguous semantics
V2: Use lockdep instead of one-off Kconfig knob
Yunsheng Lin (2):
lockdep
On 2020/11/24 16:11, Peter Zijlstra wrote:
> On Mon, Nov 23, 2020 at 12:12:59PM -0800, Jakub Kicinski wrote:
>> One liner would be:
>>
>> * Acceptable for protecting per-CPU resources accessed from BH
>>
>> We can add:
>>
>> * Much like in_softirq() - semantics are ambiguous, use ca
This patch introduces a lockdep_assert_in_softirq() interface and
uses it to assert the case when napi_consume_skb() is not called in
the softirq context.
Changelog:
V2: Use lockdep instead of one-off Kconfig knob
Yunsheng Lin (2):
lockdep: Introduce in_softirq lockdep assert
net: Use
hard IRQ or NMI context too.
Suggested-by: Jakub Kicinski
Signed-off-by: Yunsheng Lin
---
include/linux/lockdep.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index f559487..f5e3d81 100644
--- a/include/linux/lockdep.h
+++ b/in
Use napi_consume_skb() to assert the case when it is not called
in a atomic softirq context.
Signed-off-by: Yunsheng Lin
---
net/core/skbuff.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ffe3dcc..effa19d 100644
--- a/net/core/skbuff.c
+++ b
On 2020/11/19 19:41, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 05:19:44PM +0800, Yunsheng Lin wrote:
>> On 2020/11/19 0:26, Jakub Kicinski wrote:
>>> On Wed, 18 Nov 2020 16:57:57 +0100 Peter Zijlstra wrote:
>>>> On Wed, Nov 18, 2020 at 07:43:48AM -0800, Jakub
On 2020/11/19 0:26, Jakub Kicinski wrote:
> On Wed, 18 Nov 2020 16:57:57 +0100 Peter Zijlstra wrote:
>> On Wed, Nov 18, 2020 at 07:43:48AM -0800, Jakub Kicinski wrote:
>>
>>> TBH the last sentence I wrote isn't clear even to me at this point ;D
>>>
>>> Maybe using just the macros from preempt.h - l
On 2020/11/3 3:41, Jakub Kicinski wrote:
> On Mon, 2 Nov 2020 11:14:32 +0800 Yunsheng Lin wrote:
>> On 2020/11/1 6:38, Jakub Kicinski wrote:
>>> On Thu, 29 Oct 2020 19:34:48 +0800 Yunsheng Lin wrote:
>>>> The current semantic for napi_consume_skb() is that caller
On 2020/11/9 20:46, Greg KH wrote:
> On Tue, Nov 03, 2020 at 11:25:38AM +0800, Yunsheng Lin wrote:
>> commit 2fb541c862c9 ("net: sch_generic: aviod concurrent reset and enqueue
>> op for lockless qdisc")
>>
>> When the above upstream commit is backported t
On 2020/11/5 14:16, Cong Wang wrote:
> On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote:
>>
>> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
>>>>> From my understanding, we can do anything about the old qdisc (including
>>>>> destorying the old q
On 2020/11/5 14:04, Cong Wang wrote:
> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
>>>> From my understanding, we can do anything about the old qdisc (including
>>>> destorying the old qdisc) after some_qdisc_is_busy() return false.
>>>
>>>
On 2020/11/3 0:55, Cong Wang wrote:
> On Fri, Oct 30, 2020 at 12:38 AM Yunsheng Lin wrote:
>>
>> On 2020/10/30 3:05, Cong Wang wrote:
>>>
>>> I do not see how and why it should. synchronize_net() is merely an optimized
>>> version of synchronize_rcu(), it
nment back to fix it.
1. https://www.spinics.net/lists/netdev/msg693916.html
2. https://www.spinics.net/lists/netdev/msg695131.html
Fixes: 749cc0b0c7f3 ("net: sch_generic: aviod concurrent reset and enqueue op
for lockless qdisc")
Signed-off-by: Yunsheng Lin
---
net/sched/sch_gener
On 2020/10/30 1:20, Vishwanath Pai wrote:
> On 10/29/20 6:24 AM, Yunsheng Lin wrote:
>> On 2020/10/29 12:50, Vishwanath Pai wrote:
>>> On 10/28/20 10:37 PM, Yunsheng Lin wrote:
>>>> On 2020/10/29 4:04, Vishwanath Pai wrote:
>>>>> On 10/28/20 1:47 PM, Co
On 2020/11/1 6:38, Jakub Kicinski wrote:
> On Thu, 29 Oct 2020 19:34:48 +0800 Yunsheng Lin wrote:
>> The current semantic for napi_consume_skb() is that caller need
>> to provide non-zero budget when calling from NAPI context, and
>> breaking this semantic will cause hard to d
On 2020/10/30 19:50, Joakim Tjernlund wrote:
> On Fri, 2020-10-30 at 09:36 +0800, Yunsheng Lin wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know the
>> content is safe
On 2020/10/30 3:05, Cong Wang wrote:
> On Wed, Oct 28, 2020 at 7:54 PM Yunsheng Lin wrote:
>>
>> On 2020/9/18 3:26, Cong Wang wrote:
>>> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
>>>>
>>>> On 2020/9/11 4:07, Cong Wang wrote:
&
On 2020/10/29 23:18, David Ahern wrote:
> On 10/29/20 8:10 AM, Joakim Tjernlund wrote:
>> OK, bisecting (was a bit of a bother since we merge upstream releases into
>> our tree, is there a way to just bisect that?)
>>
>> Result was commit "net: sch_generic: aviod concurrent reset and enqueue op
>
' napi_alloc_cache atomically.
So add a in_softirq() debug checking in napi_consume_skb() to catch
this kind of error.
Suggested-by: Eric Dumazet
Signed-off-by: Yunsheng Lin
---
v1: drop RFC in the title
---
include/linux/netdevice.h | 6 ++
net/Kconfig | 7 +++
net/core/skb
On 2020/10/29 12:50, Vishwanath Pai wrote:
> On 10/28/20 10:37 PM, Yunsheng Lin wrote:
>> On 2020/10/29 4:04, Vishwanath Pai wrote:
>>> On 10/28/20 1:47 PM, Cong Wang wrote:
>>>> On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
>>>>> Hi,
>>
On 2020/9/18 3:26, Cong Wang wrote:
> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
>>
>> On 2020/9/11 4:07, Cong Wang wrote:
>>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>>>>
>>>> Currently there is concurrent reset and enqueue
On 2020/10/29 4:04, Vishwanath Pai wrote:
> On 10/28/20 1:47 PM, Cong Wang wrote:
>> On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
>>> Hi,
>>>
>>> We noticed some problems when testing the latest 5.4 LTS kernel and traced
>>> it
>>> back to this commit using git bisect. When running our
On 2020/10/27 9:25, Jakub Kicinski wrote:
> On Tue, 27 Oct 2020 09:24:10 +0800 Yunsheng Lin wrote:
>>> Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF
>>> doing FLR")
>>
>> The correct Fixes tag should be:
>>
>&
On 2020/10/27 7:13, Jakub Kicinski wrote:
> On Fri, 23 Oct 2020 15:01:14 +0800 Zenghui Yu wrote:
>> On 2020/10/23 14:22, Yunsheng Lin wrote:
>>> On 2020/10/23 13:15, Zenghui Yu wrote:
>>>> When unbinding the hns3 driver with the HNS3 VF, I got t
On 2020/10/23 19:22, Dan Carpenter wrote:
> Smatch complains that "ret" might be uninitialized if we don't enter
> the loop. We do always enter the loop so it's a false positive, but
> it's cleaner to just return a literal zero and that silences the
> warning as well.
Thanks for the clean up. Min
On 2020/10/23 13:15, Zenghui Yu wrote:
> When unbinding the hns3 driver with the HNS3 VF, I got the following
> kernel panic:
>
> [ 265.709989] Unable to handle kernel paging request at virtual address
> 800054627000
> [ 265.717928] Mem abort info:
> [ 265.720740] ESR = 0x9647
> [ 2
' napi_alloc_cache atomically.
So add a in_softirq() debug checking in napi_consume_skb() to catch
this kind of error.
Suggested-by: Eric Dumazet
Signed-off-by: Yunsheng Lin
---
include/linux/netdevice.h | 6 ++
net/Kconfig | 7 +++
net/core/skbuff.c | 4
3 files ch
On 2020/9/21 16:17, Eric Dumazet wrote:
> On Mon, Sep 21, 2020 at 10:10 AM Yunsheng Lin wrote:
>>
>> On 2020/9/21 15:19, Eric Dumazet wrote:
>>> On Mon, Sep 21, 2020 at 4:08 AM Yunsheng Lin wrote:
>>>>
>>>> When napi_consume_skb() is called in the
On 2020/9/21 15:19, Eric Dumazet wrote:
> On Mon, Sep 21, 2020 at 4:08 AM Yunsheng Lin wrote:
>>
>> When napi_consume_skb() is called in the tx desc cleaning process,
>> it is usually in the softirq context(BH disabled, or are processing
>> softirqs), but it may also b
re if
NAPI context or not as long as it runs in softirq context or with BH
disabled, then _kfree_skb_defer() will push the skb to the particular
cpu' napi_alloc_cache atomically.
[1] https://lkml.org/lkml/2020/9/15/38
Signed-off-by: Yunsheng Lin
---
note that budget parameter is not remove
().
Signed-off-by: Yunsheng Lin
---
net/core/skbuff.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index bfd7483..e077447 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -895,9 +895,6 @@ void __kfree_skb_defer(struct sk_buff *skb)
void
Please ignore this patch, the title is not right, sorry for the noise.
On 2020/9/19 10:16, Yunsheng Lin wrote:
> When budget is non-zero, skb_unref() has already handled the
> NULL checking.
>
> When budget is zero, the dev_consume_skb_any() has handled NULL
> checking in __de
().
Signed-off-by: Yunsheng Lin
---
net/core/skbuff.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index bfd7483..e077447 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -895,9 +895,6 @@ void __kfree_skb_defer(struct sk_buff *skb)
void
On 2020/9/16 16:38, Eric Dumazet wrote:
> On Wed, Sep 16, 2020 at 10:33 AM Saeed Mahameed wrote:
>>
>> On Tue, 2020-09-15 at 15:04 +0800, Yunsheng Lin wrote:
>>> On 2020/9/15 13:09, Saeed Mahameed wrote:
>>>> On Mon, 2020-09-14 at 20:06 +0800, Huazhong
On 2020/9/15 13:09, Saeed Mahameed wrote:
> On Mon, 2020-09-14 at 20:06 +0800, Huazhong Tan wrote:
>> From: Yunsheng Lin
>>
>> Use napi_consume_skb() to batch consuming skb when cleaning
>> tx desc in NAPI polling.
>>
>> Signed-off-by: Yunsh
On 2020/9/15 5:45, Jakub Kicinski wrote:
> On Mon, 14 Sep 2020 20:06:56 +0800 Huazhong Tan wrote:
>> From: Yunsheng Lin
>>
>> writel() can be used to order I/O vs memory by default when
>> writing portable drivers. Use writel() to replace wmb() +
>> writel_r
On 2020/9/11 4:19, Cong Wang wrote:
> On Thu, Sep 3, 2020 at 8:21 PM Kehuan Feng wrote:
>> I also tried Cong's patch (shown below on my tree) and it could avoid
>> the issue (stressing for 30 minutus for three times and not jitter
>> observed).
>
> Thanks for verifying it!
>
>>
>> --- ./include/
On 2020/9/11 16:13, Yunsheng Lin wrote:
> On 2020/9/11 4:07, Cong Wang wrote:
>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>>>
>>> Currently there is concurrent reset and enqueue operation for the
>>> same lockless qdisc when there is no lock to
On 2020/9/11 4:07, Cong Wang wrote:
> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>>
>> Currently there is concurrent reset and enqueue operation for the
>> same lockless qdisc when there is no lock to synchronize the
>> q->enqueue() in __dev_xmit_skb() wit
1 - 100 of 253 matches
Mail list logo
