Fix arc_adapt() spinning in iterate_supers_type()

The iterate_supers_type() function which was introduced in the
3.0 kernel was supposed to provide a safe way to call an arbitrary
function on all super blocks of a specific type.  Unfortunately,
because a list_head was used a bug was introduced which made it
possible for iterate_supers_type() to get stuck spinning on a
super block which was just deactivated.

This can occur because when the list head is removed from the
fs_supers list it is reinitialized to point to itself.  If the
iterate_supers_type() function happened to be processing the
removed list_head it will get stuck spinning on that list_head.

The bug was fixed in the 3.3 kernel by converting the list_head
to an hlist_node.  However, to resolve the issue for existing
3.0 - 3.2 kernels we detect when a list_head is used.  Then to
prevent the spinning from occurring the .next pointer is set to
the fs_supers list_head which ensures the iterate_supers_type()
function will always terminate.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1045
Closes #861
Closes #790

config/kernel-shrink.m4

@@ -28,6 +28,45 @@ AC_DEFUN([ZFS_AC_KERNEL_SHRINK], [
 	])
 ])
 
+dnl #
+dnl # 3.3 API change
+dnl # The super_block structure was changed to use an hlist_node instead
+dnl # of a list_head for the .s_instance linkage.
+dnl #
+dnl # This was done in part to resolve a race in the iterate_supers_type()
+dnl # function which was introduced in Linux 3.0 kernel.  The iterator
+dnl # was supposed to provide a safe way to call an arbitrary function on
+dnl # all super blocks of a specific type.  Unfortunately, because a
+dnl # list_head was used it was possible for iterate_supers_type() to
+dnl # get stuck spinning a super block which was just deactivated.
+dnl #
+dnl # This can occur because when the list head is removed from the
+dnl # fs_supers list it is reinitialized to point to itself.  If the
+dnl # iterate_supers_type() function happened to be processing the
+dnl # removed list_head it will get stuck spinning on that list_head.
+dnl #
+dnl # To resolve the issue for existing 3.0 - 3.2 kernels we detect when
+dnl # a list_head is used.  Then to prevent the spinning from occurring
+dnl # the .next pointer is set to the fs_supers list_head which ensures
+dnl # the iterate_supers_type() function will always terminate.
+dnl #
+AC_DEFUN([ZFS_AC_KERNEL_S_INSTANCES_LIST_HEAD], [
+	AC_MSG_CHECKING([whether super_block has s_instances list_head])
+	ZFS_LINUX_TRY_COMPILE([
+		#include <linux/fs.h>
+	],[
+		struct super_block sb __attribute__ ((unused));
+
+		INIT_LIST_HEAD(&sb.s_instances);
+	],[
+		AC_MSG_RESULT(yes)
+		AC_DEFINE(HAVE_S_INSTANCES_LIST_HEAD, 1,
+		    [struct super_block has s_instances list_head])
+	],[
+		AC_MSG_RESULT(no)
+	])
+])
+
 AC_DEFUN([ZFS_AC_KERNEL_NR_CACHED_OBJECTS], [
 	AC_MSG_CHECKING([whether sops->nr_cached_objects() exists])
 	ZFS_LINUX_TRY_COMPILE([

config/kernel.m4

@@ -72,6 +72,7 @@ AC_DEFUN([ZFS_AC_CONFIG_KERNEL], [
 	ZFS_AC_KERNEL_CALLBACK_SECURITY_INODE_INIT_SECURITY
 	ZFS_AC_KERNEL_MOUNT_NODEV
 	ZFS_AC_KERNEL_SHRINK
+	ZFS_AC_KERNEL_S_INSTANCES_LIST_HEAD
 	ZFS_AC_KERNEL_S_D_OP
 	ZFS_AC_KERNEL_BDI
 	ZFS_AC_KERNEL_BDI_SETUP_AND_REGISTER

module/zfs/zpl_super.c

@@ -240,6 +240,10 @@ zpl_kill_sb(struct super_block *sb)
 {
 	zfs_preumount(sb);
 	kill_anon_super(sb);
+
+#ifdef HAVE_S_INSTANCES_LIST_HEAD
+	sb->s_instances.next = &(zpl_fs_type.fs_supers);
+#endif /* HAVE_S_INSTANCES_LIST_HEAD */
 }
 
 #ifdef HAVE_SHRINK