On Mon, 26 Mar 2007, David Howells wrote:
> I don't know, what does it do? Remember, once a NOMMU process thinks it has
> the right to access a mapping, there's no way of stopping it doing so short of
> killing the process.
revoke_mapping() is mostly same as munmap(2) except that it preserves the
vma but makes it VM_REVOKED. This means that if the process tries to
access the region it will SIGBUS and if it tries to remap the range it
will get EINVAL.
What we're trying to do here is, we want to make sure no other tasks can
access the inode once it has been revoked.
On Mon, 26 Mar 2007, David Howells wrote:
> With NOMMU as it stands, private mappings are private copies of the data, and
> have no impact on the page cache and get no updates from it. It's as if you
> took a private writable mapping, touched every page and then mprotect()'d it.
> This isn't necessarily ideal, but we're limited by the lack on an MMU.
So there's no way to raise SIGBUS if the range is being accessed. The
alternatives are:
- No support for revoke(2) on NOMMU.
- If there are shared mappings, always return -ENOENT for revoke(2).
- If there are shared mappings, immediately raise SIGBUS for those
processes that are accessing it.
Making the shared mappings private is not an option because there's no way
for the process to know that it's mapping is being pulled under it which
will result in bugs. Hmm.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
