MOD_INC_USE_COUNT

MOD_INC_USE_COUNT

[Tony]

Hello All,
Usually, when a net_device->open is called, it will MOD_INC_USE_COUNT on 
success. It is removed since 2.5.x, then should I increase the use 
count? how? thx.

Re: MOD_INC_USE_COUNT

[linux-os (Dick Johnson)]

On Thu, 10 Nov 2005, Tony wrote:

> Hello All,
> Usually, when a net_device->open is called, it will MOD_INC_USE_COUNT on
> success. It is removed since 2.5.x, then should I increase the use
> count? how? thx.

Gone! Don't use INC or DEC_USE_COUNT anymore. The kernel takes
care of that for you. Also, the count shown in `lsmod` no longer
means anything you can use programmaticly.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: MOD_INC_USE_COUNT

[Tony]

linux-os (Dick Johnson) wrote:
> On Thu, 10 Nov 2005, Tony wrote:
> 
> 
>>Hello All,
>>Usually, when a net_device->open is called, it will MOD_INC_USE_COUNT on
>>success. It is removed since 2.5.x, then should I increase the use
>>count? how? thx.
> 
> 
> Gone! Don't use INC or DEC_USE_COUNT anymore. The kernel takes
> care of that for you. Also, the count shown in `lsmod` no longer
> means anything you can use programmaticly.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
> 
> ****************************************************************
> The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
> 
> Thank you.
> 
But when the module is used by a net_device(interface is up), rmmod also 
works. Strange, isn't it?

Re: MOD_INC_USE_COUNT

[linux-os (Dick Johnson)]

On Thu, 10 Nov 2005, Tony wrote:

> linux-os (Dick Johnson) wrote:
>> On Thu, 10 Nov 2005, Tony wrote:
>>
>>
>>> Hello All,
>>> Usually, when a net_device->open is called, it will MOD_INC_USE_COUNT on
>>> success. It is removed since 2.5.x, then should I increase the use
>>> count? how? thx.
>>
>>
>> Gone! Don't use INC or DEC_USE_COUNT anymore. The kernel takes
>> care of that for you. Also, the count shown in `lsmod` no longer
>> means anything you can use programmaticly.
>>
>> Cheers,
>> Dick Johnson
>> Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
>> Warning : 98.36% of all statistics are fiction.
>>
>>
> But when the module is used by a net_device(interface is up), rmmod also
> works. Strange, isn't it?

Yes, it does something unexpected, i.e., violates the tenant of
least surprise. It shuts down the network interface, doesn't even
log the event. It just __does__ it!  At least M$ would put the
information in the "event viewer".
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: MOD_INC_USE_COUNT

[Ralf Baechle]

On Thu, Nov 10, 2005 at 10:21:26PM +0800, Tony wrote:

> But when the module is used by a net_device(interface is up), rmmod also 
> works. Strange, isn't it?

Not strange at all.  The typical network driver is implemented using
pci_register_driver which will set the owner filed of the driver's struct
driver which then is being used for internal reference counting.  Other
busses or line disciplines (SLIP, PPP, AX.25 ...) need to do the equivalent
or the kernel will believe reference counting isn't necessary and it's
ok to unload the module at any time.

In which driver did you hit this problem?

  Ralf

Re: MOD_INC_USE_COUNT

[Tony]

Ralf Baechle wrote:
> On Thu, Nov 10, 2005 at 10:21:26PM +0800, Tony wrote:
> 
> 
>>But when the module is used by a net_device(interface is up), rmmod also 
>>works. Strange, isn't it?
> 
> 
> Not strange at all.  The typical network driver is implemented using
> pci_register_driver which will set the owner filed of the driver's struct
> driver which then is being used for internal reference counting.  Other
> busses or line disciplines (SLIP, PPP, AX.25 ...) need to do the equivalent
> or the kernel will believe reference counting isn't necessary and it's
> ok to unload the module at any time.
> 
> In which driver did you hit this problem?
> 
>   Ralf
> 
I have a radio connected to host using ethernet. I'm writing a radio 
driver that masquerade radio as a NIC. when the module is loaded, I just 
register_netdev a net_device struct, while unregister_netdev at module 
cleanup.

Tony

Re: MOD_INC_USE_COUNT

[Ralf Baechle]

On Tue, Nov 15, 2005 at 11:56:33AM +0800, Tony wrote:

> >Not strange at all.  The typical network driver is implemented using
> >pci_register_driver which will set the owner filed of the driver's struct
> >driver which then is being used for internal reference counting.  Other
> >busses or line disciplines (SLIP, PPP, AX.25 ...) need to do the equivalent
> >or the kernel will believe reference counting isn't necessary and it's
> >ok to unload the module at any time.
> >
> >In which driver did you hit this problem?
> >
> >  Ralf
> >
> I have a radio connected to host using ethernet. I'm writing a radio 
> driver that masquerade radio as a NIC. when the module is loaded, I just 
> register_netdev a net_device struct, while unregister_netdev at module 
> cleanup.

register_netdev / unregister_netdev don't deal with the .owner stuff, so
your bug isn't there.  If your NIC is a PCI card, it should register it's
driver through pci_register_driver which would deal with the necessary
reference counting.  If it's implemented as a platform device you're
presumably calling driver_register() before platform_device_register() and
driver_register() would do the necessary magic for you.  If you're using a
different bus it may have it's own variant of driver_register which you
should call.  If you don't, you have a problem :-)

  Ralf

Re: MOD_INC_USE_COUNT

[Tony]

Ralf Baechle wrote:
> On Tue, Nov 15, 2005 at 11:56:33AM +0800, Tony wrote:
> 
> 
>>>Not strange at all.  The typical network driver is implemented using
>>>pci_register_driver which will set the owner filed of the driver's struct
>>>driver which then is being used for internal reference counting.  Other
>>>busses or line disciplines (SLIP, PPP, AX.25 ...) need to do the equivalent
>>>or the kernel will believe reference counting isn't necessary and it's
>>>ok to unload the module at any time.
>>>
>>>In which driver did you hit this problem?
>>>
>>> Ralf
>>>
>>
>>I have a radio connected to host using ethernet. I'm writing a radio 
>>driver that masquerade radio as a NIC. when the module is loaded, I just 
>>register_netdev a net_device struct, while unregister_netdev at module 
>>cleanup.
> 
> 
> register_netdev / unregister_netdev don't deal with the .owner stuff, so
> your bug isn't there.  If your NIC is a PCI card, it should register it's
> driver through pci_register_driver which would deal with the necessary
> reference counting.  If it's implemented as a platform device you're
> presumably calling driver_register() before platform_device_register() and
> driver_register() would do the necessary magic for you.  If you're using a
> different bus it may have it's own variant of driver_register which you
> should call.  If you don't, you have a problem :-)
> 
>   Ralf
> 
That is indeed my problem. My driver is none of types of drivers, it's 
just a software virtual one. I think I should mimic the way SLIP handle 
it. thank a loooooooot!!!

Tony

Re: MOD_INC_USE_COUNT

[Ralf Baechle]

On Wed, Nov 16, 2005 at 03:39:09PM +0800, Tony wrote:

> >>>Not strange at all.  The typical network driver is implemented using
> >>>pci_register_driver which will set the owner filed of the driver's struct
> >>>driver which then is being used for internal reference counting.  Other
> >>>busses or line disciplines (SLIP, PPP, AX.25 ...) need to do the 
> >>>equivalent
> >>>or the kernel will believe reference counting isn't necessary and it's
> >>>ok to unload the module at any time.
> >>>
> >>>In which driver did you hit this problem?
> >>>
> >>>Ralf
> >>>
> >>
> >>I have a radio connected to host using ethernet. I'm writing a radio 
> >>driver that masquerade radio as a NIC. when the module is loaded, I just 
> >>register_netdev a net_device struct, while unregister_netdev at module 
> >>cleanup.
> >
> >
> >register_netdev / unregister_netdev don't deal with the .owner stuff, so
> >your bug isn't there.  If your NIC is a PCI card, it should register it's
> >driver through pci_register_driver which would deal with the necessary
> >reference counting.  If it's implemented as a platform device you're
> >presumably calling driver_register() before platform_device_register() and
> >driver_register() would do the necessary magic for you.  If you're using a
> >different bus it may have it's own variant of driver_register which you
> >should call.  If you don't, you have a problem :-)
> >
> >  Ralf
> >
> That is indeed my problem. My driver is none of types of drivers, it's 
> just a software virtual one. I think I should mimic the way SLIP handle 
> it. thank a loooooooot!!!

SLIP is a line discipline; it's reference counting happens through
tty_register_ldisc() but probably your code isn't a line discipline ...
You however might use the platform device code - see
include/linux/platform_device.h and the many users throughout the kernel.
The platform device concept was really meant to support physical hardware
but it should work just fine in your case.  Maybe
drivers/net/mipsnet.c can serve as an example - it's a driver for virtual
NIC on a software emulator.

  Ralf

Re: MOD_INC_USE_COUNT

[Stephen Hemminger]

On Thu, 10 Nov 2005 21:14:29 +0800
Tony <tony.uestc@gmail.com> wrote:

> Hello All,
> Usually, when a net_device->open is called, it will MOD_INC_USE_COUNT on 
> success. It is removed since 2.5.x, then should I increase the use 
> count? how? thx.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Did you read Documentation/network/netdevices.txt?

Networking devices don't do ref counting because they should be removable
at any time! Because of hotplug and failover, it just doesn't work to keep
track of ref counting network devices. 

What happens is that each protocol is notified on module removal of a
network device. The protocol then cleans up all references to that
device. If the protocol is buggy, then you will see the kernel
wait and print a message that ref count is still not correct.


-- 
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger