On Thu, Aug 30, 2001 at 02:47:22PM -0700, richard offer wrote: > 1) lock the whole task structure (very bad) Yeah; a lock is only a lock if it is respected. And a lot modifies the task structures. Modifying all that code to respect a new lock is probably not the best use of anyone's time. :) > 2) add a new security specific lock to the task to protect access to > the security blob > 3) add a lock inside the structure hanging off security (bad) Yeah, probably bad -- but, since you are going to be controlling everything anyway, this isn't inherently wrong. A method could be worked out for this to function. > 4) add a global policy specific lock (bad) Well, depending on how often the lock must be acquired and held, this might not be as bad as you think. If locking usually happens once per second for 1/100th of a second, the chances of contention are probably a little too high. However, if the lock needs to acquired every few minutes, and held for 1/100th of a second, chances are that this method won't be too shabby. I think I like #2 the most too, but reserve the right to change my mind. :) _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Aug 30 2001 - 15:22:39 PDT