[ENBD] /proc/nbdinfo

[Julien Rennard]

On Wed, 2004-01-07 at 17:53, Peter T. Breuer wrote:
> "Also sprach Peter T. Breuer:"
> > There are some race conditions leading up to the destroy, btw.
> 
> I might add that there is no obvious way to get rid of them completely.
> I can see why I did not insert that code myself.
> 
> The main problem is that when we do kfree(lo), there may still be other
> processes executing a spinlock wait on &lo->meta_lock, for example.
> They will be threads who are hoping to talk to the device but haven't
> yet got in there, being locked out by our occupation of all the
> device-specific locks. 
> 
> They'll get very ill if the spinlock they are spinning on is returned
> to the kernel heap!
> 
> This will happen if you try and open the device just after having sent
> the "reset" order, for example.
> 
> The best I can do is take the driver semaphore, look at the reference
> counter under write lock (must be zero), vamoosh the device, then
> release the driver semaphore.
> 
> I really would feel better if you would perhaps just do something like
> 
> 
>         
>         write_lock(&lo->meta_lock);
>         if (atomic_read(&lo->refcnt) > 0) {
>              write_unlock(&lo->meta_lock);
>              return;
>         }
> 
>         lo->nslot = 0;
>         atomic_set(&lo->flags, 0)
>         write_unlock(&lo->meta_lock);
Great !
this version "work" too I'll use it as it's more secure.
Thank you !
Is there still reason to not had this function in a new release ?
(I hope this is not useful only for myself :-) )
> and see how that goes. I suspect it will make things LOOK the way you
> want them to look. If not quite, we can get there in a couple more
> iterations. 
I think I'll have problems with the device number limitation but for now
I want to see if I can use enbd the same way to "export" Cdrom drive ! 
> Peter
> 
> 
> _______________________________________________
> ENBD mailing list
> ENBD at lists.community.tummy.com
> http://lists.community.tummy.com/mailman/listinfo/enbd
>