Subject: Re: Pending entries support for fileassoc(9)
To: Brett Lymn <blymn@baesystems.com.au>
From: Elad Efrat <elad@bsd.org.il>
List: tech-kern
Date: 12/05/2007 13:07:36
This is a multi-part message in MIME format.
--------------010600010806010709090101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Brett Lymn wrote:
> On Tue, Dec 04, 2007 at 10:23:51PM +0000, Andrew Doran wrote:
>> - What is the concurrency strategy (e.g. locking)?
>>
> 
> Locking would be good here and, tagentially, in Veriexec too.
> 
>  1) Add a lock so we can lock the fileassoc_pending list for
>  read/write both when adding and when traversing in
>  fileassoc_mount_notify()

I added a mutex.

>  2) I have not looked closely but if it is not already locked, lock
>  the vnode of the mount point so that no other operations can happen
>  while resolving the pending fileassoc entries.

How related is that to the way we notify about the mount event?

Should the locking be done in fileassoc_mount_notify() itself, or the
caller?

> Also, it looks like there is a bit of a race/hole when adding entries,
> if the file system is already mounted and for some silly reason
> fileassoc_add_pending() is called with a filename on that mounted
> system then it will sit in the pending list forever - there probably
> should be a check to see if the filesystem is already mounted prior to
> adding the entry to the list.

I did not put in code to check whether the file already "exists" in
fileassoc_add_pending() on purpose. While I agree that in DIAGNOSTIC we
could perform this check, fileassoc(9) is a kernel interface, and its up
to the subsystem using it to use it properly; but of course, if you'll
insist... :)

See attached patch, also incorporating other suggestions from ad@.

Thanks,

-e.

--------------010600010806010709090101
Content-Type: text/plain;
 name="fileassoc_pending2.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="fileassoc_pending2.diff"

Index: kern/kern_fileassoc.c
===================================================================
RCS file: /usr/cvs/src/sys/kern/kern_fileassoc.c,v
retrieving revision 1.29
diff -u -p -r1.29 kern_fileassoc.c
--- kern/kern_fileassoc.c	15 May 2007 19:47:45 -0000	1.29
+++ kern/kern_fileassoc.c	5 Dec 2007 09:53:59 -0000
@@ -60,6 +60,7 @@ static struct fileassoc_table *fileassoc
 static specificdata_domain_t fileassoc_domain;
 static specificdata_key_t fileassoc_mountspecific_key;
 static ONCE_DECL(control);
+static kmutex_t pending_queue_mtx;
 
 /*
  * Hook entry.
@@ -92,6 +93,17 @@ struct fileassoc_table {
 	specificdata_reference data;
 };
 
+static TAILQ_HEAD(, fileassoc_pending_entry) fileassoc_pending =
+    TAILQ_HEAD_INITIALIZER(fileassoc_pending);
+
+struct fileassoc_pending_entry {
+	char *pe_filename;
+	size_t pe_filenamelen;
+	fileassoc_t pe_assoc;
+	void *pe_data;
+	TAILQ_ENTRY(fileassoc_pending_entry) pe_queue;
+};
+
 /*
  * Hashing function: Takes a number modulus the mask to give back an
  * index into the hash table.
@@ -184,6 +196,8 @@ fileassoc_init(void)
 	}
 	fileassoc_domain = specificdata_domain_create();
 
+	mutex_init(&pending_queue_mtx, MUTEX_DEFAULT, IPL_NONE);
+
 	return 0;
 }
 
@@ -586,3 +600,98 @@ fileassoc_clear(struct vnode *vp, fileas
 
 	return (0);
 }
+
+/*
+ * Add a pending entry.
+ *
+ * This routine allows a subsystem to create a pending fileassoc entry for a
+ * file that does not yet exist, ie., resides on a file-system that hasn't
+ * been mounted.
+ */
+int
+fileassoc_add_pending(const char *filename, fileassoc_t id, void *data)
+{
+	struct fileassoc_pending_entry *pe;
+	int error = 0;
+
+	/* Allocate and initialize a new entry. */
+	pe = kmem_alloc(sizeof(*pe), KM_SLEEP);
+	pe->pe_filenamelen = strlen(filename) + 1;
+	pe->pe_filename = kmem_alloc(pe->pe_filenamelen, KM_SLEEP);
+	if (strlcpy(pe->pe_filename, filename, pe->pe_filenamelen) >=
+	    pe->pe_filenamelen) {
+		error = ENAMETOOLONG;
+		goto out;
+	}
+	pe->pe_assoc = id;
+	pe->pe_data = data;
+
+	/* Add it to the pending queue. */
+	mutex_enter(&pending_queue_mtx);
+	TAILQ_INSERT_TAIL(&fileassoc_pending, pe, pe_queue);
+	mutex_exit(&pending_queue_mtx);
+
+ out:
+	if (error) {
+		kmem_free(pe->pe_filename, pe->pe_filenamelen);
+		kmem_free(pe, sizeof(*pe));
+	}
+
+	return (error);
+}
+
+/*
+ * This is a temporary wrapper until there's a better way to notify a new
+ * file-system was just mounted.
+ *
+ * Called whenever a file-system is mounted. Traverses the pending list,
+ * performing a lookup on each entry. Entries that are found are removed and
+ * added properly; otherwise they remain inside the pending queue.
+ */
+void
+fileassoc_mount_notify(struct mount *mp)
+{
+	struct fileassoc_pending_entry *pe;
+	const char *mountpoint = NULL;
+	size_t len = 0;
+
+	/*
+	 * XXX Should we hold a lock here to prevent new file-systems from
+	 * XXX being added while we traverse the list? (mountlist_lock)
+	 */
+
+	mountpoint = mp->mnt_stat.f_mntonname;
+	len = strlen(mountpoint);
+
+	mutex_enter(&pending_queue_mtx);
+
+	TAILQ_FOREACH(pe, &fileassoc_pending, pe_queue) {
+		struct nameidata nid;
+		int error;
+
+		/* Skip entries not on the file-system mounted. */
+		if (strncmp(mountpoint, pe->pe_filename, len) != 0) {
+			continue;
+		}
+
+		NDINIT(&nid, LOOKUP, FOLLOW, UIO_SYSSPACE, pe->pe_filename, curlwp);
+		error = namei(&nid);
+		if (error)
+			continue;
+
+		error = fileassoc_add(nid.ni_vp, pe->pe_assoc, pe->pe_data);
+		if (error) {
+			/*
+			 * XXX Errors here usually indicate memory shortage.
+			 */
+		} else {
+			kmem_free(pe->pe_filename, pe->pe_filenamelen);
+			kmem_free(pe, sizeof(*pe));
+			TAILQ_REMOVE(&fileassoc_pending, pe, pe_queue);
+		}
+
+		vrele(nid.ni_vp);
+	}
+
+	mutex_exit(&pending_queue_mtx);
+}
Index: kern/vfs_syscalls.c
===================================================================
RCS file: /usr/cvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.331
diff -u -p -r1.331 vfs_syscalls.c
--- kern/vfs_syscalls.c	24 Oct 2007 15:28:55 -0000	1.331
+++ kern/vfs_syscalls.c	2 Dec 2007 12:08:26 -0000
@@ -356,6 +356,9 @@ mount_domount(struct lwp *l, struct vnod
 	if (error)
 		vrele(vp);
 	*vpp = NULL;
+#ifdef FILEASSOC
+	fileassoc_mount_notify(mp);
+#endif /* FILEASSOC */
 	return error;
 }
 
Index: kern/init_main.c
===================================================================
RCS file: /usr/cvs/src/sys/kern/init_main.c,v
retrieving revision 1.330
diff -u -p -r1.330 init_main.c
--- kern/init_main.c	15 Nov 2007 20:12:04 -0000	1.330
+++ kern/init_main.c	2 Dec 2007 14:47:41 -0000
@@ -164,6 +164,9 @@ __KERNEL_RCSID(0, "$NetBSD: init_main.c,
 #include <sys/ktrace.h>
 #endif
 #include <sys/kauth.h>
+#ifdef FILEASSOC
+#include <sys/fileassoc.h>
+#endif /* FILEASSOC */
 #include <net80211/ieee80211_netbsd.h>
 
 #include <sys/syscall.h>
@@ -602,6 +605,8 @@ main(void)
 	VOP_UNLOCK(rootvnode, 0);
 	cwdi0.cwdi_rdir = NULL;
 
+	fileassoc_mount_notify(CIRCLEQ_FIRST(&mountlist));
+
 	/*
 	 * Now that root is mounted, we can fixup initproc's CWD
 	 * info.  All other processes are kthreads, which merely
Index: sys/fileassoc.h
===================================================================
RCS file: /usr/cvs/src/sys/sys/fileassoc.h,v
retrieving revision 1.11
diff -u -p -r1.11 fileassoc.h
--- sys/fileassoc.h	15 May 2007 19:47:44 -0000	1.11
+++ sys/fileassoc.h	2 Dec 2007 12:08:48 -0000
@@ -46,5 +46,9 @@ int fileassoc_file_delete(struct vnode *
 int fileassoc_add(struct vnode *, fileassoc_t, void *);
 int fileassoc_clear(struct vnode *, fileassoc_t);
 int fileassoc_table_run(struct mount *, fileassoc_t, fileassoc_cb_t, void *);
+int fileassoc_add_pending(const char *, fileassoc_t, void *);
+
+/* XXX elad - temporary. */
+void fileassoc_mount_notify(struct mount *);
 
 #endif /* !_SYS_FILEASSOC_H_ */

--------------010600010806010709090101--