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--