Pekka J Enberg <[EMAIL PROTECTED]> wrote: > We don't touch private mappings at all as they're a snapshot to the inode > _before_ it was revoked. So private mappings don't really matter all: you > don't see any new data after it has been revoked nor do you flush anything > to the disk.
Okay, so that's not a problem. > Well, assuming we would use revoke for things like SAK, this doesn't > really work out too well because all a malicious process has to is create > a shared mapping and they've effectively blocked the whole thing. In NOMMU-mode, there's probably[*] nothing stopping a malicious process running completely amok and changing stuff directly - even the kernel isn't guaranteed to be safe - so I wouldn't worry about such a case. [*] The FRV, for example, does have some limited protection capability - but it is really limited and not really useful in this case. > It's antisocial for sure but the only way to guarantee revoke() succeeds on > a NOMMU setup. Oh well, lets disable it for now and see if anyone even > wants revoke() for NOMMU. 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/
