-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zfs_deadman_failmode = continue can panic in zfs_refcount_destroy_many #378
Comments
adjacent (non-boring) stacks
|
Applying openzfs#16216 and running through the test above, the ASSERT has not been triggered. The breakpoint at |
Woo commenting never fails!
So we are in fact tracking two problems in openzfs#15802
same thing where buffer:
size and rc_count both being 5120 is curious. |
I haven't looked what is that I/O, but it seems reasonable to me that if some ZIO haven't completed, its buffer is likely not freed. "failmode=continue" is a direct request for troubles. |
Yeah I assume the IO was scheduled, but not yet completed - the deadman triggers and the IO is restarted. It would seem this isn't done as easily as the code is. |
To trigger the bug referenced in #364 (comment) and probably also openzfs#15802
Will see message:
I can confirm that
https://github.com/openzfs/zfs/blob/master/module/zfs/zio.c#L2205-L2208
are called a few times, until eventually
https://github.com/openzfsonwindows/openzfs/blob/development/module/zfs/refcount.c#L98
With the stack:
However, note that
So we die in the VERIFY because
rc_count
is 5120, but when I inspectrc_count
it is now 0. Certainly feels like a race. I additionally had a breakpoint at:https://github.com/openzfsonwindows/openzfs/blob/development/module/zfs/zio.c#L2420
but it did not get triggered.
The text was updated successfully, but these errors were encountered: