linux-kernel - Re: a question about slub in function __slab

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]

Date:	Wed, 2 Mar 2016 23:12:32 +0800
From:	Jianyu Zhan <nasa4836@...il.com>
To:	Xishi Qiu <qiuxishi@...wei.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, Linux MM <linux-mm@...ck.org>,
	js1304@...il.com
Subject: Re: a question about slub in function __slab_free()

On Wed, Mar 2, 2016 at 8:26 PM, Xishi Qiu <qiuxishi@...wei.com> wrote:
> __slab_free()
>         prior = page->freelist;  // prior is NULL
>         was_frozen = new.frozen;  // was_frozen is 0
>         ...
>                 /*
>                  * Slab was on no list before and will be
>                  * partially empty
>                  * We can defer the list move and instead
>                  * freeze it.
>                  */
>                 new.frozen = 1;
>         ...
>
> I don't understand why "Slab was on no list before"?

in this  __slab_free() code path, we are freeing an object to a remote CPU.

Consider the condition that leads to this branch, that is:

new.inuse  && !prior && !was_frozen

new.inuse means that slab page has free objects after we do this free operiton.

!prior && !was_frozen together means  that slab page has previously
depleted all objects
and forgotten(SLUB don't remember a slab page that has got all its
object allocated).

All these 3 conditions mean that,

A slab page on a remote CPU has got all tis objects allocated and it
was forgotten by SLUB,
so  "Slab was on no list before",

and then at the present, we (on local CPU) are freeing object back to
that CPU,  that "will make
the slab page partially empty".

But we don't bother to immediately add it back to the node partial
list( to avoid the list->lock contention),
so "we can defer the list move".

But how do we handle this?  Easy, just mark it frozen,  and latter
that CPU's  per-cpu freelist queue will
use it.

Regards,
Jianyu Zhan