linux-kernel - Re: [patch] SLQB v2

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:	Thu, 1 May 2008 12:29:13 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Nick Piggin <npiggin@...e.de>
cc:	"Ahmed S. Darwish" <darwish.07@...il.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] SLQB v2

On Thu, 1 May 2008, Nick Piggin wrote:

> > A small question for SLUB devs, would you accept a patch that does
> > a similar thing by creating 'slub_page' instead of stuffing slub 
> > elements (freelist, inuse, ..) in 'mm_types::struct page' unions ?
> 
> I'd like to see that. I have a patch for SLUB, actually.

We could do that but then how do we make sure that both definitions stay 
in sync? So far I have thought that it is clearer if we have one def 
that shows how objects are overloaded.

There is also the overloading of page flags that is now done separately 
in SLUB. I wonder if that needs to be moved into page-flags.h? Would 
clarify how page flags are overloaded.

If someone inspects the contents of a page struct via debug then it would 
help if all the possible uses are in one place. If the stuff in tucked 
away in mm/sl?b.c then its difficult to find.

--
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/