linux-kernel - Re: [PATCH] [RFC] mm: slab: separate 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <00000142de866123-cf1406b5-b7a3-4688-b46f-80e338a622a1-000000@email.amazonses.com>
Date:	Tue, 10 Dec 2013 22:00:18 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Dave Hansen <dave@...1.net>
cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	kirill.shutemov@...ux.intel.com, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] [RFC] mm: slab: separate slab_page from 'struct page'

On Tue, 10 Dec 2013, Dave Hansen wrote:

> >
> > The single page struct definitions makes it easy to see how a certain
> > field is being used in various subsystems. If you add a field then you
> > can see other use cases in other subsystems. If you happen to call
> > them then you know that there is trouble afoot.
>
> First of all, I'd really argue with the assertion that the way it is now
> make it easy to figure anything out.  Maybe we can take a vote. :)

Its certainly easier than it was before where we had page struct defs
spluttered in various subsystems.

> We _need_ to share fields when the structure is handed between different
> subsystems and it needs to be consistent in both places.  For slab page
> at least, the only data that actually gets used consistently is
> page->flags.  It seems silly to bend over backwards just to share a
> single bitfield.

If you get corruption in one field then you need to figure out which other
subsystem could have accessed that field. Its not a single bitfield. There
are numerous relationships between the fields in struct page.

> > How do you ensure that the sizes and the locations of the fields in
> > multiple page structs stay consistent?
>
> Check out the BUILD_BUG_ON().  That shows one example of how we do it
> for a field location.  We could do the same for sizeof() the two.

A bazillion of those? And this is simpler than what we ahve?

> > As far as I can tell we are trying to put everything into one page struct
> > to keep track of the uses of various fields and to allow a reference for
> > newcomes to the kernel.
>
> If the goal is to make a structure which is approachable to newcomers to
> the kernel, then I think we've utterly failed.

I do not see your approach making things easier. Having this stuff in one
place is helpful. I kept on discovering special use cases in various
kernel subsystems that caused breakage because of this and that
special use cases for fields. I think we were only able to optimize
slabs use of struct page because we finally had a better handle on what
uses which field for what purpose.

Looks to me that you want to go back to the old mess because we now have a
more complete accounting of how the fields are used. It may be a horror
but maybe you can help by simplifying things where possible and find as of
yet undocumented use cases for various page struct fields?

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