linux-kernel - Re: [git pull] x86 changes for v2.6.27

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] [day] [month] [year] [list]

Message-ID: <20080716140502.GA22631@elte.hu>
Date:	Wed, 16 Jul 2008 16:05:02 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] x86 changes for v2.6.27

* Bartlomiej Zolnierkiewicz <bzolnier@...il.com> wrote:

> 
> Hi,
> 
> On Monday 14 July 2008, Ingo Molnar wrote:
> > Linus,
> > 
> > Please pull the latest x86 git tree from:
> > 
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86/for-linus
> > 
> > this is our first merge window since we migrated over to a pure Git 
> > based patch management setup and integrated x86.git into the -tip tree. 
> > Going from Quilt to Git was quite hard for this 
> > 1000-patches-per-kernel-cycle tree, so please bear with us :-)
> 
> I see that fix patches are no longer folded into the guilty patch
> and it makes me a bit worried about kernel bisectability (on which
> many people depend on for hunting regressions)...
> 
> Random example (amongst many others) of what I mean:
> 
> [...]
> 
> >       x86: introduce max_low_pfn_mapped for 64-bit
> >       x86: max_low_pfn_mapped fix, #1
> >       x86: max_low_pfn_mapped fix, #2
> >       x86: max_low_pfn_mapped fix, #3
> 
> There is also a _ton_ of build fixes which could have been easily 
> folded into guilty patches.

actually, while there are indeed other examples where merging fixes 
would have made sense, those 3 above are conceptually different so we 
wanted to have them separate intentionally.

> Could you please consider adding this additional step into your 
> development process before push to Linus?

yeah, we definitely try to do that but -tip is released daily so the 
window to squash patches is small in an append-only setup. There were 2 
days between those fixes above so even if we wanted we couldnt squash 
them. The purpose of finegrained fixes is to observe the effects of the 
fixes. (sometimes the fix is worse than the bug it purports to fix)

Anyway, i think you'll see less of these in the next merge window.

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