On Thu, Aug 30, 2001 at 05:33:25PM -0700, richard offer wrote: > > Wouldn't a static lock be 4) (that was what I meant by 4)) ? No, it would be a lock in your module, not any lock in the current security.c file. It would be local to your code. > See...if only there was only one lock it would be easy :-) Having a void * > security_lock member in the task struct would provide enough mechanism for > 2) without setting policy. void * are bad. And we are only getting away with it due to the totally different security models we want to support. There are different kinds of locks, because you need them under different situations. I'm not going to discuss locking mechanisms here, but please go read the documentation I pointed out to get an idea of the different issues involved. > From Chris's explanation it seems that I shouldn't need to lock > current->security only the contents of current->security is that true ? > Assuming the worst case scenario, is there no way that current->security > (not the contents) can be accessed from multiple locations simmultaniously > ? Is it possible for a single process to call two system calls at the same > time ? My guess is no, not with the current threading model (n-to-1) ? > > Are there any plans to re-do the threading to provide a n-to-m type model ? > Wouldn't that sort of be something needed to get Linux to scale to higher > CPU counts (in terms of usefulness to applications) ? No, threading doesn't play too much of an issue with scalability. Things like reducing lock contention and better scheduler algorithms do. See http://lse.sf.net/ if you're interested in those things. thanks, greg k-h _______________________________________________ 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 - 19:28:56 PDT