Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH -mm] Revoke core code: fix nommu arch compiling error bug | Date | Mon, 26 Mar 2007 13:22:44 +0100 |
| |
Pekka J Enberg <penberg@cs.helsinki.fi> 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.
Yeah, that's not enforceable in NOMMU-mode situations. I presume it differs from munmap() also in that it can effectively be forced by one process upon another.
In MMU-mode, how does this work with private mappings that have some private copies of the pages that make up the mapping? Are those still available to a process that is using them? Are they revoked when swapped out? Or are they forcibly evicted?
> 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.
Okay.
> So there's no way to raise SIGBUS if the range is being accessed. The > alternatives are: > > - No support for revoke(2) on NOMMU.
That's a bit over the top, I think. It sounds like revoke() is perfectly fine - as long as there aren't any mappings on the target inode (or at least shared mappings - dunno about private mappings).
> - If there are shared mappings, always return -ENOENT for revoke(2).
That sounds feasible. How about -ETXTBSY instead?
> - If there are shared mappings, immediately raise SIGBUS for those > processes that are accessing it.
Hmmm... maybe. That sounds a bit antisocial though, but is also workable. Does the SIGBUS raised have its own si_code, btw? Perhaps BUS_REVOKED?
> 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.
Agreed.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |