--l76fUT7nc3MelDdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hiya Greg,

On Tue, Jan 03, 2006 at 02:43:39PM -0600, Greg Oster wrote:
> Reinoud Zandijk writes:
> is locking/unlocking bqueue_slock really needed here?  Isn't that 
> just for mucking with bufqueues[] and friends?  Also, are you allowed 
> to PR_WAITOK w/ bqueue_slock locked??  (I don't think so...)  If nothing 
> else, can the unlock and splx() be moved up to right after the 
> pool_get() ?  (i.e. only block things for as long as really necessary? )  
> 
> (sys/kern_physio.c:getphysbuf() seems to indicate that the 
> simple_lock/simple_unlock for pool_get(&bufpool,_) isn't needed.)

You are right... i think that was left from an earlier solution silly me. I 
used to claim a buffer normally until i decided that would kill off data 
unnessisarily!

 Thanks for pointing out!

> Again, I don't think you can PR_WAITOK w/ a lock held.  A LOCKDEBUG 
> kernel would have a fit :) 

i noticed before ;)

> > +	/* avoid confusion for softdep? */
> > +	LIST_INIT(&bp->b_dep);
> 
> Missing a:
> 
> 	simple_unlock(&bqueue_slock);
> 	splx(s);
> 
> here?  (or, preferably, right after the pool_get() if that would be 
> sufficient.

ARGH! shows i haven't executed the code O:-) My idea of delaying the splx 
is prolly paranoia to be sure all is set up correctly just in case an 
interrupt comes along.

Fixed the places, thanks :)

Reinoud

--l76fUT7nc3MelDdI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ7rxR4KcNwBDyKpoAQINWwf+KjQbxV7Cw3RJHthUVq9qRb/SfkD4yadh
zDYWemtk4PUiZHRZcYP7mRofdIMm+kKo2VNJytnaW0+l5gN0XD17HhcM8lzYAny/
U16EWUTzHUHlLxQXYcIPyOigxMHVgQ9J4R2DAONoilyVwtgsyH8gSuNGyGcuGYiB
Ncc2JbG6G6SevDUPIb5yIQPud1zwxdRUhH2esrVAe0+wSYb+nEeg3lu2yCPbr0pe
YmjWVac96L1MlHlq6/CFPQivZtyR2FSPMJD9Cn4gS1Orjk0NSdaV3PHE4mmWeldV
4Tfsv6kx5b46q+rZ/rRzGa/Q6H7piFNUVbNl8EXynQtnNB5g80dkDQ==
=Xsmc
-----END PGP SIGNATURE-----

--l76fUT7nc3MelDdI--