On Mon, 2008-12-01 at 16:00 -0500, Oren Laadan wrote:

Dave Hansen wrote:

quoted

On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:

quoted

quoted

quoted

quoted

+   fd = cr_attach_file(file);      /* no need to cleanup 'file' below */
+   if (fd < 0) {
+           filp_close(file, NULL);
+           ret = fd;
+           goto out;
+   }
+
+   /* register new <objref, file> tuple in hash table */
+   ret = cr_obj_add_ref(ctx, file, parent, CR_OBJ_FILE, 0);
+   if (ret < 0)
+           goto out;

Who said that file still exists at that point?

Correct. This call should move higher up befor ethe call to cr_attach_file()

Is that sufficient?  It seems like we're depending on the fd's reference
to the 'struct file' to keep it valid in the hash.  If something happens
to the fd (like the other thread messing with it) the 'struct file' can
still go away.

Shouldn't we do another get_file() for the hash's reference?

When a shared object is inserted to the hash we automatically take another
reference to it (according to its type) for as long as it remains in the
hash. See:  'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'.  So by moving that
call higher up, we protect the struct file.

We also need to document that we depend on this reference in the hash to
keep the object around.  Take a look at cr_read_fd_data().  Once that
cr_attach_file() has been performed, the only thing keeping the 'file'
around is the hash reference.  If someone happened to remove it from the
hash, the vfs_llseek() below would be bogus.

I don't know how we document that the hash is one-way: writes only and
no later deletions.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html