From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: root@chaos.analogic.com
Cc: Brian Gerst <bgerst@didntduck.org>,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Module open() problems, Linux 2.4.0
Date: Thu, 09 Nov 2000 15:27:16 -0500 [thread overview]
Message-ID: <3A0B08A4.38A37F1F@mandrakesoft.com> (raw)
In-Reply-To: <Pine.LNX.3.95.1001109150621.15404A-100000@chaos.analogic.com>
"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 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-09 20:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-09 19:00 Module open() problems, Linux 2.4.0 Richard B. Johnson
2000-11-09 19:27 ` Brian Gerst
2000-11-09 20:12 ` Richard B. Johnson
2000-11-09 20:22 ` Christoph Hellwig
2000-11-09 20:27 ` Jeff Garzik [this message]
2000-11-09 20:57 ` Richard B. Johnson
2000-11-09 21:02 ` Jeff Garzik
2000-11-09 21:05 ` Christoph Hellwig
2000-11-10 0:01 ` Olaf Titz
2000-11-09 20:27 ` Brian Gerst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A0B08A4.38A37F1F@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=bgerst@didntduck.org \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.