linux-kernel - Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.

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]

Message-Id: <20080204025133.511ac3e2.akpm@linux-foundation.org>
Date:	Mon, 4 Feb 2008 02:51:33 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	schwidefsky@...ibm.com
Cc:	benh@...nel.crashing.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.

On Mon, 04 Feb 2008 11:36:49 +0100 Martin Schwidefsky <schwidefsky@...ibm.com> wrote:

> On Sat, 2008-02-02 at 21:53 -0800, Andrew Morton wrote:
> > On Sun, 03 Feb 2008 16:37:00 +1100 Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> > 
> > > Why dropping add-mm-argument-to-pte-pmd-pud-pgd_free.patch though ?
> > 
> > I dropped the whole series.
>
> Sniff .. my patches .. ;-)

Well yes.  People who merge via -mm continue to be at a disadvantage
because they're forced to go behind all the subsystem trees.  Plus I (and
apparently I alone) will skip patches when the kernel is
more-than-usually-wrecked and will slow things down for stabilisation as
we're heading into the merge window.

Plus: I started to prepare 2.6.24-mm1 on Friday morning, worked all weekend
and got it out Sunday evening after having committed forty to fifty fixes
and having dropped numerous patches.

If this situation (conflicting changes and poor code quality) persists into
the 2.6.25 cycle I will toss all the subsystem trees out of -mm, shall
rebase -mm on mainline and shall merge first.  I had decided today to
actually just do this, but on reflection I'll give it just one more shot.

It's remarkable how many bugs are in current mainline which weren't in
2.6.24-rc8-mm1.  What could have caused this?

> > Look: I can't fix *everyone's* stuff.  This was a consequence of ongoing
> > unbounded churn in the x86 tree.  If we can find a way of preventing those
> > guys (and everyone else) from trashing everyone else's stuff then we'd have
> > much smoother sailing.
> 
> Understood. That is where I jump in and regenerate my patches on the
> latest available level. That the patches did hold up for some months in
> -mm now without really breaking anything is an indication that we can
> push them upstream now, isn't ? That would make the patch problem go
> away and I could queue my s390 specific page table rework. Our KVM
> people keep asking about it.

yes, against 2.6.24-mm1 would be good, thanks.  I really don't know what
went wrong in i386 but I ended up getting all grumpy at the macro mess
we've made in all the pagetable handling.  Please do take a look at
improving that.

(goes back to bisecting)
--
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/