-
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
Fix off by one in zpl_lookup #5768
Conversation
@tuxoko, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @dweeezil and @mkjorling to be potential reviewers. |
BTW, I have no idea why it uses |
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.
Nice find, the fix looks good. It is odd that we're not using MAXNAMELEN here. It looks like this case was accidentally swept up in the eca7b76 mass rename.
Using |
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.
Let's change this to ZAP_MAXNAMELEN
while we're here. They're both defined to 256 as they should be so there's no functional change.
Doing the following command would return success with zfs creating an orphan object. touch $(for i in $(seq 256); do printf "n"; done) The funny thing is that this will only work once for each directory, because after upgraded to fzap, zfs_lookup would fail properly since it has additional length check. Signed-off-by: Chunwei Chen <[email protected]>
Changed to ZAP_MAXNAMELEN |
Doing the following command would return success with zfs creating an orphan object. touch $(for i in $(seq 256); do printf "n"; done) The funny thing is that this will only work once for each directory, because after upgraded to fzap, zfs_lookup would fail properly since it has additional length check. Signed-off-by: Chunwei Chen <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Closes openzfs#5768
Doing the following command would return success with zfs creating an orphan object. touch $(for i in $(seq 256); do printf "n"; done) The funny thing is that this will only work once for each directory, because after upgraded to fzap, zfs_lookup would fail properly since it has additional length check. Signed-off-by: Chunwei Chen <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Closes openzfs#5768
Doing the following command would return success with zfs creating an orphan object. touch $(for i in $(seq 256); do printf "n"; done) The funny thing is that this will only work once for each directory, because after upgraded to fzap, zfs_lookup would fail properly since it has additional length check. Signed-off-by: Chunwei Chen <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Closes openzfs#5768
Doing the following command would return success with zfs creating an orphan object. touch $(for i in $(seq 256); do printf "n"; done) The funny thing is that this will only work once for each directory, because after upgraded to fzap, zfs_lookup would fail properly since it has additional length check. Signed-off-by: Chunwei Chen <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Closes openzfs#5768
Doing the following command would return success with zfs creating an orphan object. touch $(for i in $(seq 256); do printf "n"; done) The funny thing is that this will only work once for each directory, because after upgraded to fzap, zfs_lookup would fail properly since it has additional length check. Signed-off-by: Chunwei Chen <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Closes #5768
Doing the following command would return success with zfs creating an orphan
object.
The funny thing is that this will only work once for each directory, because
after upgraded to fzap, zfs_lookup would fail properly since it has additional
length check.
Signed-off-by: Chunwei Chen [email protected]
Types of changes
Checklist: