Mdthbs

Must every right-inverse of a linear transformation be a linear transformation?

Why "strap-on" boosters, and how do other people say it?

Why is a weak base more able to deprotonate a strong acid than a weak acid?

Keeping the dodos out of the field

Meaning of "half-crown enclosure"

Ribbon Cable Cross Talk - Is there a fix after the fact?

Is the default 512 byte physical sector size appropriate for SSD disks under Linux?

Download app bundles from App Store to run on iOS Emulator on Mac

why "American-born", not "America-born"?

Managing heat dissipation in a magic wand

How to tease a romance without a cat and mouse chase?

How do you earn the reader's trust?

Is there a word for pant sleeves?

Is there a linguistic basses for how to translate John 8:43, or are translations basing their translation on context alone?

Three knights or knaves, three different hair colors

Why is 'additive' EQ more difficult to use than 'subtractive'?

Efficient Algorithms for Destroyed Document Reconstruction

Can a UK national work as a paid shop assistant in the USA?

Sony VAIO Duo 13 Wifi not working on Ubuntu 16.04

VHDL: Why is it hard to desgin a floating point unit in hardware?

Does attacking (or having a rider attack) cancel Charge/Pounce-like abilities?

Adobe Illustrator: How can I change the profile of a dashed stroke?

How to safely discharge oneself

Is a world with one country feeding everyone possible?

mmap: effect of other processes writing to a file previously mapped read-only

How does copy-on-write in fork() handle multiple fork?Writing own daemon. systemd error: Failed to read PID from file: Invalid argumentPagemap on memory mapped devices not workingWhen writing a file, permissions are write onlyUnderstanding MMAPMonitoring page cache / memory mapped files accessmajor page faults on anon mappingsHow to use dd if=/dev/mem in place of devmem ?Is there a standard for the Linux user-space memory map?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

1

1

I am trying to understand what happens when a file, which has been mapped into memory by the mmap system call, is subsequently written to by other processes.

I have mmaped memory with PROT_READ protection in "process A". If I close the underlying file descriptor in process A, and another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected? Given that the pages are read-only, I would expect them not to change. However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory. I am suspecting that this is stemming from writes to the backing file by other processes. Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

c mmap

share|improve this question

asked 2 hours ago

user001user001

1,63232141

add a comment | 

1

1

I am trying to understand what happens when a file, which has been mapped into memory by the mmap system call, is subsequently written to by other processes.

I have mmaped memory with PROT_READ protection in "process A". If I close the underlying file descriptor in process A, and another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected? Given that the pages are read-only, I would expect them not to change. However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory. I am suspecting that this is stemming from writes to the backing file by other processes. Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

c mmap

share|improve this question

asked 2 hours ago

user001user001

1,63232141

add a comment | 

I am trying to understand what happens when a file, which has been mapped into memory by the mmap system call, is subsequently written to by other processes.

I have mmaped memory with PROT_READ protection in "process A". If I close the underlying file descriptor in process A, and another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected? Given that the pages are read-only, I would expect them not to change. However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory. I am suspecting that this is stemming from writes to the backing file by other processes. Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

c mmap

share|improve this question

asked 2 hours ago

user001user001

1,63232141

share|improve this question

asked 2 hours ago

user001user001

1,63232141

share|improve this question

asked 2 hours ago

user001user001

1,63232141

asked 2 hours ago

user001user001

1,63232141

asked 2 hours ago

user001user001

1,63232141

1 Answer
1

active

oldest

votes

3

If I close the underlying file descriptor in process A,

closing the file descriptor doesn't change anything at all

another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected?

It may be. The manpage of mmap(2) says:

 MAP_PRIVATE

    ...

    It is  unspecified  whether changes made to the file

    after the mmap() call are visible in the mapped region.

In practice, changes made by other processes seem to be reflected in the content of the mmaped region, at least for regular files.

However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory.

I'm expecting that to happen when you truncate a mmaped file.

Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

No, MAP_PRIVATE only prevent modifications to the memory from being carried through to the backing file, not the reverse.

share|improve this answer

answered 1 hour ago

mosvymosvy

11.6k11340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thanks, that helps. So it sounds like mmap is not the right tool for reading (and preserving in memory) the current state of a file, when that file might be modified by other processes before the memory has been completely read by the process which created the map?
  
  – user001
  57 mins ago
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  hurd seems to have a MAP_COPY for that, but that's not supported on Linux/BSD/Solaris/etc. You can read more about it here.
  
  – mosvy
  44 mins ago
  

  
  
  
  

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

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

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f519850%2fmmap-effect-of-other-processes-writing-to-a-file-previously-mapped-read-only%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

3

If I close the underlying file descriptor in process A,

closing the file descriptor doesn't change anything at all

another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected?

It may be. The manpage of mmap(2) says:

 MAP_PRIVATE

    ...

    It is  unspecified  whether changes made to the file

    after the mmap() call are visible in the mapped region.

In practice, changes made by other processes seem to be reflected in the content of the mmaped region, at least for regular files.

However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory.

I'm expecting that to happen when you truncate a mmaped file.

Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

No, MAP_PRIVATE only prevent modifications to the memory from being carried through to the backing file, not the reverse.

share|improve this answer

answered 1 hour ago

mosvymosvy

11.6k11340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thanks, that helps. So it sounds like mmap is not the right tool for reading (and preserving in memory) the current state of a file, when that file might be modified by other processes before the memory has been completely read by the process which created the map?
  
  – user001
  57 mins ago
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  hurd seems to have a MAP_COPY for that, but that's not supported on Linux/BSD/Solaris/etc. You can read more about it here.
  
  – mosvy
  44 mins ago
  

  
  
  
  

add a comment | 

3

If I close the underlying file descriptor in process A,

closing the file descriptor doesn't change anything at all

another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected?

It may be. The manpage of mmap(2) says:

 MAP_PRIVATE

    ...

    It is  unspecified  whether changes made to the file

    after the mmap() call are visible in the mapped region.

In practice, changes made by other processes seem to be reflected in the content of the mmaped region, at least for regular files.

However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory.

I'm expecting that to happen when you truncate a mmaped file.

Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

No, MAP_PRIVATE only prevent modifications to the memory from being carried through to the backing file, not the reverse.

share|improve this answer

answered 1 hour ago

mosvymosvy

11.6k11340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thanks, that helps. So it sounds like mmap is not the right tool for reading (and preserving in memory) the current state of a file, when that file might be modified by other processes before the memory has been completely read by the process which created the map?
  
  – user001
  57 mins ago
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  hurd seems to have a MAP_COPY for that, but that's not supported on Linux/BSD/Solaris/etc. You can read more about it here.
  
  – mosvy
  44 mins ago
  

  
  
  
  

add a comment | 

If I close the underlying file descriptor in process A,

closing the file descriptor doesn't change anything at all

another process later writes to that file (not using mmap; just a simple redirection of stdout to the file using > in the shell), is the mmaped memory in the address space of process A affected?

It may be. The manpage of mmap(2) says:

 MAP_PRIVATE

    ...

    It is  unspecified  whether changes made to the file

    after the mmap() call are visible in the mapped region.

In practice, changes made by other processes seem to be reflected in the content of the mmaped region, at least for regular files.

However, process A is being terminated by SIGBUS signals as a result of invalid memory accesses (Non-existent physical address at address 0x[...]) when trying to parse the mapped memory.

I'm expecting that to happen when you truncate a mmaped file.

Would setting MAP_PRIVATE be sufficient to completely protect this memory from other processes?

No, MAP_PRIVATE only prevent modifications to the memory from being carried through to the backing file, not the reverse.

share|improve this answer

answered 1 hour ago

mosvymosvy

11.6k11340

 MAP_PRIVATE

    ...

    It is  unspecified  whether changes made to the file

    after the mmap() call are visible in the mapped region.

share|improve this answer

answered 1 hour ago

mosvymosvy

11.6k11340

answered 1 hour ago

mosvymosvy

11.6k11340

answered 1 hour ago

mosvymosvy

11.6k11340