On Fri, Mar 25, 2016 at 11:55:31PM -0400, Mike Marshall wrote:
> I'll look to see if I can see it, I guess it has something to
> do with Al's superblock re-do...
It does; with this approach you would need to add ORANGEFS_VFS_OP_FS_UNMOUNT
to the whitelist in orangefs_devreq_read() - the
!(op->upcall.type ==
ORANGEFS_VFS_OP_FS_MOUNT ||
op->upcall.type ==
ORANGEFS_VFS_OP_GETATTR)) {
thing. Sorry, should've thought about that...
Alternatively, we could do orangefs_unmount_sb(sb) before removing from
the list, and add mutex_lock/mutex_unlock of request_mutex right before
that kfree() in the very end. Same effect in terms of list protection and
closer to your current logics.
Try this incremental (to be folded into "fix orangefs_superblock locking"):
diff --git a/fs/orangefs/super.c b/fs/orangefs/super.c
index bf78870..bb3dc14 100644
--- a/fs/orangefs/super.c
+++ b/fs/orangefs/super.c
@@ -514,6 +514,12 @@ void orangefs_kill_sb(struct super_block *sb)
/* provided sb cleanup */
kill_anon_super(sb);
+ /*
+ * issue the unmount to userspace to tell it to remove the
+ * dynamic mount info it has for this superblock
+ */
+ orangefs_unmount_sb(sb);
+
/* remove the sb from our list of orangefs specific sb's */
spin_lock(&orangefs_superblocks_lock);
@@ -522,10 +528,11 @@ void orangefs_kill_sb(struct super_block *sb)
spin_unlock(&orangefs_superblocks_lock);
/*
- * issue the unmount to userspace to tell it to remove the
- * dynamic mount info it has for this superblock
+ * make sure that ORANGEFS_DEV_REMOUNT_ALL loop that might've seen us
+ * gets completed before we free the damn thing.
*/
- orangefs_unmount_sb(sb);
+ mutex_lock(&request_mutex);
+ mutex_unlock(&request_mutex);
/* free the orangefs superblock private data */
kfree(ORANGEFS_SB(sb));
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
