cbdata race conditions ?

Whilst looking at the diskd code I found a place where data
(in this case sio) was being cbdataUnlock'ed and then being used.

This is bad because cbdataUnlock can potentially free memory,
and in this case if a read was aborted and the cbdata wasn't valid,
memory was still being trampled on. It didn't cause a crash here,
but it potentially *could*.

I'm going to go through the diskd IO code soon and make sure that
there aren't any more "surprises" like this.

Now, I don't want to think about how many other places in the code
this possibly could exist, so I'm going to play dumb for the next
few days (after I commit this diskd patch, of course) because I'm
slightly overworked right now.

If someone comes up with a suitable patch against aufs which people
agree on, I'll test it here on my linux dev box and try it out,
and if it doesn't show signs of sudden death I'll commit it and
MFC it to SQUID_2_4 .

All credit to finding this bug can go to Andres. Whats your
postal address Andres, since I have some chocolate to send to you. :)

Adrian

-- 
Adrian Chadd			"God: Damn! I left pot everywhere!
<adrian@creative.net.au>	  Now I'll have to create Republicans!"
				    - Bill Hicks