linux-kernel - Re: current git kernel has strange problems during bisect

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:	Sun, 11 Jan 2009 17:27:01 -0500 (EST)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Christian Borntraeger <borntraeger@...ibm.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	Johannes Schindelin <Johannes.Schindelin@....de>,
	git@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: current git kernel has strange problems during bisect

On Sun, 11 Jan 2009, Christian Borntraeger wrote:

> Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:
> > Well, you don't actually have to mark that semi-random one as good either. 
> > What you can do is to just mark anything that _only_ contains fs/btrfs as 
> > good. IOW, you don't have to know the magic number - you just have to be 
> > told that "oh, if you only have btrfs files, and you're not actively 
> > bisecting a btrfs bug, just do 'git bisect good' and continue".
> 
> That should work.
> 
> <rant>
> Still, I am a bit frustrated. During this weekend I reported 2 regressions 
> (wlan and ata)  and I still try to find out why suspend/resume stopped 
> working. In the meantime I have identified 2 patches (one was already known, 
> I reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend 
> to ram regressions. In rc1 S2R was broken again. So I tried bisecting the 
> third patch - which finally brought me to the btrfs bisect problem.
> 
> For me, this was the most annoying  merge window ever.
> 
> In my opinion we should really avoid subtree merges in the future as a curtesy 
> to people who do the uncool work of testing, problem tracking and bisecting. 
> </rant>

I think hitting a version without the actual kernel source in it should 
actually make bisecting easier, not harder; you can say without even 
building the kernel that that version doesn't have the problem you're 
trying to find, because it doesn't have anything in it.

The alternative to having that part of the tree empty would be to stick in 
some kernel version there (probably 2.6.28), and then you'd build and test 
2.6.28 again, completely wasting a bunch of time.

Probably the bisect documentation or messages need to make it clear what 
you should do when you land on this sort of commit.

	-Daniel
*This .sig left intentionally blank*
--
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/