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]

Date:	Wed, 6 Sep 2006 10:35:55 +0800
From:	Aubrey <aubreylee@...il.com>
To:	"David Howells" <dhowells@...hat.com>
Cc:	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

Yeah, I agree with most of your opinion. Using PG_slab is really a
quickest way to determine the size of the object. But I think using a
flag named "PG_slab" on a memory algorithm named "slob" seems not
reasonable. It may confuse the people who start to read the kernel
source code. So I'm writing to ask if there is a better solution to
fix the issue.

-Aubrey

On 9/5/06, David Howells <dhowells@...hat.com> wrote:
> 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/