14 Feb, 2007

1 commit

  • This reverts commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1.

    It causes some strange Gnome problem with dbus-daemon getting stuck, so
    we'll revert it until that problem is understood.

    Reported by both walt and Greg KH, who both independently git-bisected
    the problem to this commit.

    Andreas is looking at it.

    Reported-by: walt
    Reported-by: Greg KH
    Acked-by: Andreas Gruenbacher
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

13 Feb, 2007

1 commit

  • Here is a bugfix to d_path.

    First, when d_path() hits a lazily unmounted mount point, it tries to
    prepend the name of the lazily unmounted dentry to the path name. It gets
    this wrong, and also overwrites the slash that separates the name from the
    following pathname component. This is demonstrated by the attached test
    case, which prints "getcwd returned d_path-bugsubdir" with the bug. The
    correct result would be "getcwd returned d_path-bug/subdir".

    It could be argued that the name of the root dentry should not be part of
    the result of d_path in the first place. On the other hand, what the
    unconnected namespace was once reachable as may provide some useful hints
    to users, and so that seems okay.

    Second, it isn't always possible to tell from the __d_path result whether
    the specified root and rootmnt (i.e., the chroot) was reached: lazy
    unmounts of bind mounts will produce a path that does start with a
    non-slash so we can tell from that, but other lazy unmounts will produce a
    path that starts with a slash, just like "ordinary" paths.

    The attached patch cleans up __d_path() to fix the bug with overlapping
    pathname components. It also adds a @fail_deleted argument, which allows
    to get rid of some of the mess in sys_getcwd(). Grabbing the dcache_lock
    can then also be moved into __d_path(). The patch also makes sure that
    paths will only start with a slash for paths which are connected to the
    root and rootmnt.

    The @fail_deleted argument could be added to d_path() as well: this would
    allow callers to recognize deleted files, without having to resort to the
    ambiguous check for the " (deleted)" string at the end of the pathnames.
    This is not currently done, but it might be worthwhile.

    Signed-off-by: Andreas Gruenbacher
    Cc: Neil Brown
    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andreas Gruenbacher
     

08 Dec, 2006

2 commits

  • Some dentries don't need to be globally visible in dentry hashtable.
    (pipes & sockets)

    Such dentries dont need to wait for a RCU grace period at delete time.
    Being able to free them permits a better CPU cache use (hot cache)

    This patch combined with (dont insert pipe dentries into dentry_hashtable)
    reduced time of { pipe(p); close(p[0]); close(p[1]);} on my UP machine (1.6
    GHz Pentium-M) from 3.23 us to 2.86 us (But this patch does not depend on
    other patches, only bench results)

    Signed-off-by: Eric Dumazet
    Cc: Al Viro
    Cc: Maneesh Soni
    Cc: "Paul E. McKenney"
    Cc: Dipankar Sarma
    Acked-by: David Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     
  • Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

29 Oct, 2006

2 commits

  • With Vasily Averin

    Fix an error in unused dentry counting in shrink_dcache_for_umount_subtree()
    in which the count is modified without the dcache_lock held.

    Signed-off-by: David Howells
    Cc: Vasily Averin
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • On the the following patch:
    http://linux.bkbits.net:8080/linux-2.6/gnupatch@449b144ecSF1rYskg3q-SeR2vf88zg

    # ChangeSet
    # 2006/06/22 15:05:57-07:00 neilb@suse.de
    # [PATCH] Fix dcache race during umount

    # If prune_dcache finds a dentry that it cannot free, it leaves it where it
    # is (at the tail of the list) and exits, on the assumption that some other
    # thread will be removing that dentry soon.

    However as far as I see this comment is not correct: when we cannot take
    s_umount rw_semaphore (for example because it was taken in do_remount) this
    dentry is already extracted from dentry_unused list and we do not add it
    into the list again. Therefore dentry will not be found by prune_dcache()
    and shrink_dcache_sb() and will leave in memory very long time until the
    partition will be unmounted.

    The patch adds this dentry into tail of the dentry_unused list.

    Signed-off-by: Vasily Averin
    Cc: Neil Brown
    Acked-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vasily Averin
     

22 Oct, 2006

1 commit

  • If the caller tries to instantiate a directory using an inode that already
    has a dentry alias, then we attempt to rename the existing dentry instead
    of instantiating a new one. Fail with an ELOOP error if the rename would
    affect one of our parent directories.

    This behaviour is needed in order to avoid issues such as

    http://bugzilla.kernel.org/show_bug.cgi?id=7178

    Signed-off-by: Trond Myklebust
    Cc: Miklos Szeredi
    Cc: Maneesh Soni
    Cc: Dipankar Sarma
    Cc: Neil Brown
    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     

12 Oct, 2006

1 commit

  • The attached patch destroys all the dentries attached to a superblock in one go
    by:

    (1) Destroying the tree rooted at s_root.

    (2) Destroying every entry in the anon list, one at a time.

    (3) Each entry in the anon list has its subtree consumed from the leaves
    inwards.

    This reduces the amount of work generic_shutdown_super() does, and avoids
    iterating through the dentry_unused list.

    Note that locking is almost entirely absent in the shrink_dcache_for_umount*()
    functions added by this patch. This is because:

    (1) at the point the filesystem calls generic_shutdown_super(), it is not
    permitted to further touch the superblock's set of dentries, and nor may
    it remove aliases from inodes;

    (2) the dcache memory shrinker now skips dentries that are being unmounted;
    and

    (3) the superblock no longer has any external references through which the VFS
    can reach it.

    Given these points, the only locking we need to do is when we remove dentries
    from the unused list and the name hashes, which we do a directory's worth at a
    time.

    We also don't need to guard against reference counts going to zero unexpectedly
    and removing bits of the tree we're working on as nothing else can call dput().

    A cut down version of dentry_iput() has been folded into
    shrink_dcache_for_umount_subtree() function. Apart from not needing to unlock
    things, it also doesn't need to check for inotify watches.

    In this version of the patch, the complaint about a dentry still being in use
    has been expanded from a single BUG_ON() and now gives much more information.

    Signed-off-by: David Howells
    Acked-by: NeilBrown
    Acked-by: Ian Kent
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

04 Oct, 2006

1 commit

  • There is a possible race in d_splice_alias. Though __d_find_alias(inode, 1)
    will only return a dentry with DCACHE_DISCONNECTED set, it is possible for it
    to get cleared before the BUG_ON, and it is is not possible to lock against
    that.

    There are a couple of problems here. Firstly, the code doesn't match the
    comment. The comment describes a 'disconnected' dentry as being IS_ROOT as
    well as DCACHE_DISCONNECTED, however there is not testing of IS_ROOT anythere.

    A dentry is marked DCACHE_DISCONNECTED when allocated with d_alloc_anon, and
    remains DCACHE_DISCONNECTED while a path is built up towards the root. So a
    dentry can have a valid name and a valid parent and even grandparent, but will
    still be DCACHE_DISCONNECTED until a path to the root is created. Once the
    path to the root is complete, everything in the path gets DCACHE_DISCONNECTED
    cleared. So the fact that DCACHE_DISCONNECTED isn't enough to say that a
    dentry is free to be spliced in with a given name. This can only be allowed
    if the dentry does not yet have a name, so the IS_ROOT test is needed too.

    However even adding that test to __d_find_alias isn't enough. As
    d_splice_alias drops dcache_lock before calling d_move to perform the splice,
    it could race with another thread calling d_splice_alias to splice the inode
    in with a different name in a different part of the tree (in the case where a
    file has hard links). So that splicing code is only really safe for
    directories (as we know that directories only have one link). For
    directories, the caller of d_splice_alias will be holding i_mutex on the
    (unique) parent so there is no room for a race.

    A consequence of this is that a non-directory will never benefit from being
    spliced into a pre-exisiting dentry, but that isn't a problem. It is
    perfectly OK for a non-directory to have multiple dentries, some anonymous,
    some not. And the comment for d_splice_alias says that it only happens for
    directories anyway.

    Signed-off-by: Neil Brown
    Cc: Christoph Hellwig
    Cc: Al Viro
    Cc: Dipankar Sarma
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

01 Oct, 2006

1 commit


23 Sep, 2006

1 commit

  • The attached patch adds a new directory cache management function that prepares
    a disconnected anonymous function to be connected into the dentry tree. The
    anonymous dentry is transferred the name and parentage from another dentry.

    The following changes were made in [try #2]:

    (*) d_materialise_dentry() now switches the parentage of the two nodes around
    correctly when one or other of them is self-referential.

    The following changes were made in [try #7]:

    (*) d_instantiate_unique() has had the interior part split out as function
    __d_instantiate_unique(). Callers of this latter function must be holding
    the appropriate locks.

    (*) _d_rehash() has been added as a wrapper around __d_rehash() to call it
    with the most obvious hash list (the one from the name). d_rehash() now
    calls _d_rehash().

    (*) d_materialise_dentry() is now __d_materialise_dentry() and is static.

    (*) d_materialise_unique() added to perform the combination of d_find_alias(),
    d_materialise_dentry() and d_add_unique() that the NFS client was doing
    twice, all within a single dcache_lock critical section. This reduces the
    number of times two different spinlocks were being accessed.

    The following further changes were made:

    (*) Add the dentries onto their parents d_subdirs lists.

    Signed-Off-By: David Howells
    Signed-off-by: Trond Myklebust

    David Howells
     

04 Jul, 2006

2 commits


01 Jul, 2006

1 commit


27 Jun, 2006

2 commits

  • This patch converts the combination of list_del(A) and list_add(A, B) to
    list_move(A, B).

    Cc: Greg Kroah-Hartman
    Cc: Ram Pai
    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     
  • This patch converts list_add(A, B.prev) to list_add_tail(A, &B) for
    readability.

    Acked-by: Karsten Keil
    Cc: Jan Harkes
    Acked-by: Jan Kara
    AOLed-by: David Woodhouse
    Cc: Sridhar Samudrala
    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

26 Jun, 2006

1 commit

  • likely profiling shows that the following is a miss.

    After boot:
    [+- ] Type | # True | # False | Function:Filename@Line
    +unlikely | 1074| 0 prune_dcache()@:fs/dcache.c@409

    After a bonnie++ run:
    +unlikely | 66716| 19584 prune_dcache()@:fs/dcache.c@409

    So remove it.

    Signed-off-by: Hua Zhong
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hua Zhong
     

23 Jun, 2006

3 commits

  • Extend the get_sb() filesystem operation to take an extra argument that
    permits the VFS to pass in the target vfsmount that defines the mountpoint.

    The filesystem is then required to manually set the superblock and root dentry
    pointers. For most filesystems, this should be done with simple_set_mnt()
    which will set the superblock pointer and then set the root dentry to the
    superblock's s_root (as per the old default behaviour).

    The get_sb() op now returns an integer as there's now no need to return the
    superblock pointer.

    This patch permits a superblock to be implicitly shared amongst several mount
    points, such as can be done with NFS to avoid potential inode aliasing. In
    such a case, simple_set_mnt() would not be called, and instead the mnt_root
    and mnt_sb would be set directly.

    The patch also makes the following changes:

    (*) the get_sb_*() convenience functions in the core kernel now take a vfsmount
    pointer argument and return an integer, so most filesystems have to change
    very little.

    (*) If one of the convenience function is not used, then get_sb() should
    normally call simple_set_mnt() to instantiate the vfsmount. This will
    always return 0, and so can be tail-called from get_sb().

    (*) generic_shutdown_super() now calls shrink_dcache_sb() to clean up the
    dcache upon superblock destruction rather than shrink_dcache_anon().

    This is required because the superblock may now have multiple trees that
    aren't actually bound to s_root, but that still need to be cleaned up. The
    currently called functions assume that the whole tree is rooted at s_root,
    and that anonymous dentries are not the roots of trees which results in
    dentries being left unculled.

    However, with the way NFS superblock sharing are currently set to be
    implemented, these assumptions are violated: the root of the filesystem is
    simply a dummy dentry and inode (the real inode for '/' may well be
    inaccessible), and all the vfsmounts are rooted on anonymous[*] dentries
    with child trees.

    [*] Anonymous until discovered from another tree.

    (*) The documentation has been adjusted, including the additional bit of
    changing ext2_* into foo_* in the documentation.

    [akpm@osdl.org: convert ipath_fs, do other stuff]
    Signed-off-by: David Howells
    Acked-by: Al Viro
    Cc: Nathan Scott
    Cc: Roland Dreier
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • - Add description of d_lock handling to comments over prune_one_dentry().

    - It has three callsites - uninline it, saving 200 bytes of text.

    Cc: Jan Blunck
    Cc: Kirill Korotaev
    Cc: Olaf Hering
    Cc: Balbir Singh
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • The race is that the shrink_dcache_memory shrinker could get called while a
    filesystem is being unmounted, and could try to prune a dentry belonging to
    that filesystem.

    If it does, then it will call in to iput on the inode while the dentry is
    no longer able to be found by the umounting process. If iput takes a
    while, generic_shutdown_super could get all the way though
    shrink_dcache_parent and shrink_dcache_anon and invalidate_inodes without
    ever waiting on this particular inode.

    Eventually the superblock gets freed anyway and if the iput tried to touch
    it (which some filesystems certainly do), it will lose. The promised
    "Self-destruct in 5 seconds" doesn't lead to a nice day.

    The race is closed by holding s_umount while calling prune_one_dentry on
    someone else's dentry. As a down_read_trylock is used,
    shrink_dcache_memory will no longer try to prune the dentry of a filesystem
    that is being unmounted, and unmount will not be able to start until any
    such active prune_one_dentry completes.

    This requires that prune_dcache *knows* which filesystem (if any) it is
    doing the prune on behalf of so that it can be careful of other
    filesystems. shrink_dcache_memory isn't called it on behalf of any
    filesystem, and so is careful of everything.

    shrink_dcache_anon is now passed a super_block rather than the s_anon list
    out of the superblock, so it can get the s_anon list itself, and can pass
    the superblock down to prune_dcache.

    If prune_dcache finds a dentry that it cannot free, it leaves it where it
    is (at the tail of the list) and exits, on the assumption that some other
    thread will be removing that dentry soon. To try to make sure that some
    work gets done, a limited number of dnetries which are untouchable are
    skipped over while choosing the dentry to work on.

    I believe this race was first found by Kirill Korotaev.

    Cc: Jan Blunck
    Acked-by: Kirill Korotaev
    Cc: Olaf Hering
    Acked-by: Balbir Singh
    Signed-off-by: Neil Brown
    Signed-off-by: Balbir Singh
    Acked-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

01 Apr, 2006

2 commits

  • It is very common to hash a dentry and then to call lookup. If we take fs
    specific hash functions into account the full hash logic can get ugly.
    Further full_name_hash as an inline function is almost 100 bytes on x86 so
    having a non-inline choice in some cases can measurably decrease code size.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     
  • IN_DELETE events are no longer generated for the removal of a file from a
    watched directory.

    This seems to be a result of clearing DCACHE_INOTIFY_PARENT_WATCHED in
    d_delete() directly before calling fsnotify_nameremove().

    Assuming the flag doesn't need to be cleared before dentry_iput(), this
    should do the trick.

    Signed-off-by: Amy Griffis
    Cc: John McCutchan
    Acked-by: Robert Love
    Cc: Nick Piggin
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Amy Griffis
     

27 Mar, 2006

4 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial:
    drivers/char/ftape/lowlevel/fdc-io.c: Correct a comment
    Kconfig help: MTD_JEDECPROBE already supports Intel
    Remove ugly debugging stuff
    do_mounts.c: Minor ROOT_DEV comment cleanup
    BUG_ON() Conversion in drivers/s390/block/dasd_devmap.c
    BUG_ON() Conversion in mm/mempool.c
    BUG_ON() Conversion in mm/memory.c
    BUG_ON() Conversion in kernel/fork.c
    BUG_ON() Conversion in ipc/sem.c
    BUG_ON() Conversion in fs/ext2/
    BUG_ON() Conversion in fs/hfs/
    BUG_ON() Conversion in fs/dcache.c
    BUG_ON() Conversion in fs/buffer.c
    BUG_ON() Conversion in input/serio/hp_sdc_mlc.c
    BUG_ON() Conversion in md/dm-table.c
    BUG_ON() Conversion in md/dm-path-selector.c
    BUG_ON() Conversion in drivers/isdn
    BUG_ON() Conversion in drivers/char
    BUG_ON() Conversion in drivers/mtd/

    Linus Torvalds
     
  • Signed-off-by: Adrian Bunk

    Artem B. Bityuckiy
     
  • I discovered on oprofile hunting on a SMP platform that dentry lookups were
    slowed down because d_hash_mask, d_hash_shift and dentry_hashtable were in
    a cache line that contained inodes_stat. So each time inodes_stats is
    changed by a cpu, other cpus have to refill their cache line.

    This patch moves some variables to the __read_mostly section, in order to
    avoid false sharing. RCU dentry lookups can go full speed.

    Signed-off-by: Eric Dumazet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     
  • this changes if() BUG(); constructs to BUG_ON() which is
    cleaner and can better optimized away

    Signed-off-by: Eric Sesterhenn
    Signed-off-by: Adrian Bunk

    Eric Sesterhenn
     

26 Mar, 2006

3 commits

  • This patch reduces scheduling latency in shrink_dcache_sb() noticed during
    remounting of big partitions with many cached dentries. The same latency
    fix was applied to select_parent() long ago.

    Signed-off-by: Denis Lunev
    Signed-off-by: Pavel Emelianov
    Signed-off-by: Kirill Korotaev
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kirill Korotaev
     
  • Previous inotify work avoidance is good when inotify is completely unused,
    but it breaks down if even a single watch is in place anywhere in the
    system. Robin Holt notices that udev is one such culprit - it slows down a
    512-thread application on a 512 CPU system from 6 seconds to 22 minutes.

    Solve this by adding a flag in the dentry that tells inotify whether or not
    its parent inode has a watch on it. Event queueing to parent will skip
    taking locks if this flag is cleared. Setting and clearing of this flag on
    all child dentries versus event delivery: this is no in terms of race
    cases, and that was shown to be equivalent to always performing the check.

    The essential behaviour is that activity occuring _after_ a watch has been
    added and _before_ it has been removed, will generate events.

    Signed-off-by: Nick Piggin
    Cc: Robert Love
    Cc: John McCutchan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Piggin
     
  • The attached patch optimises d_find_alias() to only take the spinlock if
    there's anything in the the inode's alias list. If there isn't, it returns
    NULL immediately.

    With respect to the superblock sharing patch, this should reduce by one the
    number of times the dcache_lock is taken by nfs_lookup() for ordinary
    directory lookups.

    Only in the case where there's already a dentry for particular directory inode
    (such as might happen when another mountpoint is rooted at that dentry) will
    the lock then be taken the extra time.

    Signed-off-by: David Howells
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

24 Mar, 2006

1 commit

  • Change the kmem_cache_create calls for certain slab caches to support cpuset
    memory spreading.

    See the previous patches, cpuset_mem_spread, for an explanation of cpuset
    memory spreading, and cpuset_mem_spread_slab_cache for the slab cache support
    for memory spreading.

    The slab caches marked for now are: dentry_cache, inode_cache, some xfs slab
    caches, and buffer_head. This list may change over time. In particular,
    other file system types that are used extensively on large NUMA systems may
    want to allow for spreading their directory and inode slab cache entries.

    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

09 Mar, 2006

1 commit

  • I have benchmarked this on an x86_64 NUMA system and see no significant
    performance difference on kernbench. Tested on both x86_64 and powerpc.

    The way we do file struct accounting is not very suitable for batched
    freeing. For scalability reasons, file accounting was
    constructor/destructor based. This meant that nr_files was decremented
    only when the object was removed from the slab cache. This is susceptible
    to slab fragmentation. With RCU based file structure, consequent batched
    freeing and a test program like Serge's, we just speed this up and end up
    with a very fragmented slab -

    llm22:~ # cat /proc/sys/fs/file-nr
    587730 0 758844

    At the same time, I see only a 2000+ objects in filp cache. The following
    patch I fixes this problem.

    This patch changes the file counting by removing the filp_count_lock.
    Instead we use a separate percpu counter, nr_files, for now and all
    accesses to it are through get_nr_files() api. In the sysctl handler for
    nr_files, we populate files_stat.nr_files before returning to user.

    Counting files as an when they are created and destroyed (as opposed to
    inside slab) allows us to correctly count open files with RCU.

    Signed-off-by: Dipankar Sarma
    Cc: "Paul E. McKenney"
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     

04 Feb, 2006

1 commit


15 Jan, 2006

1 commit


11 Jan, 2006

1 commit

  • 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

  • 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

  • - ->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

  • 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