BK problem

BK problem

[Larry McVoy]

Hi, we've got a problem in one of Linus' trees and it has started to
propagate around.  I need your help to track it down and fix it.
Please run the following script on your Linux BK trees and contact
me if it tells you to do so.  You can fix up the tree by doing the
following (warning: takes lots and lots of CPU time so if you don't
need the tree it may well be faster to reclone tomorrow after I finish
fixing the trees on bkbits).

cp SCCS/s.ChangeSet .		# save it just in case
bk checksum -vf ChangeSet	# takes ~15 minutes on 1Ghz K7

The set of trees which I know are bad on bkbits are:

    gkernel/main
    linus/linux-2.5
    linux-isdn/linux-2.5.export
    linuxvm/linus-2.5
    ppc/for-linus-ppc64

Here's the script, the usage is

	sh SH list of roots of the trees

------------ cut here and store in SH ------------------
#!/bin/sh

test -z "$1" && {
	echo "Usage: $0 repo [repo repo...]"
	exit 0
}
ID="torvalds@athlon.transmeta.com|ChangeSet|20020205173056|16047|c1d11a41ed024864"
HERE=`pwd`
for tree in "$@"
do	cd $HERE
	test -f $tree/SCCS/s.ChangeSet || continue
	cd $tree
	test "`bk identity`" = "$ID" || {
		# echo Skipping $tree because ID does not match
		continue
	}
	for i in 20020507175820 20020507172730 20020507171942 \
		20020507171816 20020507165445
	do	bk findkey -t$i ChangeSet
	done | bk prs -hnd:KEY: - | bk _keysort > /tmp/k$$
	test -s /tmp/k$$ || {
		echo $tree is OK, does not have the bad keys
		rm /tmp/k$$
		continue
	}
	cmp -s /tmp/k$$ - <<EOF
greg@kroah.com|ChangeSet|20020507171816|03715
greg@kroah.com|ChangeSet|20020507171942|33284
greg@kroah.com|ChangeSet|20020507175820|37065
ink@jurassic.park.msu.ru|ChangeSet|20020507165445|24759
mochel@segfault.osdl.org|ChangeSet|20020507172730|37035
EOF
	test $? -eq 0 || {
		echo =========================================================
		echo $tree needs fixing, contact lm@bitmover.com
		echo =========================================================
		rm /tmp/k$$
		continue
	}
	echo $tree is fine, it has the fixed keys
	rm /tmp/k$$
done

Re: BK problem

[Eli Carter]

Larry McVoy wrote:
> Hi, we've got a problem in one of Linus' trees and it has started to
> propagate around.  I need your help to track it down and fix it.
> Please run the following script on your Linux BK trees and contact
> me if it tells you to do so.  You can fix up the tree by doing the
> following (warning: takes lots and lots of CPU time so if you don't
> need the tree it may well be faster to reclone tomorrow after I finish
> fixing the trees on bkbits).

Would you mind giving something of a lay-man's explanation of what went 
wrong and what that means?  In particular, I'm curious about the 
propagating part...

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: BK problem

[Larry McVoy]

On Fri, May 10, 2002 at 12:58:12PM -0500, Eli Carter wrote:
> Larry McVoy wrote:
> > Hi, we've got a problem in one of Linus' trees and it has started to
> > propagate around.  I need your help to track it down and fix it.
> > Please run the following script on your Linux BK trees and contact
> > me if it tells you to do so.  You can fix up the tree by doing the
> > following (warning: takes lots and lots of CPU time so if you don't
> > need the tree it may well be faster to reclone tomorrow after I finish
> > fixing the trees on bkbits).
> 
> Would you mind giving something of a lay-man's explanation of what went 
> wrong and what that means?  In particular, I'm curious about the 
> propagating part...

The short summary is that two people used Linus' import tools and because
of no error on his part, simply the way things worked out, that caused what
we call "duplicate keys" (a lot like duplicate inodes, a lot like it) when
the trees with the imported patch came together.  I wrote a script to fix
up the trees after the fact and the application of that script went wrong
in Linus' tree but was not noticed until later.  It started showing up as
pull errors and then we tracked it down.

The long explanation would take me too long to do in email, I have 
carpal problems and it would amount to writing a "how BK works" paper
and that's too much for me right now.  If you want to understand the
nitty gritty, we can go to voice and I'll tell you.  So far, talking
doesn't seem to hurt my wrists :)
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK problem

[Larry McVoy]

> The set of trees which I know are bad on bkbits are:
> 
>     gkernel/main
>     linus/linux-2.5
>     linux-isdn/linux-2.5.export
>     linuxvm/linus-2.5
>     ppc/for-linus-ppc64

These are all fine now.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm