Module reference count problem

• Next message: Tigran Aivazian: "Re: spin_lock_irq vs. spin_lock_irqsave."
• Previous message: Xuan Baldauf: "ipnatctl"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi folks,

I have a problem with making module unloading safe.

The scenario:
  i2c adapter module
  i2c client module
The modules do not depend on each other.
The adapter module can be removed, but all registered clients on it should
be deleted (an i2c client module can register one or more clients on each
connected adapter).
The i2c client module defines a /proc directory for each of its clients

Now imagine what happens if a user is standing in a /proc directory
belonging to the adapter module (but created by the client module),
and the adapter module is removed.
It calls the client module to unregister all its clients on that adapter.
This involves removing the /proc directory the user is standing in.
Instant oops.

Note that in the above scenario, we do not ask the client module to
be removed (only the adapter module), so the module usage count of
the client module is never considered by rmmod.

So, what needs to be done, is to increase the module usage counts of
*both* the client module and the adapter module when one of their
/proc directories is entered. And there lies the problem. It was easy
to do in 2.2 and early 2.3 kernels through the fill_inode trick. But
that was removed and replaced by the `owner' field - which can define
exactly one module owner and no more.

This seems to call for reintroducing the fill_inode stuff, or
alternatively, making the `owner' field a linked list.

Comments?

(yet another option would be to make the module unloading fail, but that
 seems not supported: once cleanup_module is called, the module *has*
 to cleanup, whatever happens. Right?)

Thanks,
  Frodo

-- 
Frodo Looijaard <frodol@dds.nl>  PGP key and more: http://huizen.dds.nl/~frodol
Defenestration n. (formal or joc.):
  The act of removing Windows from your computer in disgust, usually followed
  by the installation of Linux or some other Unix-like operating system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

• Next message: Tigran Aivazian: "Re: spin_lock_irq vs. spin_lock_irqsave."
• Previous message: Xuan Baldauf: "ipnatctl"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:22 EST