Re: [RFC] Is an alternative module interface needed/possible?

[Rusty Russell <rusty@rustcorp.com.au>]

In message <20030218142257.A10210@almesberger.net> you write:
> Next round: possible remedies and their side-effects. As
> usual, if you disagree with something, please holler.
> 
> If yes, let's look at possible (and not overly insane) solutions,
> using remove_proc_entry as a case study:
> 
> 1) still don't kfree, and leave it to the user to somehow
>    minimize the damage. (Good luck :-)
> 
> 2) add a callback that is invoked when the proc entry gets
>    deleted. (This callback may be called before remove_proc_entry
>    completes.) Problem: unload/return race for modules.

OK.  For reference, the "state of 2.4" solution (which is also the
"state of 2.5" solution) looks like:

> 	struct proc_dir_entry *de = create_proc_entry(...);
> 	void *my_data;
> 
> 	de->data = my_data = kmalloc(...);
=====>  de->owner = THIS_MODULE;
> 	...
> 	remove_proc_entry(...);
> 	/* what happens with "my_data", formerly known as "de->data" ? */

And have proc_file_operations do the standard owner get and release:

	open: proc_open,
	release: proc_release,

static int proc_open(struct inode *inode, struct file *filp)
{
	struct proc_dir_entry *dp = PDE(inode);
	if (!try_module_get(dp->owner))
		return -ENOENT;
	return 0;
}

static int proc_release(struct inode *inode, struct file *filp)
{
	struct proc_dir_entry *dp = PDE(inode);
	module_put(dp->owner);
	return 0;
}

Now, if remove_proc_entry() is called from module_exit(), the kfree()
works fine, since (1) we wouldn't be in module_exit() if the proc
entry was in used, and (2) the try_module_get() prevents any new
users.

Of course, if you wanted to remove the entry at any other time
(eg. hotplug), this doesn't help you one damn bit (which is kind of
your point).

> 3) change remove_proc_entry or add remove_proc_entry_wait that
>    works like remove_proc_entry, but blocks until the entry is
>    deleted. Problem: may sleep "forever".

This is what network devices do, and what the sockopt registration
code does, too, so this is already in the kernel, too.  It's not
great, but it becomes a noop for the module deregistration stuff.

Thanks!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.