linux-kernel - Re: [GIT] Networking

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110315143708.GB31746@fieldses.org>
Date:	Tue, 15 Mar 2011 10:37:08 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	david@...g.hm, Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT] Networking

On Tue, Mar 15, 2011 at 08:52:40AM -0400, Steven Rostedt wrote:
> But it wont, as the fix will still be brought in at a later time. It has
> nothing to do with being based off of the broken commit.
> 
>          A  +
>             +   merged in fix
>          B  + \
>             |  |
>             |  |
>             |  |
> Lots of     |  |
>   stuff     |  |
>             |  |
>             |  |
>             |  + - fix for bug
>             | /
>  Bug commit +
>             |
> 
> A bisect will still be testing lots of stuff without that fix. And if it
> goes into the branch with the fix, we just brought the kernel way back
> in time from point A. Then if it goes back to point B, then we zoom back
> to the future and bounce the kernel all over the place.
> 
> I see no gain for having a fixed based off of the bug that it fixes.

I suppose you'd test the intermediate ("bad") area by merging in "fix
for bug" instead of cherry-picking it.  In theory perhaps that would
give the bisect algorithm a little more information.  (Since it's seeing
the same "fix for bug" commit each time.)

> Pros of doing this:
> 
> 1) documents the point that things broke (can be done by commenting it
> in the change log too)
> 
> 2) probably good for back porting (but Con 3 may out weigh this)
> 
> Cons:
> 
> 1) Adds many more branches and merges for no real good reason
> 
> 2) Makes bisects even less linear than it already is
> 
> 3) May cause more conflicts at the merge point as the broken code may
> have changed.
> 
> 
> 
> Who will be doing the conflict resolutions? Linus? I doubt he would be
> happy with that, but he can speak for himself.

No real change there: you still won't want to send in a pull request
every time you fix a bug, so you'd pull a bunch together, merge them
(and maybe a test merge with upstream to make sure it's reasonable),
then send a pull request for the result.

I dunno, I have no strong opinions here, just curiosity.

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