linux-kernel - Re: kernel BUGs when removing largish files with the SLOB allocator

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: <3551.1157448903@warthog.cambridge.redhat.com>
Date:	Tue, 05 Sep 2006 10:35:03 +0100
From:	David Howells <dhowells@...hat.com>
To:	Aubrey <aubreylee@...il.com>
Cc:	"David Howells" <dhowells@...hat.com>,
	linux-kernel@...r.kernel.org, mpm@...enic.com, davidm@...pgear.com,
	gerg@...pgear.com
Subject: Re: kernel BUGs when removing largish files with the SLOB allocator

Aubrey <aubreylee@...il.com> wrote:

> IMHO the problem is nommu.c is written for slab only. So when slob is
> enabled, it need to be considered to make some modification to make
> two or more memory allocator algorithms work properly, rather than to
> force all others algorithm to be compatible with the current one(slab)
> to match the code in the nommu.c, which is not common enough.
>
> Does that make sense?

No, not really.

The point is that kobjsize() needs to determine the size of the object it has
been asked to assess.  It knows how to do that directly if the page is
allocated by the main page allocator, but not if the page belongs to the slab
allocator.  The quickest way it can determine this is to look at PG_slab.  In
such a case it defers to the slab allocator for a determination.

What I don't want to happen is that we have to defer immediately to the slob
allocator which then goes and searches various lists to see if it owns the
page.  Remember: unless the page is _marked_ as belonging to the slob
allocator, the slob allocator may _not_ assume any of the metadata in struct
page is valid slob metadata.  It _has_ to determine the validity of the page
by other means _before_ it can use the metadata, and that most likely means a
search.  This is why PG_slab exists: if it is set, you _know_ you can
instantly trust the metadata.

Since slob appears to be an entry-point-by-entry-point replacement for the
slab allocator, the slob allocator can also mark its pages for anything that's
looking to defer to it using PG_slab since the presence of slab and slob are
mutually exclusive.

Also, we already have two major memory allocator algorithms in the kernel at
any one time: (1) the main page allocator and (2) slab or slob.  We don't
really want to start going to three or more.

So, I come back to the main question: Why don't you want to use PG_slab?

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/