Re: Locking task->security

From: Seth Arnold (sarnoldat_private)
Date: Thu Aug 30 2001 - 18:14:28 PDT

  • Next message: Greg KH: "Re: Locking task->security"

    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
    



    This archive was generated by hypermail 2b30 : Thu Aug 30 2001 - 19:12:29 PDT