Skip to content
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

mmap non-zero length #1873

Merged
merged 1 commit into from
Nov 21, 2022

Conversation

JonathanWoollett-Light
Copy link
Contributor

When calling mmap the passed length needs to be greater than zero, else an error is returned:

EINVAL (since Linux 2.6.12) length was 0.

By specifying the argument as std::num::NonZeroUsize we eliminate this error case.

@JonathanWoollett-Light JonathanWoollett-Light force-pushed the mmap-non-zero-length branch 2 times, most recently from b7d0d7c to eb489a9 Compare November 20, 2022 16:35
Copy link
Member

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good improvement. But don't forget a CHANGELOG. Also, what about
mremap, and munmap? The man pages have the same restriction for them. And for msync, a zero-value for the length argument has special meaning, so we should probably turn it into Option<usize>.

@@ -515,8 +515,9 @@ pub unsafe fn madvise(
/// # use nix::sys::mman::{mmap, mprotect, MapFlags, ProtFlags};
/// # use std::ptr;
/// const ONE_K: size_t = 1024;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ONE_K is no longer used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to fix this.


#[test]
fn test_mmap_anonymous() {
unsafe {
let ptr = mmap(
std::ptr::null_mut(),
1,
NonZeroUsize::new(1).unwrap(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it would be worthwhile to bring in the nonzero_ext crate just for these tests?

Suggested change
NonZeroUsize::new(1).unwrap(),
nonzero_ext::nonzero!(1)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point no, but if NonZeroUsize sees wider usage it may become worthwhile.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, I took a look through my other crates and found exactly zero places where nonzero_ext would help. It turns out that Option<NonZeroXXX> is a lot more common than NonZeroXXX.

@JonathanWoollett-Light
Copy link
Contributor Author

I think this is a good improvement. But don't forget a CHANGELOG. Also, what about mremap, and munmap? The man pages have the same restriction for them. And for msync, a zero-value for the length argument has special meaning, so we should probably turn it into Option<usize>.

These changes make sense to me. I think they make sense as separate PRs to keep the changes incremental.

Comment on lines 88 to 91
let one_k_non_zero = NonZeroUsize::new(ONE_K).unwrap();
let ten_one_k = one_k_non_zero
.checked_mul(NonZeroUsize::new(10).unwrap())
.unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd hate to raise the MSRV just for this one line in a test. How about this instead?

Suggested change
let one_k_non_zero = NonZeroUsize::new(ONE_K).unwrap();
let ten_one_k = one_k_non_zero
.checked_mul(NonZeroUsize::new(10).unwrap())
.unwrap();
let ten_one_k = NonZeroUsize::new(10 * 1024).unwrap();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@JonathanWoollett-Light JonathanWoollett-Light force-pushed the mmap-non-zero-length branch 2 times, most recently from 9ab07dc to d034ea5 Compare November 20, 2022 17:53
Copy link
Member

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bors r+

@bors
Copy link
Contributor

bors bot commented Nov 20, 2022

Merge conflict.

@asomers
Copy link
Member

asomers commented Nov 21, 2022

bors retry

@bors bors bot merged commit 8d27985 into nix-rust:master Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants