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
Fix bug in list_hp_retire function #10
Conversation
@linD026, Please help review this proposed change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read https://cbea.ms/git-commit/ carefully. Then, write down informative commit message(s).
You should use |
In hp_list project's function : list_hp_retire, it attempts to reorganize retire list while the object is deleting. However, as I see, the origin code doesn't adjust the index simultaneously, which will skip track of the object origin from &rl->list[iret + 1]. Change the behavior as: - If reorganize happens, keep the same index for next iteration. - Else, index++.
In my opinion, the original code might be a bug. |
I think the change is correct since the original code skips the next element if a deletion happens. |
Thank @kevinshieh0225 for contributing. The git commit message was amended upon the review of @linD026 and @kdnvt . |
In list_hp_retire function of hp_list, the original code would skip the next element if a deletion happens. It was incorrect because of its neglect to adjust the index simultaneously, skipping track of the object origin from &rl->list[iret + 1]. This patch then changed the behavior as: - If reorganize happens, keep the same index for next iteration. - Else, index++.
In hp_list project's function : list_hp_retire, it attempt to reorganize retire list while the object is deleting.
However, as I see, the origin code doesn't adjust the index simultaneously, which will skip track of the object
origin from &rl->list[iret + 1]. I'm not sure whether the behavior was originally intended or not.