linux-kernel - Re: [PATCH] cpumask: introduce new API, without changing anything

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: <20081107093911.GD7787@elte.hu>
Date:	Fri, 7 Nov 2008 10:39:11 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Mike Travis <travis@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpumask: introduce new API, without changing anything

* Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> Hi Ingo,
> 
> On Fri, 7 Nov 2008 09:40:16 +0100 Ingo Molnar <mingo@...e.hu> wrote:
> >
> > if this is equal to the patch that you sent me (see the git 
> > coordinates below), it was also stess-tested and build-coverage tested 
> > by me on a healthy range of x86 systems, in a range of build 
> > environments.
> 
> It isn't identical.  See my message about a small merge conflict 
> between the cpus4096 tree and the rr tree in linux-next today.

but the change was not due to some merge conflict, it was a change 
done to the patch itself.

The merge conflict happened because Rusty iterated the patch in a 
non-append manner so two versions of the same patch collided in 
linux-next.

So ... what was the change, was it _really_ tested as-is in the 
linux-next tree for a longer time, or just merged a couple of hours 
ago?

Rusty, i pointed it out before, this kind of workflow you use in the 
rr tree is really inefficient for such types of changes. You destroy 
testing results by rebasing all the time, you make changes harder to 
review and as an end result you make it harder to achieve a better end 
result.

	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/