[U-Boot] Hash problem...

[Peter Barada]

I've stumbled across a problem in U-boot 2010.12's hashing algorithm.

In my particular case the size of the has table is 347 (due to my 
default environment being 2258 bytes long as reported on entry to 
himport_r), and I have in my envrironment the variable "ramdiskimage" as 
well as "preboot"; part of my startup is to do some housecleaning then 
delete preboot so its only done once.  But when I load u-boot with an 
empty environemnt environment, I see the following problem:

...
=> printenv
....
ramdiskimage=rootfs.ext2.gz.uboot
....
=> echo $ramdiskimage

=> setenv ramdiskimage=rootfs.ext2.gz.uboot
=> printenv
...
ramdiskimage=rootfs.ext2.gz.uboot
ramdiskimage=rootfs.ext2.gz.uboot
...

After spending an entire day digging into the hash using GDB/BDI on my 
ARM board, I've findally figured out that the hash key of "ramdiskimage" 
and "preboot" are the same modulus 347, and this is problematic because 
on the initial hash import, preboot is placed into the hash first (at 
idx 190 since the table is sorted), and then ramdiskimage collides with 
preboot causing the 2nd probe (at idx 191) to occur which works fine.  
Unfortunately as part of the housecleaning, preboot is deleted and the 
environemnt saved.  The delete of preboot removes entry at idx 190 and 
the next lookup of ramdiskimage sees that idx 190 is empty and believes 
that the ramdiskimage is not in the table ionstead of rehashing to find 
it at idx 191.

The hash delete code is in error; instead of just removing the deleted 
key, it should instead allocate a new hashtable, hash all the keys into 
the new table except for the deleted key and then reclaim the old table 
(and deleted key).

-- 
Peter Barada
peter.barada at logicpd.com