-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
suspicious code in dsl_scan_ds_clone_swapped, related to sequential scan #9140
Comments
avg-I
added a commit
to avg-I/zfs
that referenced
this issue
Aug 14, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. This change should fix openzfs#9140. Signed-off-by: Andriy Gapon <avg@FreeBSD.org>
I believe that FreeBSD bug 239566 is the same issue. That crash happens when both |
I believe you are correct. We should probably just have separate if / else statements for each case. |
avg-I
added a commit
to avg-I/zfs
that referenced
this issue
Aug 26, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. This change should fix openzfs#9140. Signed-off-by: Andriy Gapon <avg@FreeBSD.org>
avg-I
added a commit
to avg-I/zfs
that referenced
this issue
Aug 29, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. This change should fix openzfs#9140. Signed-off-by: Andriy Gapon <avg@FreeBSD.org>
avg-I
added a commit
to avg-I/zfs
that referenced
this issue
Sep 4, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. This change should fix openzfs#9140. Signed-off-by: Andriy Gapon <avg@FreeBSD.org>
behlendorf
pushed a commit
that referenced
this issue
Sep 18, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes #9140 Closes #9163
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this issue
Sep 18, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes openzfs#9140 Closes openzfs#9163
ahrens
pushed a commit
to ahrens/zfs
that referenced
this issue
Sep 18, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes openzfs#9140 Closes openzfs#9163
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this issue
Sep 18, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes openzfs#9140 Closes openzfs#9163
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this issue
Sep 19, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes openzfs#9140 Closes openzfs#9163
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this issue
Sep 23, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes openzfs#9140 Closes openzfs#9163
tonyhutter
pushed a commit
that referenced
this issue
Sep 26, 2019
The was incorrect with respect to swapping dataset IDs both in the on-disk ZAP object and the in-memory queue. In both cases, if ds1 was already present, then it would be first replaced with ds2 and then ds would be replaced back with ds1. Also, both cases did not properly handle a situation where both ds1 and ds2 are already queued. A duplicate insertion would be attempted and its failure would result in a panic. Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: Tom Caputi <tcaputi@datto.com> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes #9140 Closes #9163
Hi all - just a follow up. This is not a theoretical issue. It happens without the fix. So thanks for taking care of it!
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry for not following the template.
This potential issue was found through a code review.
The code in question:
I see two potential problems.
If the first condition is true then the second condition will always be true as well.
That's because the first block replaces
ds1->ds_object
withds2->ds_object
in the queue.So, the second block will do a reverse replacement.
I feel that it is unlikely that that is the intended behavior.
Also, I think that it is possible that both
ds1->ds_object
andds2->ds_object
may already be on the queue. If that's the case, then the code will attempt to do a duplicate insertion.Maybe the code should first check if object IDs are on the queue and remember the results.
Then do necessary removals (if either ID is present, then both should be removed?).
And then do necessary insertions (insert the other ID for each originally present ID).
CC: @tcaputi @ahrens
The text was updated successfully, but these errors were encountered: