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: <c6f12967-e7bc-bf36-9c6b-0111dea1f0de@gentwo.org>
Date:   Mon, 23 Oct 2023 14:05:10 -0700 (PDT)
From:   "Christoph Lameter (Ampere)" <cl@...two.org>
To:     Vlastimil Babka <vbabka@...e.cz>
cc:     chengming.zhou@...ux.dev, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        roman.gushchin@...ux.dev, 42.hyeyoo@...il.com, willy@...radead.org,
        pcc@...gle.com, tytso@....edu, maz@...nel.org,
        ruansy.fnst@...itsu.com, vishal.moola@...il.com,
        lrh2000@....edu.cn, hughd@...gle.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Chengming Zhou <zhouchengming@...edance.com>
Subject: Re: [RFC PATCH v2 0/6] slub: Delay freezing of CPU partial slabs

On Mon, 23 Oct 2023, Vlastimil Babka wrote:

>> For much of the frozen handling we must be holding the node list lock
>> anyways in order to add/remove from the list. So we already have a lock
>> that could be used to protect flag operations.
>
> I can see the following differences between the traditional frozen bit and
> the new flag:
>
> frozen bit advantage:
> - __slab_free() on an already-frozen slab can ignore list operations and
> list_lock completely
>
> frozen bit disadvantage:
> - acquire_slab() trying to do cmpxchg_double() under list_lock (see commit
> 9b1ea29bc0d7)


Ok so a slab is frozen if either of those conditions are met. That gets a 
bit complicated to test for. Can we just get away with the 
slab_node_partial flag?

The advantage with the frozen state is that it can be changed with a 
cmpxchg together with some other values (list pointer, counter) that need 
updating at free and allocation.

But frozen updates are rarer so maybe its worth to completely drop the 
frozen bit. If both need to be updates then we would have two atomic ops. 
One is the cmpxchg and the other the operation on the page flag.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ