linux-kernel - Re: [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to avoid lost wakeups

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y1rrmeq3.fsf@suse.de>
Date:   Thu, 01 Dec 2022 10:32:36 -0300
From:   Gabriel Krisman Bertazi <krisman@...e.de>
To:     Kemeng Shi <shikemeng@...wei.com>
Cc:     <axboe@...nel.dk>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <shikemeng@...weicloud.com>,
        <linfeilong@...wei.com>, <liuzhiqiang@...wei.com>
Subject: Re: [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to
 avoid lost wakeups

Kemeng Shi <shikemeng@...wei.com> writes:

> If we decremented queue without waiters, we should not decremente freed
> bits number "nr", or all "nr" could be consumed in a empty queue and no
> wakeup will be called.
> Currently, for case "wait_cnt > 0", "nr" will not be decremented if we
> decremented queue without watiers and retry is returned to avoid lost
> wakeups. However for case "wait_cnt == 0", "nr" will be decremented
> unconditionally and maybe decremented to zero. Although retry is
> returned by active state of queue, it's not actually executed for "nr"
> is zero.
>

Hi Kemeng,

Fwiw, I sent a patch rewriting this algorithm which is now merged in
axboe/for-next.  It drops the per-waitqueue wait_cnt entirely.  You can
find it here:

https://lore.kernel.org/lkml/20221110153533.go5qs3psm75h27mx@quack3/T/

Thanks!


-- 
Gabriel Krisman Bertazi