Re: Locking task->security

sarnoldat_private

On Thu, Aug 30, 2001 at 05:33:25PM -0700, richard offer wrote:
> From Chris's explanation it seems that I shouldn't need to lock
> current->security only the contents of current->security is that true ?

Well, by the very nature of current, once current->security is
instantiated, you can use its lock. And, current->security ought to be
initialized in the clone() handling stuff -- of which, for any given
task, really ought to be done only once. :) (Process trees don't have
multiple inheritence. :)

> 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) ? 

Many people will maintain that the linux task model is superior to many
other forms of threading, and I think I have to agree -- at least signal
delivery makes some level of sense. (Think sigchld.)

So, then, an understanding of the linux model is important. :) It would
be best to throw away the idea 'process' and 'thread' in your mind, and
think instead of 'tasks'. A new process and a new thread are both
created using the clone interface, which specifies which pieces of the
old task structure ought to be copied over to the new task structure. If
the two tasks share memory space, then they are called 'threads'. If
they don't share memory space, they are called 'processes'.

(This is rough, emailish description, but hopefully the flavor is
correct enough for you to get done what you need to get done. :)

So, you don't run the risk of one process calling several system calls
at once, even on SMP machines, because each task has only one thread
of execution.

However, if anything in your system intends on modifying the security
field of other processes, then you will want some other method of
locking the struct. :)

I recall seeing a project, hosted at SGI, that was working on an n-to-m
thread model; check the FOLK (functionally overloaded linux kernel) team
to see more information, I think that is where I first saw the reference.

Oh yeah -- based on gregkh's comments in the other email, I now think
that putting the lock in the task struct is a lousy idea. :) hehe. How
quickly thoughts can be modified...

I hope this was useful. :)

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module