RCU stall in arc_adapt (zpl_prune_sbs) during umount #861
Milestone
Comments
|
From the stack trace, it seems to be a deadlock on Maybe something within the code path of If I come across the issue again I'll try to get the stack traces of umount-related tasks to see if there's something interesting. |
|
Your probably right about it racing with the umount in some unfortunate way. That's one of the few operations which is going to touch the |
|
I got it again. Same situation as in the issue description. Here's the detailed information: I also kept the result of SysRq T (stack traces for all tasks) in case that's not enough. |
|
I have most likely ran into the the same issue as this one; unable to export, not even with -f. |
|
@martinhelmer Thanks for the comment but I think we've got what we need. It just needs someone with time to work on it. |
behlendorf
added a commit
to behlendorf/zfs
that referenced
this issue
Jul 16, 2013
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. 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> Issue openzfs#1045 Issue openzfs#861 Issue openzfs#790
unya
pushed a commit
to unya/zfs
that referenced
this issue
Dec 13, 2013
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 openzfs#1045 Closes openzfs#861 Closes openzfs#790
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using latest zfs master, on a dual-core machine with 6 GB memory and
vm.min_free_kbytes = 32768, while exporting a pool with some ZVOLs in it,zfs umountfroze and I got this:The rest of the system still works fine, but the message repeats itself continuously and ZFS stays blocked. I had to do a hard reset. What's surprising is that I was stress-testing the pool with 48 benchmarks running on top of 6 zvols continuously for 20 hours and it handled it just fine, it just wouldn't umount after that. I find this kinda ironic.
I only got this once, so I have no idea how to reproduce it. I hope the stack trace will be enough to pinpoint the cause.
The text was updated successfully, but these errors were encountered: