lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 2 Sep 2020 16:14:48 +0800
From:   Yunsheng Lin <>
To:     Eric Dumazet <>,
        Cong Wang <>
CC:     Jamal Hadi Salim <>, Jiri Pirko <>,
        "David Miller" <>,
        Jakub Kicinski <>,
        "Linux Kernel Network Developers" <>,
        LKML <>, <>
Subject: Re: [PATCH net-next] net: sch_generic: aviod concurrent reset and
 enqueue op for lockless qdisc

On 2020/9/2 15:32, Eric Dumazet wrote:
> On 9/1/20 11:34 PM, Yunsheng Lin wrote:
>> I am not familiar with TCQ_F_CAN_BYPASS.
>> From my understanding, the problem is that there is no order between
>> qdisc enqueuing and qdisc reset.
> Thw qdisc_reset() should be done after rcu grace period, when there is guarantee no enqueue is in progress.
> qdisc_destroy() already has a qdisc_reset() call, I am not sure why qdisc_deactivate() is also calling qdisc_reset()

That is a good point.
Do we allow skb left in qdisc when the qdisc is deactivated state?
And qdisc_destroy() is not always called after qdisc_deactivate() is called.
If we allow skb left in qdisc when the qdisc is deactivated state, then it is
huge change of semantics for qdisc_deactivate(), and I am not sure how many
cases will affected by this change.


Powered by blists - more mailing lists