> As we really prefer working systems over non-working ones (and lots > of unattached shm segments can clearly result in a non-working > system) we can only accept the "this will break stuff" argument if > it's *demonstrated* to break stuff and if the failure scenario is > carefully described in the commit. > > It would take a serious breakage to override a "system locks up > swapping itself to death" failure scenario. Ths shared memory interface is defined to be persistent for good reason and all sorts of apps rely upon that so no you can't just ignore that. As a configurable alternative it makes sense (indeed many SYS5 admins used to run shared memory segment sweepers to clean up long idle ones) However if it's locking the machine up and not being properly handled by resource management then a) your resource management is broken so fix that instead b) if your resource management is busted or you are not properly tracking resource commits then the user is going to be able to achieve the same result by other means (eg a unix domain socket bomb) If you've got no overcommit set you shouldn't be able to swap to death, it may be the sysv shared memory objects need to be accounted for specifically somewhere but that would be the right thing to fix and the mechanisms to do it exist. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
