linux-kernel - Re: [PATCH] SLOB allocator imcompatible 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]

Message-ID: <46809D88.2080208@yahoo.com.au>
Date:	Tue, 26 Jun 2007 15:00:56 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Matt Mackall <mpm@...enic.com>
CC:	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] SLOB allocator imcompatible SLAB

Matt Mackall wrote:
> On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
> 
>>Yoshinori Sato wrote:
>>
>>>At Fri, 22 Jun 2007 09:56:35 -0500,
>>>Matt Mackall wrote:
>>>
>>>
>>>>On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
>>>>
>>>>
>>>>>Because the page which SLOB allocator got does not have PG_slab,
>>>>
>>>>This is for a NOMMU system?
>>>
>>>
>>>Yes.
>>>
>>>
>>>
>>>>You're using an old kernel with an old version of SLOB. SLOB in newer
>>>>kernels actually sets per-page flags. Nick, can you see any reason not
>>>>to s/PG_active/PG_slab/ in the current code?
>>
>>The problem with this is that PG_private is used only for the SLOB
>>part of the allocator and not the bigblock part.
> 
> 
> That's fine, at least for the purposes of kobjsize. We only mark
> actual SLOB-managed pages, kobjsize assumes the rest are alloc_pages
> and that's indeed what they are.

OK, but that only makes it work in this case. I think we should
either call PG_slab part of the kmem/kmalloc API and implement
that, or say it isn't and make nommu do something else?


>>We _could_ just bite the bullet and have SLOB set PG_slab, however
>>that would encouarage more users of this flag which we should hope
>>to get rid of one day.
>>
>>The real problem is that nommu wants to get the size of either
>>kmalloc or alloc_pages objects and it needs to differentiate
>>between them. So I would rather nommu to take its own page flag
>>(could overload PG_swapcache, perhaps?), and set that flag on
>>pages it allocates directly, then uses that to determine whether
>>to call ksize or not.
> 
> 
> I think we already established on the last go-round that the kobjsize
> scheme was rather hopelessly broken anyway. 

I can't remember, but that would be another good reason to confine
it to nommu.c wouldn't it?

-- 
SUSE Labs, Novell Inc.
-
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/