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?

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

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

@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

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.

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?

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

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

@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

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.

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?

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

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.

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 Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

edited Feb 12 at 10:26

ctrl-alt-delor

11.6k42159

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

asked Feb 2 at 1:32

炸鱼薯条德里克

510214

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

@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

add a comment |

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

@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

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

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.

edited Feb 2 at 3:38

answered Feb 2 at 3:01

Ed Grimm

3737

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
);

);

draft saved

draft discarded

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

Name

Required, but never shown

1 Answer
1

active

oldest

votes

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.

edited Feb 2 at 3:38

answered Feb 2 at 3:01

Ed Grimm

3737

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.

edited Feb 2 at 3:38

answered Feb 2 at 3:01

Ed Grimm

3737

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.

edited Feb 2 at 3:38

answered Feb 2 at 3:01

Ed Grimm

3737

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.

edited Feb 2 at 3:38

answered Feb 2 at 3:01

Ed Grimm

3737

edited Feb 2 at 3:38

answered Feb 2 at 3:01

Ed Grimm

3737

answered Feb 2 at 3:01

Ed Grimm

3737

answered Feb 2 at 3:01

Ed Grimm

3737

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

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

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 |

draft saved

draft discarded

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.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

搜尋此網誌

mjhjmtu