Skip to contentSkip to conversation

BK problem

DISCUSSION Larry McVoy 2 participants 4 messages May 10, 2002

lore
Share & tools
lore
#0 lore raw

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="[email protected]|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
[email protected]|ChangeSet|20020507171816|03715
[email protected]|ChangeSet|20020507171942|33284
[email protected]|ChangeSet|20020507175820|37065
[email protected]|ChangeSet|20020507165445|24759
[email protected]|ChangeSet|20020507172730|37035
EOF
	test $? -eq 0 || {
		echo =========================================================
		echo $tree needs fixing, contact [email protected]
		echo =========================================================
		rm /tmp/k$$
		continue
	}
	echo $tree is fine, it has the fixed keys
	rm /tmp/k$$

done

#1 lore raw
Quoted 7 lines · 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).

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 `-------------------------------------------------

#2 lore raw
In reply to Larry McVoy
Quoted 9 lines · Eli Carter
Quoted 7 lines · 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).

Quoted 3 lines

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 :)

Signature · 2 lines
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
#3 lore raw
In reply to Larry McVoy
Quoted 7 lines

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.

Signature · 2 lines
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm