Why doesn't Linux support mmap by path?
The mmap syscall needs a fd as parameter, but when you close that fd, the mmap is still alive in the process's memory address space.
Therefore keeping an mmap doesn't need an opened fd, so why dose Linux only support creating an mmap of a file using a fd, but not a file-name-path? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?
If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.
Is there any historical or security reason for not having such syscall on Linux kernel?
linux-kernel
edited yesterday
ctrl-alt-delor
11.4k42058
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
add a comment |
The mmap syscall needs a fd as parameter, but when you close that fd, the mmap is still alive in the process's memory address space.
Therefore keeping an mmap doesn't need an opened fd, so why dose Linux only support creating an mmap of a file using a fd, but not a file-name-path? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?
If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.
Is there any historical or security reason for not having such syscall on Linux kernel?
linux-kernel
edited yesterday
ctrl-alt-delor
11.4k42058
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
1
The*_atdiffer from their non-at counterparts by being able to resolve relative path wrt to an openfdto a directory instead of the cwd, not by using a path instead of a file descriptor. As to why yourmmap_path()is not implemented in the kernel, the keyword from your question is "atomically". Good luck doing it atomically.
– mosvy
Feb 4 at 4:59
@mosvy Butmmapnever support path. While other functions support path either *at or non-at version.
– 炸鱼薯条德里克
Feb 4 at 5:06
That's why I was suggesting you to rename itmmap_path();-)
– mosvy
Feb 4 at 5:08
add a comment |
The mmap syscall needs a fd as parameter, but when you close that fd, the mmap is still alive in the process's memory address space.
Therefore keeping an mmap doesn't need an opened fd, so why dose Linux only support creating an mmap of a file using a fd, but not a file-name-path? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?
If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.
Is there any historical or security reason for not having such syscall on Linux kernel?
linux-kernel
edited yesterday
ctrl-alt-delor
11.4k42058
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
The mmap syscall needs a fd as parameter, but when you close that fd, the mmap is still alive in the process's memory address space.
Therefore keeping an mmap doesn't need an opened fd, so why dose Linux only support creating an mmap of a file using a fd, but not a file-name-path? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?
If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.
Is there any historical or security reason for not having such syscall on Linux kernel?
linux-kernel
linux-kernel
edited yesterday
ctrl-alt-delor
11.4k42058
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
edited yesterday
ctrl-alt-delor
11.4k42058
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
edited yesterday
ctrl-alt-delor
11.4k42058
edited yesterday
ctrl-alt-delor
11.4k42058
edited yesterday
ctrl-alt-delor
11.4k42058
11.4k42058
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
asked Feb 2 at 1:32
炸鱼薯条德里克炸鱼薯条德里克
477214
477214
1
The*_atdiffer from their non-at counterparts by being able to resolve relative path wrt to an openfdto a directory instead of the cwd, not by using a path instead of a file descriptor. As to why yourmmap_path()is not implemented in the kernel, the keyword from your question is "atomically". Good luck doing it atomically.
– mosvy
Feb 4 at 4:59
@mosvy Butmmapnever support path. While other functions support path either *at or non-at version.
– 炸鱼薯条德里克
Feb 4 at 5:06
That's why I was suggesting you to rename itmmap_path();-)
– mosvy
Feb 4 at 5:08
add a comment |
1
The*_atdiffer from their non-at counterparts by being able to resolve relative path wrt to an openfdto a directory instead of the cwd, not by using a path instead of a file descriptor. As to why yourmmap_path()is not implemented in the kernel, the keyword from your question is "atomically". Good luck doing it atomically.
– mosvy
Feb 4 at 4:59
@mosvy Butmmapnever support path. While other functions support path either *at or non-at version.
– 炸鱼薯条德里克
Feb 4 at 5:06
That's why I was suggesting you to rename itmmap_path();-)
– mosvy
Feb 4 at 5:08
1
1
The
*_at differ from their non-at counterparts by being able to resolve relative path wrt to an open fd to a directory instead of the cwd, not by using a path instead of a file descriptor. As to why your mmap_path() is not implemented in the kernel, the keyword from your question is "atomically". Good luck doing it atomically.– mosvy
Feb 4 at 4:59
The
*_at differ from their non-at counterparts by being able to resolve relative path wrt to an open fd to a directory instead of the cwd, not by using a path instead of a file descriptor. As to why your mmap_path() is not implemented in the kernel, the keyword from your question is "atomically". Good luck doing it atomically.– mosvy
Feb 4 at 4:59
@mosvy But
mmap never support path. While other functions support path either *at or non-at version.– 炸鱼薯条德里克
Feb 4 at 5:06
@mosvy But
mmap never support path. While other functions support path either *at or non-at version.– 炸鱼薯条德里克
Feb 4 at 5:06
That's why I was suggesting you to rename it
mmap_path() ;-)– mosvy
Feb 4 at 5:08
That's why I was suggesting you to rename it
mmap_path() ;-)– mosvy
Feb 4 at 5:08
add a comment |
1 Answer
1
active
oldest
votes
mmap(2) is basically a read(2) to a buffer that the kernel is going to write to directly, rather than reading to a kernel buffer and then copying to the provided buffer.
There's no mmapat(2) for the same reason there's no readat(2).
The file descriptor isn't needed any more because
The mmap() function adds an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference is removed when there are no more mappings to the file.
This is per the OpenGroup's website. They're the people who mange the POSIX standard, if I'm not mistaken, so they should know.
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
1
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f498236%2fwhy-doesnt-linux-support-mmap-by-path%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
mmap(2) is basically a read(2) to a buffer that the kernel is going to write to directly, rather than reading to a kernel buffer and then copying to the provided buffer.
There's no mmapat(2) for the same reason there's no readat(2).
The file descriptor isn't needed any more because
The mmap() function adds an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference is removed when there are no more mappings to the file.
This is per the OpenGroup's website. They're the people who mange the POSIX standard, if I'm not mistaken, so they should know.
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
1
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
add a comment |
mmap(2) is basically a read(2) to a buffer that the kernel is going to write to directly, rather than reading to a kernel buffer and then copying to the provided buffer.
There's no mmapat(2) for the same reason there's no readat(2).
The file descriptor isn't needed any more because
The mmap() function adds an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference is removed when there are no more mappings to the file.
This is per the OpenGroup's website. They're the people who mange the POSIX standard, if I'm not mistaken, so they should know.
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
1
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
add a comment |
mmap(2) is basically a read(2) to a buffer that the kernel is going to write to directly, rather than reading to a kernel buffer and then copying to the provided buffer.
There's no mmapat(2) for the same reason there's no readat(2).
The file descriptor isn't needed any more because
The mmap() function adds an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference is removed when there are no more mappings to the file.
This is per the OpenGroup's website. They're the people who mange the POSIX standard, if I'm not mistaken, so they should know.
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
mmap(2) is basically a read(2) to a buffer that the kernel is going to write to directly, rather than reading to a kernel buffer and then copying to the provided buffer.
There's no mmapat(2) for the same reason there's no readat(2).
The file descriptor isn't needed any more because
The mmap() function adds an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference is removed when there are no more mappings to the file.
This is per the OpenGroup's website. They're the people who mange the POSIX standard, if I'm not mistaken, so they should know.
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
edited Feb 2 at 3:38
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
answered Feb 2 at 3:01
Ed GrimmEd Grimm
3286
3286
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
1
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
add a comment |
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
1
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
You can't write to a mmaped file after all fd of it are closed even though the mmap is PROT_WRITE|MAP_SHARED ?
– 炸鱼薯条德里克
Feb 2 at 3:24
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
I didn't say whether or not you can write to an mmapped file after the fd is closed. I said if you can write to the file through the closed fd then it's magic.
– Ed Grimm
Feb 2 at 3:32
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
And just found the reference I was looking for, and yeah, it's magic. Specifically, implicit dup(2) magic. I should learn to date-check references before accepting them. Google returned two links, and I guessed the first would be the better link because Google. Sigh.
– Ed Grimm
Feb 2 at 3:39
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
Yeah, but if it creates an extra reference, why can't we have mmapat which create such extra reference at the first time?
– 炸鱼薯条德里克
Feb 2 at 3:48
1
1
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
mmap is basically an alternate implementation of read. You can if you want write the wrapper function you're asking for and use it yourself, but you'll have about as much luck getting a standard library to incorporate it as you would having them incorporate readat.
– Ed Grimm
Feb 2 at 3:51
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f498236%2fwhy-doesnt-linux-support-mmap-by-path%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
The
*_atdiffer from their non-at counterparts by being able to resolve relative path wrt to an openfdto a directory instead of the cwd, not by using a path instead of a file descriptor. As to why yourmmap_path()is not implemented in the kernel, the keyword from your question is "atomically". Good luck doing it atomically.– mosvy
Feb 4 at 4:59
@mosvy But
mmapnever support path. While other functions support path either *at or non-at version.– 炸鱼薯条德里克
Feb 4 at 5:06
That's why I was suggesting you to rename it
mmap_path();-)– mosvy
Feb 4 at 5:08