Doug / smarc-fsl-linux-kernel

15 Jan, 2006

1 commit

11 Jan, 2006

1 commit

  • e866cfa93   [PATCH] d_instantiate_unique / NFS inode leakage ... Browse Code »

    If we have found aliased dentry that we return, inode reference is not
    dropped and inode is not attached anywhere, so it seems the reference to
    inode is leaked in that case.

    Cc: Trond Myklebust ,
    Cc:
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Drokin
     

09 Jan, 2006

1 commit

  • 5160ee6fc   [PATCH] shrink dentry struct ... Browse Code »

    Some long time ago, dentry struct was carefully tuned so that on 32 bits
    UP, sizeof(struct dentry) was exactly 128, ie a power of 2, and a multiple
    of memory cache lines.

    Then RCU was added and dentry struct enlarged by two pointers, with nice
    results for SMP, but not so good on UP, because breaking the above tuning
    (128 + 8 = 136 bytes)

    This patch reverts this unwanted side effect, by using an union (d_u),
    where d_rcu and d_child are placed so that these two fields can share their
    memory needs.

    At the time d_free() is called (and d_rcu is really used), d_child is known
    to be empty and not touched by the dentry freeing.

    Lockless lookups only access d_name, d_parent, d_lock, d_op, d_flags (so
    the previous content of d_child is not needed if said dentry was unhashed
    but still accessed by a CPU because of RCU constraints)

    As dentry cache easily contains millions of entries, a size reduction is
    worth the extra complexity of the ugly C union.

    Signed-off-by: Eric Dumazet
    Cc: Dipankar Sarma
    Cc: Maneesh Soni
    Cc: Miklos Szeredi
    Cc: "Paul E. McKenney"
    Cc: Ian Kent
    Cc: Paul Jackson
    Cc: Al Viro
    Cc: Christoph Hellwig
    Cc: Trond Myklebust
    Cc: Neil Brown
    Cc: James Morris
    Cc: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     

07 Nov, 2005

1 commit

28 Oct, 2005

1 commit

  • 27496a8c6   [PATCH] gfp_t: fs/* ... Browse Code »

    - ->releasepage() annotated (s/int/gfp_t), instances updated
    - missing gfp_t in fs/* added
    - fixed misannotation from the original sweep caught by bitwise checks:
    XFS used __nocast both for gfp_t and for flags used by XFS allocator.
    The latter left with unsigned int __nocast; we might want to add a
    different type for those but for now let's leave them alone. That,
    BTW, is a case when __nocast use had been actively confusing - it had
    been used in the same code for two different and similar types, with
    no way to catch misuses. Switch of gfp_t to bitwise had caught that
    immediately...

    One tricky bit is left alone to be dealt with later - mapping->flags is
    a mix of gfp_t and error indications. Left alone for now.

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

    Al Viro
     

20 Sep, 2005

1 commit

11 Sep, 2005

1 commit

09 Aug, 2005

1 commit

  • 7a91bf7f5   [PATCH] fsnotify_name/inoderemove ... Browse Code »

    The patch below unhooks fsnotify from vfs_unlink & vfs_rmdir. It
    introduces two new fsnotify calls, that are hooked in at the dcache
    level. This not only more closely matches how the VFS layer works, it
    also avoids the problem with locking and inode lifetimes.

    The two functions are

    - fsnotify_nameremove -- called when a directory entry is going away.
    It notifies the PARENT of the deletion. This is called from
    d_delete().

    - inoderemove -- called when the files inode itself is going away. It
    notifies the inode that is being deleted. This is called from
    dentry_iput().

    Signed-off-by: John McCutchan
    Signed-off-by: Linus Torvalds

    John McCutchan
     

06 May, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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