`lsmod` shows that a device is open twice when using Linux-2.4.0-test9
when, in fact, it has been opened only once.
lsmod is version 2.3.15, the latest-and-greatest.
Here are the open/close routines for a module.
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
* Open the device.
*/
static int device_open(struct inode *inp, struct file *fp)
{
DEB(printk("%s open\n", info->dev));
MOD_INC_USE_COUNT; /* Increment usage count */
return 0;
}
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
* Close the device.
*/
static int device_close(struct inode *inp, struct file *fp)
{
DEB(printk("%s close\n", info->dev));
MOD_DEC_USE_COUNT; /* Decrement usage count */
return 0;
}
When the module is closed, the use-count goes to zero as expected.
However, a single open() causes the use-count to be 2.
In a possibly-related observation, during the change-root from
an initial RAM disk to the root file system during boot, the
d_count used to be reported as '1'. It is now '3'.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"Richard B. Johnson" wrote:
>
> `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> when, in fact, it has been opened only once.
>
> lsmod is version 2.3.15, the latest-and-greatest.
>
> Here are the open/close routines for a module.
>
> /*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
> /*
> * Open the device.
> */
> static int device_open(struct inode *inp, struct file *fp)
> {
> DEB(printk("%s open\n", info->dev));
> MOD_INC_USE_COUNT; /* Increment usage count */
> return 0;
> }
> /*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
> /*
> * Close the device.
> */
> static int device_close(struct inode *inp, struct file *fp)
> {
> DEB(printk("%s close\n", info->dev));
> MOD_DEC_USE_COUNT; /* Decrement usage count */
> return 0;
> }
>
> When the module is closed, the use-count goes to zero as expected.
> However, a single open() causes the use-count to be 2.
This is harmless. It is caused by a try_inc_mod_count(module) in the
function calling device_open(), which is the proper way for module
locking to be handled when not holding the BKL. You can keep the
MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
--
Brian Gerst
On Thu, 9 Nov 2000, Brian Gerst wrote:
> "Richard B. Johnson" wrote:
> >
> > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> > when, in fact, it has been opened only once.
> >
> >
> > When the module is closed, the use-count goes to zero as expected.
> > However, a single open() causes the use-count to be 2.
>
> This is harmless. It is caused by a try_inc_mod_count(module) in the
> function calling device_open(), which is the proper way for module
> locking to be handled when not holding the BKL. You can keep the
> MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
>
> Brian Gerst
This may be, as you say, "harmless". It is, however, a bug. The
reporting must be correct or large complex systems can't be
developed or maintained.
I had two persons, working nearly a week, trying to find out
what one of over 200 processes had a device open when only
one was supposed to have it opened. --Err we have to check
our work here. The fact that something "works" is not
sufficient.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
In article <[email protected]> you wrote:
> This may be, as you say, "harmless". It is, however, a bug. The
> reporting must be correct or large complex systems can't be
> developed or maintained.
No. It is not. The module usage count doesn't have a direct relation
to the number of open devices. The module count just makes the modules
un-removable if it is non-zero. It doesn't matter at all, when and where
you in- and decrease it, as long as the module is always protected against
unload when in use (e.g. opened).
Christoph
--
Always remember that you are unique. Just like everyone else.
"Richard B. Johnson" wrote:
>
> On Thu, 9 Nov 2000, Brian Gerst wrote:
>
> > "Richard B. Johnson" wrote:
> > >
> > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> > > when, in fact, it has been opened only once.
> > >
>
> > >
> > > When the module is closed, the use-count goes to zero as expected.
> > > However, a single open() causes the use-count to be 2.
> >
> > This is harmless. It is caused by a try_inc_mod_count(module) in the
> > function calling device_open(), which is the proper way for module
> > locking to be handled when not holding the BKL. You can keep the
> > MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
> >
> > Brian Gerst
>
> This may be, as you say, "harmless". It is, however, a bug. The
> reporting must be correct or large complex systems can't be
> developed or maintained.
>
> I had two persons, working nearly a week, trying to find out
> what one of over 200 processes had a device open when only
> one was supposed to have it opened. --Err we have to check
> our work here. The fact that something "works" is not
> sufficient.
There is NO guarantee that module use count == device open count. Never
has been, AFAIK. It just happens to work out that way on a lot of
pre-2.4 code.
The kernel is free to bump the module reference count up and down as it
pleases. For example, if a driver creates a kernel thread, that will
increase its module usage count by one, for the duration of the kernel
thread's lifetime.
The only rule is that you cannot unload a module until its use count it
zero.
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft |
"Richard B. Johnson" wrote:
>
> On Thu, 9 Nov 2000, Brian Gerst wrote:
>
> > "Richard B. Johnson" wrote:
> > >
> > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> > > when, in fact, it has been opened only once.
> > >
>
> > >
> > > When the module is closed, the use-count goes to zero as expected.
> > > However, a single open() causes the use-count to be 2.
> >
> > This is harmless. It is caused by a try_inc_mod_count(module) in the
> > function calling device_open(), which is the proper way for module
> > locking to be handled when not holding the BKL. You can keep the
> > MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
> >
> > Brian Gerst
>
> This may be, as you say, "harmless". It is, however, a bug. The
> reporting must be correct or large complex systems can't be
> developed or maintained.
>
> I had two persons, working nearly a week, trying to find out
> what one of over 200 processes had a device open when only
> one was supposed to have it opened. --Err we have to check
> our work here. The fact that something "works" is not
> sufficient.
It is not a bug. The only values that matter are zero and non-zero. As
long as the refcounting is symmetric, it all comes out in the wash.
Remove the MOD_{INC,DEC}_USE_COUNT from your driver if it bothers you
that much and you don't care about 2.2 compatability.
--
Brian Gerst
On Thu, 9 Nov 2000, Jeff Garzik wrote:
> "Richard B. Johnson" wrote:
> >
> > On Thu, 9 Nov 2000, Brian Gerst wrote:
> >
> > > "Richard B. Johnson" wrote:
> > > >
> > > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> > > > when, in fact, it has been opened only once.
> > > >
> >
> > > >
> > > > When the module is closed, the use-count goes to zero as expected.
> > > > However, a single open() causes the use-count to be 2.
> > >
> > > This is harmless. It is caused by a try_inc_mod_count(module) in the
> > > function calling device_open(), which is the proper way for module
> > > locking to be handled when not holding the BKL. You can keep the
> > > MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
> > >
> > > Brian Gerst
> >
> > This may be, as you say, "harmless". It is, however, a bug. The
> > reporting must be correct or large complex systems can't be
> > developed or maintained.
> >
> > I had two persons, working nearly a week, trying to find out
> > what one of over 200 processes had a device open when only
> > one was supposed to have it opened. --Err we have to check
> > our work here. The fact that something "works" is not
> > sufficient.
>
> There is NO guarantee that module use count == device open count. Never
> has been, AFAIK. It just happens to work out that way on a lot of
> pre-2.4 code.
>
> The kernel is free to bump the module reference count up and down as it
> pleases. For example, if a driver creates a kernel thread, that will
> increase its module usage count by one, for the duration of the kernel
> thread's lifetime.
>
> The only rule is that you cannot unload a module until its use count it
> zero.
>
> Jeff
>
I suppose. Look at what you just stated! This means that a reported
value is now worthless.
To restate, somebody decided that we didn't need this reported value
anymore. Therefore, it is okay to make it worthless.
I don't agree. The De-facto standard has been that the module usage
count is equal to the open count. This became the standard because
of a long established history.
This is one of the tools we use to verify that an entire system
is functioning properly. Now, somebody decided that I didn't need
this tool.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"Richard B. Johnson" wrote:
> I suppose. Look at what you just stated! This means that a reported
> value is now worthless.
>
> To restate, somebody decided that we didn't need this reported value
> anymore. Therefore, it is okay to make it worthless.
>
> I don't agree. The De-facto standard has been that the module usage
> count is equal to the open count. This became the standard because
> of a long established history.
>
> This is one of the tools we use to verify that an entire system
> is functioning properly. Now, somebody decided that I didn't need
> this tool.
You assumed the module count == device open count, when that was in fact
never the case. The 2.4.x kernel changes merely shattered false
assumptions you held on your part.
The kernel thread example I described in my last e-mail holds true for
kernel 2.2.x as well, maybe 2.0.x too.
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft |
In article <[email protected]> you wrote:
> On Thu, 9 Nov 2000, Jeff Garzik wrote:
>> There is NO guarantee that module use count == device open count. Never
>> has been, AFAIK. It just happens to work out that way on a lot of
>> pre-2.4 code.
>>
>> The kernel is free to bump the module reference count up and down as it
>> pleases. For example, if a driver creates a kernel thread, that will
>> increase its module usage count by one, for the duration of the kernel
>> thread's lifetime.
>>
>> The only rule is that you cannot unload a module until its use count it
>> zero.
>>
>> Jeff
>>
> I suppose. Look at what you just stated! This means that a reported
> value is now worthless.
Correct. And it was always worthless.
> To restate, somebody decided that we didn't need this reported value
> anymore. Therefore, it is okay to make it worthless.
It was always wothless besides == 0 means: you can unload me now.
> I don't agree. The De-facto standard has been that the module usage
> count is equal to the open count. This became the standard because
> of a long established history.
It's the same de-facto standard as bogo-mips ~= CPU MHz. It was so,
but it was neither intended nor documented so.
> This is one of the tools we use to verify that an entire system
> is functioning properly.
It was the wrong tool.
Christoph
--
Always remember that you are unique. Just like everyone else.
> > I suppose. Look at what you just stated! This means that a reported
> > value is now worthless.
>
> Correct. And it was always worthless.
Right. The module "use count" is not a use count, it's a lock count.
E.g. a driver may well increase this counter on open and then again
when in a particular ioctl routine, if this situation isn't already
locked right by the kernel. This can happen when a driver has more
than one access point from user space, look at slip_open() in slip.c
from 2.2.
> It's the same de-facto standard as bogo-mips ~= CPU MHz. It was so,
> but it was neither intended nor documented so.
Remember the Landmark Test and those silly CPU-speed displays
configured to show "Landmark MHz"? :-)
Olaf