On Wed, 2005-10-12 at 22:33 +0100, Neal H. Walfield wrote: > > > To simplify the protocols, it is normal for the client to specify a > > space bank at object creation time. The server associates this bank with > > the object for later use when that object is extended, grown, or shrunk. > > How does the client determine how large a space bank to hand to the > server? In the case of an object upon which the client depends, I can > see the argument that no limit need be provided. On the other hand, a > task might have a number of resources that it would like to use but > doesn't depend on. If it gives unlimited access to its space bank > then one misbehaving server can create a denial of service.
The answer is: in the absence of a storage requirement specification you can't figure it out. But in practice the right solution is to invert the problem. Ensure that you know the storage required for your process manager window. Let everything else run unlimited. Here is how this works: Space banks form a tree. The effective limit on a bank is the *least* limit of all of its parents. It is legal to build a parent with a limit of 2 and a child bank of this parent with a limit of 18. All space banks are actually implemented by a single server process, so the tree traversal does not involve any context switches. It is also legal to build *unlimited* banks, and these can be children of limited banks. This does not mean that allocation is unlimited. It merely means that no limit is imposed by the unlimited bank. So in practice, the thing to do is have the shell run each program in a dedicated, unlimited sub-bank. If the program goes crazy, you destroy the bank. When you destroy the bank, all of the storage is destroyed too. I guess what I am saying is: Alfred is right. Either you know what the space requirement is or quotas are stupid. In a general-purpose system, the bad behavior is going to happen rarely enough that you can deal with it on an exceptional basis. You just want to make sure that you have a destroyable bank in place that you can use to kill the misbehaving process(es). > What does the server do when it requires more storage but the space > bank is full? Current behavior: When the limit is exceeded, allocation fails. Norm Hardy and I have discussed a design in which a fault handler could be associated with a limited bank that might be invoked to try to resolve the problem. Norm had some concerns about this related to covert storage channels. This is a case where he and I do not fully agree. I believe that the value of recoverability in this situation outweighs the risk of the storage channel. However, there are some classified system configurations in which this decision might need to be made the other way. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
