aboutsummaryrefslogtreecommitdiffstats
path: root/config/kernel-shrink.m4
diff options
context:
space:
mode:
authorBrian Behlendorf <[email protected]>2013-07-15 13:37:51 -0700
committerBrian Behlendorf <[email protected]>2013-07-17 09:28:06 -0700
commitdba1d705669cf0e33091622d0e950b9459b20e2e (patch)
treed2d4bc38cf534c04dc38ea1e8cc292d22fdb825d /config/kernel-shrink.m4
parentc9ada6d5a00ba66fd54d62b4a1684e561fe2c9a4 (diff)
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 <[email protected]> Closes #1045 Closes #861 Closes #790
Diffstat (limited to 'config/kernel-shrink.m4')
-rw-r--r--config/kernel-shrink.m439
1 files changed, 39 insertions, 0 deletions
diff --git a/config/kernel-shrink.m4 b/config/kernel-shrink.m4
index 479fb3a6e..1c211ed15 100644
--- a/config/kernel-shrink.m4
+++ b/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([