Fix arc_adapt() spinning in iterate_supers_type()
authorBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 15 Jul 2013 20:37:51 +0000 (13:37 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Wed, 17 Jul 2013 16:28:06 +0000 (09:28 -0700)
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
config/kernel.m4
module/zfs/zpl_super.c

index 479fb3a..1c211ed 100644 (file)
@@ -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([
index 46c0255..8742bc5 100644 (file)
@@ -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
index d4d4e1b..eee4a50 100644 (file)
@@ -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