linux-kernel - Re: Linux 2.6.39-rc3

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, 14 Apr 2011 11:36:12 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Yinghai Lu <yinghai@...nel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alex Deucher <alexdeucher@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Linux 2.6.39-rc3

On Thu, Apr 14, 2011 at 01:03:37PM +0900, Tejun Heo wrote:
> Hello,
> 
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> > On Wednesday, April 13, 2011, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > > On Wednesday, April 13, 2011, H. Peter Anvin <hpa@...or.com> wrote:
> > >>
> > >> Yes.  However, even if we *do* revert (and the time is running short on
> > >> not reverting) I would like to understand this particular one, simply
> > >> because I think it may very well be a problem that is manifesting itself
> > >> in other ways on other systems.
> > 
> >  sorry, fingerfart. Anyway, I agree 100%.
> > 
> >  we definitely want to also understand the reason for things not
> > working, even if we do revert..
> 
> There were (and still are) places where memblock callers implemented
> ad-hoc top-down allocation by stepping down start limit until
> allocation succeeds.  Several of them have been removed since top-down
> became the default behavior, so simply reverting the commit is likely
> to cause subtle issues.  Maybe the best approach is introducing
> @topdown parameter and use it selectively for pure memory allocations.

Wouldn't it be better to provide a seperate memblock allocation
function which operates top-down and use this one in the places that
need it? This way it wouldn't break code that relies on bottom-up.

	Joerg

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