linux-kernel - Re: [PATCH v6 42/45] mm: shrinker: make global slab shrink lockless

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]

Message-ID: <ZXA7MS+p/YjrN4Lj@dread.disaster.area>
Date:   Wed, 6 Dec 2023 20:13:21 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Lai Jiangshan <jiangshanlai@...il.com>
Cc:     Qi Zheng <zhengqi.arch@...edance.com>, akpm@...ux-foundation.org,
        paulmck@...nel.org, tkhai@...ru, vbabka@...e.cz,
        roman.gushchin@...ux.dev, djwong@...nel.org, brauner@...nel.org,
        tytso@....edu, steven.price@....com, cel@...nel.org,
        senozhatsky@...omium.org, yujie.liu@...el.com,
        gregkh@...uxfoundation.org, muchun.song@...ux.dev,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v6 42/45] mm: shrinker: make global slab shrink lockless

On Wed, Dec 06, 2023 at 04:23:24PM +0800, Lai Jiangshan wrote:
> On Wed, Dec 6, 2023 at 3:55 PM Qi Zheng <zhengqi.arch@...edance.com> wrote:
> > On 2023/12/6 15:47, Lai Jiangshan wrote:
> > > On Tue, Sep 12, 2023 at 9:57 PM Qi Zheng <zhengqi.arch@...edance.com> wrote:
> > >
> > No, this_shrinker will not be removed from the shrinker_list until the
> > last refcount is released. See below:
> >
> > > rcu_read_lock();
> > > shrinker_put(this_shrinker);
> >
> >         CPU 1                                      CPU 2
> >
> >    --> if (refcount_dec_and_test(&shrinker->refcount))
> >                 complete(&shrinker->done);
> >
> >                                 wait_for_completion(&shrinker->done);
> >                                  list_del_rcu(&shrinker->list);
> 
> since shrinker will not be removed from the shrinker_list until the
> last refcount is released.
> 
> Is it possible that shrinker_free() can be starved by continuous
> scanners getting and putting the refcount?

In theory, yes. In practice, highly improbable. i.e. I don't think
this will ever be an issue because the timing conditions for memory
reclaim to keep a permanently elevated reference count on a shrinker
for a subsystem that is being torn down are -highly- improbable.

And even if you could pull it off, who cares if shrinker_free() is
delayed? It's a teardown operation meaning the subsystem using the
shrinker will no longer be in use so the latency of the teardown
operation is largely irrelevant to whatever is still running
on the system.

-Dave.
-- 
Dave Chinner
david@...morbit.com