linux-kernel - Re: [PATCH net v5 1/3] net: sched: fix packet stuck problem for lockless qdisc

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] [day] [month] [year] [list]

Date:   Fri, 7 May 2021 20:05:14 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Yunsheng Lin <linyunsheng@...wei.com>
Cc:     <davem@...emloft.net>, <olteanv@...il.com>, <ast@...nel.org>,
        <daniel@...earbox.net>, <andriin@...com>, <edumazet@...gle.com>,
        <weiwan@...gle.com>, <cong.wang@...edance.com>,
        <ap420073@...il.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linuxarm@...neuler.org>,
        <mkl@...gutronix.de>, <linux-can@...r.kernel.org>,
        <jhs@...atatu.com>, <xiyou.wangcong@...il.com>, <jiri@...nulli.us>,
        <andrii@...nel.org>, <kafai@...com>, <songliubraving@...com>,
        <yhs@...com>, <john.fastabend@...il.com>, <kpsingh@...nel.org>,
        <bpf@...r.kernel.org>, <jonas.bonn@...rounds.com>,
        <pabeni@...hat.com>, <mzhivich@...mai.com>, <johunt@...mai.com>,
        <albcamus@...il.com>, <kehuan.feng@...il.com>,
        <a.fatoum@...gutronix.de>, <atenart@...nel.org>,
        <alexander.duyck@...il.com>, <hdanton@...a.com>, <jgross@...e.com>,
        <JKosina@...e.com>, <mkubecek@...e.cz>, <bjorn@...nel.org>
Subject: Re: [PATCH net v5 1/3] net: sched: fix packet stuck problem for
 lockless qdisc

On Sat, 8 May 2021 10:55:19 +0800 Yunsheng Lin wrote:
> >> +		 * the flag set after releasing lock and reschedule the
> >> +		 * net_tx_action() to do the dequeuing.  
> > 
> > I don't understand why MISSED is checked before the trylock.
> > Could you explain why it can't be tested directly here?  
> The initial thinking was:
> Just like the set_bit() before the second trylock, If MISSED is set
> before first trylock, it means other thread has set the MISSED flag
> for this thread before doing the first trylock, so that this thread
> does not need to do the set_bit().
> 
> But the initial thinking seems over thinking, as thread 3' setting the
> MISSED before the second trylock has ensure either thread 3' second
> trylock returns ture or thread 2 holding the lock will see the MISSED
> flag, so thread 1 can do the test_bit() before or after the first
> trylock, as below:
> 
>     thread 1                thread 2                    thread 3
>                          holding q->seqlock
> first trylock failed                              first trylock failed
>                          unlock q->seqlock
>                                                test_bit(MISSED) return false
>                    test_bit(MISSED) return false
>                           and not reschedule
>                                                       set_bit(MISSED)
> 						      trylock success
> test_bit(MISSED) retun ture
> and not retry second trylock
> 
> If the above is correct, it seems we could:
> 1. do test_bit(MISSED) before the first trylock to avoid doing the
>    first trylock for contended case.
> or
> 2. do test_bit(MISSED) after the first trylock to avoid doing the
>    test_bit() for un-contended case.
> 
> Which one do you prefer?

No strong preference but testing after the trylock seems more obvious
as it saves the temporary variable.

For the contended case could we potentially move or add a MISSED test
before even the first try_lock()? I'm not good at optimizing things, 
but it could save us the atomic op, right? (at least on x86)