Re: quotactl hook

From: Greg KH (gregat_private)
Date: Sat Sep 01 2001 - 17:13:03 PDT

  • Next message: jmjonesat_private: "Re: quotactl hook"

    On Sat, Sep 01, 2001 at 07:25:03PM -0400, jmjonesat_private wrote:
    > 
    > I had not thought this was the "policy", at this point, but rather had
    > believed that SGI was reviewing "some authoritative" and had responded
    > positively to a limitted application.
    > 
    > If it's a complete "NO", I will procede forward based on that.
    
    Come on people.  We went over this months ago.  I was very surprised to
    see it come up again at the BOF meeting, which I interpreted as Crispin of
    WireX giving SGI the benefit of the doubt.  Since neither of them have
    really talked about it since then on the list, I don't see any reason
    why we would change the proposed plan that I thought we had all agreed
    upon.
    
    > I'd think that a mechanism to init blobs reliably without conflict would
    > be a consideration if this support was to be applied.  I admit I haven't
    > looked "very closely" at the patch with this regard... our prototypes
    > assume that a NULL is an un-allocated blob and don't deal with locking.
    
    That's a good assumption to make :)
    But you really should consider locking things when modifying them if
    another processor could be modifying them at that same moment also (like
    within your same function.)
    
    > We DID see locking as a consdir-able issue and hoped it would get more
    > discussion.
    
    I'd be glad to talk about it if anyone has any questions.  Locking
    problems are something that I like to mess with.  There are lots of
    different ways to implements locks in the Linux kernel, depending on
    your requirements.
    
    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 : Sat Sep 01 2001 - 17:16:34 PDT