Pekka J Enberg <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
