linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Zippel <zippel@linux-m68k.org>
To: Werner Almesberger <wa@almesberger.net>
Cc: Rusty Russell <rusty@rustcorp.com.au>, <kuznet@ms2.inr.ac.ru>,
	<kronos@kronoz.cjb.net>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Is an alternative module interface needed/possible?
Date: Wed, 19 Feb 2003 02:48:33 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.44.0302181516210.1336-100000@serv> (raw)
In-Reply-To: <20030217221837.Q2092@almesberger.net>

Hi,

On Mon, 17 Feb 2003, Werner Almesberger wrote:

> > failure: if the object is still busy, we just return -EBUSY. This is 
> > simple, but this doesn't work for modules, since during module exit you 
> > can't fail anymore.
> 
> That's a modules API problem. And yes, I think modules should
> eventually be able to say that they're busy.

As Rusty already correctly said, this is currently not possible with the 
current modules API. On the other hand he also jumps very quickly to 
conclusions, so let's look at all the options first and then decide how 
trivial they are.
Anyway, for now just keep this option in mind and let's look at the other
options, which don't require a module API change.

> By the way, a loong time ago, in the modules thread, I suggested
> a "decrement_module_count_and_return" function [1]. Such a
> construct would be useful in this specific case.

This would just be an optimization(?) for the module count, it doesn't 
change the general problem and is not useful as generic solution, so I'd 
rather put it back for now.

> > failure doesn't work with modules, so that only leaves the module count.
> 
> And how would you ensure correct access to static data in the
> absence of modules ? Any solution that _requires_ a module count
> looks highly suspicious to me.

In that case it would be kernel memory, which cannot be freed, so it will 
not go away and requires no module count.

> Likewise, possibly dynamically allocated data that is synchronized
> by the caller, e.g. "user" in "struct proc_dir_entry".

user?

> > The last solution sounds complicated, but exactly this is done for 
> > filesystems and we didn't really get rid of the second reference count, we 
> > just moved it somewhere else, where it hurts least.
> 
> Hmm, I'm confused. With "filesystem", do you mean the file system
> driver per se (e.g. "ext3"), or a specific instance of such a file
> system (e.g. /dev/hda1 mounted on /) ?

A generic file system as it's registered via register_filesystem. A file 
system exports lots of dynamic and static data and the only (used) module 
pointer you will find is in struct file_system_type (the owner pointer in 
struct file_operations is not used by any standard fs). It's interesting 
to see how file systems keep the module business at a minimum (no 
try_module_get() is still cheaper than the cheapest try_module_get()).

Um, it's getting late and I just played too much with procfs to find a 
sensible solution. Below is an experimental patch to add callback which 
would allow it to safely remove user data. Very lightly tested, so no 
guarantees.

bye, Roman

Index: include/linux/proc_fs.h
===================================================================
RCS file: /usr/src/cvsroot/linux-2.5/include/linux/proc_fs.h,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 proc_fs.h
--- include/linux/proc_fs.h	27 Aug 2002 23:38:02 -0000	1.1.1.9
+++ include/linux/proc_fs.h	19 Feb 2003 00:46:28 -0000
@@ -69,6 +69,7 @@ struct proc_dir_entry {
 	void *data;
 	read_proc_t *read_proc;
 	write_proc_t *write_proc;
+	void (*release_proc)(struct proc_dir_entry *);
 	atomic_t count;		/* use count */
 	int deleted;		/* delete flag */
 	kdev_t	rdev;
Index: fs/proc/generic.c
===================================================================
RCS file: /usr/src/cvsroot/linux-2.5/fs/proc/generic.c,v
retrieving revision 1.1.1.12
diff -u -p -r1.1.1.12 generic.c
--- fs/proc/generic.c	15 Feb 2003 01:25:07 -0000	1.1.1.12
+++ fs/proc/generic.c	19 Feb 2003 01:40:36 -0000
@@ -639,6 +639,8 @@ void free_proc_entry(struct proc_dir_ent
 	if (ino < PROC_DYNAMIC_FIRST ||
 	    ino >= PROC_DYNAMIC_FIRST+PROC_NDYNAMIC)
 		return;
+	if (de->release_proc)
+		de->release_proc(de);
 	if (S_ISLNK(de->mode) && de->data)
 		kfree(de->data);
 	kfree(de);
@@ -655,6 +657,7 @@ void remove_proc_entry(const char *name,
 	const char *fn = name;
 	int len;
 
+	lock_kernel();
 	if (!parent && xlate_proc_name(name, &parent, &fn) != 0)
 		goto out;
 	len = strlen(fn);
@@ -680,5 +683,6 @@ void remove_proc_entry(const char *name,
 		break;
 	}
 out:
+	unlock_kernel();
 	return;
 }
Index: fs/proc/inode.c
===================================================================
RCS file: /usr/src/cvsroot/linux-2.5/fs/proc/inode.c,v
retrieving revision 1.1.1.13
diff -u -p -r1.1.1.13 inode.c
--- fs/proc/inode.c	1 Feb 2003 19:59:21 -0000	1.1.1.13
+++ fs/proc/inode.c	19 Feb 2003 01:40:36 -0000
@@ -23,13 +23,6 @@
 
 extern void free_proc_entry(struct proc_dir_entry *);
 
-static inline struct proc_dir_entry * de_get(struct proc_dir_entry *de)
-{
-	if (de)
-		atomic_inc(&de->count);
-	return de;
-}
-
 /*
  * Decrements the use count and checks for deferred deletion.
  */
@@ -44,11 +37,13 @@ static void de_put(struct proc_dir_entry
 		}
 
 		if (atomic_dec_and_test(&de->count)) {
+			struct module *owner = de->owner;
 			if (de->deleted) {
 				printk("de_put: deferred delete of %s\n",
 					de->name);
 				free_proc_entry(de);
 			}
+			module_put(owner);
 		}		
 		unlock_kernel();
 	}
@@ -71,11 +66,8 @@ static void proc_delete_inode(struct ino
 
 	/* Let go of any associated proc directory entry */
 	de = PROC_I(inode)->pde;
-	if (de) {
-		if (de->owner)
-			module_put(de->owner);
+	if (de)
 		de_put(de);
-	}
 }
 
 struct vfsmount *proc_mnt;
@@ -178,44 +170,36 @@ struct inode * proc_get_inode(struct sup
 	/*
 	 * Increment the use count so the dir entry can't disappear.
 	 */
-	de_get(de);
-#if 1
-/* shouldn't ever happen */
-if (de && de->deleted)
-printk("proc_iget: using deleted entry %s, count=%d\n", de->name, atomic_read(&de->count));
-#endif
+	if (!atomic_read(&de->count) && !try_module_get(de->owner))
+		return NULL;
+	atomic_inc(&de->count);
 
 	inode = iget(sb, ino);
 	if (!inode)
 		goto out_fail;
-	
+
 	PROC_I(inode)->pde = de;
-	if (de) {
-		if (de->mode) {
-			inode->i_mode = de->mode;
-			inode->i_uid = de->uid;
-			inode->i_gid = de->gid;
-		}
-		if (de->size)
-			inode->i_size = de->size;
-		if (de->nlink)
-			inode->i_nlink = de->nlink;
-		if (!try_module_get(de->owner))
-			goto out_fail;
-		if (de->proc_iops)
-			inode->i_op = de->proc_iops;
-		if (de->proc_fops)
-			inode->i_fop = de->proc_fops;
-		else if (S_ISBLK(de->mode)||S_ISCHR(de->mode)||S_ISFIFO(de->mode))
-			init_special_inode(inode,de->mode,kdev_t_to_nr(de->rdev));
+	if (de->mode) {
+		inode->i_mode = de->mode;
+		inode->i_uid = de->uid;
+		inode->i_gid = de->gid;
 	}
+	if (de->size)
+		inode->i_size = de->size;
+	if (de->nlink)
+		inode->i_nlink = de->nlink;
+	if (de->proc_iops)
+		inode->i_op = de->proc_iops;
+	if (de->proc_fops)
+		inode->i_fop = de->proc_fops;
+	else if (S_ISBLK(de->mode)||S_ISCHR(de->mode)||S_ISFIFO(de->mode))
+		init_special_inode(inode,de->mode,kdev_t_to_nr(de->rdev));
 
-out:
 	return inode;
 
 out_fail:
 	de_put(de);
-	goto out;
+	return NULL;
 }			
 
 int proc_fill_super(struct super_block *s, void *data, int silent)


  parent reply	other threads:[~2003-02-19  1:40 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-02 22:50 [RFC] Migrating net/sched to new module interface Kronos
2003-01-03  5:10 ` Rusty Russell
2003-01-03  8:37   ` David S. Miller
2003-01-04  6:09     ` Rusty Russell
2003-01-04 16:21       ` Kronos
2003-01-13 22:32   ` kuznet
2003-01-13 23:23     ` Max Krasnyansky
2003-01-14 17:49     ` Kronos
2003-01-15  0:21       ` Roman Zippel
2003-01-15  1:19         ` kuznet
2003-01-15  7:31           ` Werner Almesberger
2003-01-15  8:16             ` Rusty Russell
2003-01-15  9:33               ` Werner Almesberger
2003-01-16  1:12                 ` Rusty Russell
2003-01-16  2:42                   ` Werner Almesberger
2003-01-16  3:31                     ` Rusty Russell
2003-01-16  4:20                       ` Werner Almesberger
2003-01-16  4:25                       ` David S. Miller
2003-01-16  4:49                         ` Werner Almesberger
2003-01-16 16:05                         ` Roman Zippel
2003-01-16 18:15                     ` Roman Zippel
2003-01-16 18:58                       ` Werner Almesberger
2003-01-16 23:53                         ` Roman Zippel
2003-01-17  1:04                           ` Greg KH
2003-01-17  2:27                     ` Rusty Russell
2003-01-17 21:40                       ` Roman Zippel
2003-02-13 23:16                       ` Werner Almesberger
2003-02-14  1:57                         ` Rusty Russell
2003-02-14  3:44                           ` Werner Almesberger
2003-02-14 11:16                           ` Roman Zippel
2003-02-14 12:04                             ` Rusty Russell
2003-02-14 12:49                               ` Roman Zippel
2003-02-17  1:59                                 ` Rusty Russell
2003-02-17 10:53                                   ` Roman Zippel
2003-02-17 23:31                                     ` Rusty Russell
2003-02-18 12:26                                       ` Roman Zippel
2003-02-14 13:21                               ` Roman Zippel
2003-02-14 13:53                                 ` Werner Almesberger
2003-02-14 14:24                                   ` Roman Zippel
2003-02-14 18:30                                     ` Werner Almesberger
2003-02-14 20:09                                       ` Roman Zippel
2003-02-15  0:12                                         ` Werner Almesberger
2003-02-15  0:51                                           ` Roman Zippel
2003-02-15  2:28                                             ` Werner Almesberger
2003-02-15 23:20                                               ` Roman Zippel
2003-02-17 17:04                                                 ` Werner Almesberger
2003-02-17 23:09                                                   ` [RFC] Is an alternative module interface needed/possible? Roman Zippel
2003-02-18  1:18                                                     ` Werner Almesberger
2003-02-18  4:54                                                       ` Rusty Russell
2003-02-18  7:20                                                         ` Werner Almesberger
2003-02-18 12:06                                                           ` Roman Zippel
2003-02-18 14:12                                                             ` Werner Almesberger
2003-02-18 12:45                                                               ` Thomas Molina
2003-02-18 17:22                                                               ` Werner Almesberger
2003-02-19  3:30                                                                 ` Rusty Russell
2003-02-19  4:11                                                                   ` Werner Almesberger
2003-02-19 23:38                                                                     ` Rusty Russell
2003-02-20  9:46                                                                       ` Roman Zippel
2003-02-20  0:40                                                                 ` Roman Zippel
2003-02-20  2:17                                                                   ` Werner Almesberger
2003-02-23 16:02                                                                     ` Roman Zippel
2003-02-26 23:26                                                                       ` Werner Almesberger
2003-02-27 12:34                                                                         ` Roman Zippel
2003-02-27 13:20                                                                           ` Werner Almesberger
2003-02-27 14:33                                                                             ` Roman Zippel
2003-02-23 23:34                                                                 ` Kevin O'Connor
2003-02-24 12:14                                                                   ` Roman Zippel
2003-02-18 12:35                                                           ` Roman Zippel
2003-02-18 14:14                                                             ` Werner Almesberger
2003-02-19  1:48                                                       ` Roman Zippel [this message]
2003-02-19  2:27                                                         ` Werner Almesberger
2003-01-16 13:44                   ` [RFC] Migrating net/sched to new module interface Roman Zippel
2003-01-15 17:04               ` Roman Zippel
2003-02-20 12:09 [RFC] Is an alternative module interface needed/possible? Adam J. Richter
2003-02-20 12:46 ` Roman Zippel
2003-02-20 13:51 Adam J. Richter
2003-02-20 14:06 ` Werner Almesberger
2003-02-20 15:38 ` Roman Zippel

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=Pine.LNX.4.44.0302181516210.1336-100000@serv \
    --to=zippel@linux-m68k.org \
    --cc=kronos@kronoz.cjb.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=wa@almesberger.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).