linux-kernel - Re: [v2.6.26] what's brewing in x86.git for v2.6.26

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, 17 Apr 2008 03:06:11 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [v2.6.26] what's brewing in x86.git for v2.6.26

On Thu, 17 Apr 2008 11:46:06 +0200 Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > > you mean kmemcheck? Yes, that's planned. We've been working 4 months 
> > > non-stop on kmemcheck to make it mergeable and usable, it's at 
> > > version 7 right now, and it caught a handful of real bugs already 
> > > (such as 63a7138671c - unfortunately not credited in the log to 
> > > kmemcheck). But because it touches SLUB (because it has to - and 
> > > they are acked by Pekka) i never had the chance to move it into the 
> > > for-akpm branch.
> > 
> > Does it really really really need to consume one of our few remaining 
> > page flags?  We'll be in a mess when we run out.
> 
> well AFAICS the shortage really mostly affects 32-bit platforms. And 
> there we've got 19 bits used, out of 23 available, right?

Unfortunately the answer to that question is surprisingly hard to generate
and it probably has changed over time.  Christoph sat down and worked it
all out a few months ago.

One surprising problem is ia64 which uses (or used to use?) basically all
of the upper 32-bits.

> whether we track a page or not is rather fundamental to kmemcheck, i 
> dont see any easy way to get rid of that usage. (and since kmemcheck is 
> a transparent add-on, i dont see any obvious other candidate like 
> page->private either - all those fields might be utilized)

oooh yeah.  We've squeezed blood out of the pageframe.

> if we run out of that in the future: the high bits get used by sparse 
> section and numa node ID bits, worst-case we could live with restricting 
> the max number of NUMA nodes on 32-bit from 64 to 32? [NUMA on 32-bit is 
> an afterthought anyway.]

Yes, I think it's only NUMAQ and one of the old IBM machines.  I don't
think numaq ever went beyond 8 nodes.  superh is (or will) use NUMA, but
surely not with many nodes.

> Or we could do a CONFIG_KMEMCHECK=y only 
> page->flags_debug.

Yes, that'd be OK.   We could do that now, or just pop a comment in there.
--
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/