linux-kernel - Re: More thoughts about hwpoison and pageflags compression

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:	Sat, 30 May 2009 00:29:30 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, fengguang.wu@...el.com
Subject: Re: More thoughts about hwpoison and pageflags compression

On Sat, 30 May 2009 09:27:58 +0200 Andi Kleen <andi@...stfloor.org> wrote:

> On Fri, May 29, 2009 at 11:53:02PM -0700, Andrew Morton wrote:
> > On Sat, 30 May 2009 08:37:10 +0200 Andi Kleen <andi@...stfloor.org> wrote:
> > 
> > > So using a separate bit is a sensible choice imho.
> > 
> > Could you make the feature 64-bit-only and use one of bits 32-63?
> 
> We could, but these systems can run 32bit kernels too (although
> it's probably not a good idea). Ok it would be probably possible
> to make it 64bit only, but I would prefer to not do that.
> 
> Also even 32bit has still flags free and even if we run out there's an easy 
> path to free more (see my earlier writeup)

hm.  Maybe that should be proven sooner rather than later.

> So I don't see the pressing need to conserve every bit on 32bit.
> 
> > Did you consider making the poison tag external to the pageframe?  Some
> > hash(page*) into a bitmap or something?  If suitably designed, such
> > infrastructure could perhaps be reused to reclaim some existing page
> > flags.  Dave Hansen had such a patch a few years back.  Or maybe it
> > was Andy Whitcroft.
> 
> I considered it at some point, but it would have complicated the code
> and I preferred to keep it simple. The poison handler should be relatively
> straight forward and do its work quickly otherwise it might not isolate
> the page before it's actually used.

Well it's going to get complicated when we run out anyway.  And run out
we shall.

Plus we haven't looked into the complexity of the external flags yet.
--
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/