Re: [Linux-ATM-General] atm driver refcounting?

[chas w. <ch...@cm...>]

In message <200...@ga...>,Mitchell Blank Jr writes:
>I still don't think the way its done is safe.  Just adding using
>module_{get,put}(THIS_MODULE) is still racy (but at least gets rid
>of the warning).  Really we need a registration API for ATM protocols.

actually the struct atm_dev now has a refcnt and atm_dev_lookup()
increments it (under a lock).  the module_put/module_get is just there
to keep people from unloading the driver while vcc's are open.   you
really dont need them anymore.  when the driver is unloaded it will
wait for refcnt to reach 1 (meaning the register function is the only
user).

>  http://www.sfgoth.com/~mitch/linux/atm/atm-proposal.txt
>Both pppoatm and br2684 are already basically prepared to use this
>system - the other protocols would need some compatibility glue to
>avoid having to require a tools upgrade.

i dont believe we would need to do this.  eventually, i will fix the 
sendmsg/recvmsg functions so that outstanding skb's keep a reference
to the vcc (via the sk) which will keep a reference to the driver.
the atm stack should be using skb_set_owner_w() and skb_set_owner_r()
but it currently doesnt since it doesnt skb_clone() when necessary.
this should keep vcc's from disappearing while then are in use by 
a particular skb.  i dont like pushing a null skb to close things
and i will think about that.  as for the ioctl backend interface, i
believe part of that problem will go away when netlink is used to the
userland to kernel communication.  this will need user space changes
of course, but in the long run is the 'right way' (or so i have been
told).

>We could add a .owner field to it and let the atm core do all of the
>refcounting that way.  Does that sound interesting to you?  I think I
>can throw a patch together.

i dont think the higher ups would accept something like this.  refcnt'ing
is the way to go.