lists.openwall.net   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  linux-cve-announce  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]
Message-ID: <441a41d4-b547-6c30-f9a8-f76604293215@huawei.com>
Date:   Wed, 17 Mar 2021 08:45:17 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     David Miller <davem@...emloft.net>
CC:     <kuba@...nel.org>, <jhs@...atatu.com>, <xiyou.wangcong@...il.com>,
        <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linuxarm@...neuler.org>
Subject: Re: [PATCH net-next] net: sched: remove unnecessay lock protection
 for skb_bad_txq/gso_skb

On 2021/3/17 5:45, David Miller wrote:
> From: Yunsheng Lin <linyunsheng@...wei.com>
> Date: Tue, 16 Mar 2021 10:40:56 +0800
> 
>> On 2021/3/16 7:41, David Miller wrote:
>>> From: Yunsheng Lin <linyunsheng@...wei.com>
>>
>> At least for the fast path, taking two locks for lockless qdisc hurts
>> performance when handling requeued skb, especially if the lockless
>> qdisc supports TCQ_F_CAN_BYPASS.
> 
> The bad txq and gro skb cases are not "fast path", sorry

You are right, it is more of exceptional data path, but it is still
ok to clean that up without obvious risk, right?
For I am going to replace qdisc->seqlock with qdisc_lock(q) for lockless
qdisc too and remove qdisc->seqlock, which makes more sense.


> 
> .
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ