03 Aug, 2011

2 commits


01 Aug, 2011

4 commits


26 Jul, 2011

3 commits


26 Jan, 2011

1 commit

  • nfsacl_encode() allocates memory in certain cases. This of course
    is not guaranteed to work.

    Since commit 9f06c719 "SUNRPC: New xdr_streams XDR encoder API", the
    kernel's XDR encoders can't return a result indicating possibly a
    failure, so a memory allocation failure in nfsacl_encode() has become
    fatal (ie, the XDR code Oopses) in some cases.

    However, the allocated memory is a tiny fixed amount, on the order
    of 40-50 bytes. We can easily use a stack-allocated buffer for
    this, with only a wee bit of nose-holding.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

07 Jan, 2011

1 commit

  • This simple implementation just checks for no ACLs on the inode, and
    if so, then the rcu-walk may proceed, otherwise fail it.

    This could easily be extended to put acls under RCU and check them
    under seqlock, if need be. But this implementation is enough to show
    the rcu-walk aware permissions code for path lookups is working, and
    will handle cases where there are no ACLs or ACLs in just the final
    element.

    This patch implicity converts tmpfs to rcu-aware permission check.
    Subsequent patches onvert ext*, xfs, and, btrfs. Each of these uses
    acl/permission code in a different way, so convert them all to provide
    templates and proof of concept.

    Signed-off-by: Nick Piggin

    Nick Piggin
     

03 Dec, 2009

1 commit


25 Jun, 2009

2 commits


24 Jun, 2009

1 commit


09 Oct, 2005

1 commit

  • - added typedef unsigned int __nocast gfp_t;

    - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
    the same warnings as far as sparse is concerned, doesn't change
    generated code (from gcc point of view we replaced unsigned int with
    typedef) and documents what's going on far better.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds