23 Apr, 2008

2 commits

  • Add a new function:

    seq_file_root()

    This is similar to seq_path(), but calculates the path relative to the
    given root, instead of current->fs->root. If the path was unreachable
    from root, then modify the root parameter to reflect this.

    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro

    Miklos Szeredi
     
  • [mszeredi@suse.cz] split big patch into managable chunks

    Add the following functions:

    dentry_path()
    seq_dentry()

    These are similar to d_path() and seq_path(). But instead of
    calculating the path within a mount namespace, they calculate the path
    from the root of the filesystem to a given dentry, ignoring mounts
    completely.

    Signed-off-by: Ram Pai
    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro

    Ram Pai
     

15 Feb, 2008

5 commits

  • Extract the common code to remove a dentry from the lru into a new function
    dentry_lru_remove().

    Two call sites used list_del() instead of list_del_init(). AFAIK the
    performance of both is the same. dentry_lru_remove() does a list_del_init().

    As a result dentry->d_lru is now always empty when a dentry is freed.

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

    Christoph Lameter
     
  • d_path() is used on a pair. Lets use a struct path to
    reflect this.

    [akpm@linux-foundation.org: fix build in mm/memory.c]
    Signed-off-by: Jan Blunck
    Acked-by: Bryan Wu
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Cc: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     
  • Move and update d_path() kernel API documentation.

    Signed-off-by: Jan Blunck
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     
  • All callers to __d_path pass the dentry and vfsmount of a struct path to
    __d_path. Pass the struct path directly, instead.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Jan Blunck
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     
  • * Use struct path in fs_struct.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Jan Blunck
    Acked-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     

07 Feb, 2008

2 commits

  • The inotify debugging code is supposed to verify that the
    DCACHE_INOTIFY_PARENT_WATCHED scalability optimisation does not result in
    notifications getting lost nor extra needless locking generated.

    Unfortunately there are also some races in the debugging code. And it isn't
    very good at finding problems anyway. So remove it for now.

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

    Nick Piggin
     
  • Use hlist_unhashed() instead of opencoded equivalent.

    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

22 Oct, 2007

1 commit

  • Well, it's not especially important that target->d_iname get the contents
    of dentry->d_iname, but it's important that it get initialized with
    *something*, otherwise we're just exposing some random piece of memory to
    anyone who reads the link at /proc//fd/ for the deleted file, when
    it's still held open by someone.

    I've run a test program that copies a short (=36 character) name and see that the first time I run it, without
    this patch, I get unpredicatable results out of /proc//fd/.

    Signed-off-by: J. Bruce Fields
    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     

21 Oct, 2007

1 commit

  • New kind of audit rule predicates: "object is visible in given subtree".
    The part that can be sanely implemented, that is. Limitations:
    * if you have hardlink from outside of tree, you'd better watch
    it too (or just watch the object itself, obviously)
    * if you mount something under a watched tree, tell audit
    that new chunk should be added to watched subtrees
    * if you umount something in a watched tree and it's still mounted
    elsewhere, you will get matches on events happening there. New command
    tells audit to recalculate the trees, trimming such sources of false
    positives.

    Note that it's _not_ about path - if something mounted in several places
    (multiple mount, bindings, different namespaces, etc.), the match does
    _not_ depend on which one we are using for access.

    Signed-off-by: Al Viro

    Al Viro
     

17 Oct, 2007

6 commits

  • Signed-off-by: Denis Cheng
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis Cheng
     
  • This patch makes shrink_dcache_sb consistent with dentry pruning policy.

    On the first pass we iterate over dentry unused list and prepare some
    dentries for removal.

    However, since the existing code moves evicted dentries to the beginning of
    the LRU it can happen that fresh dentries from other superblocks will be
    inserted *before* our dentries.

    This can result in significant slowdown of shrink_dcache_sb(). Moreover,
    for virtual filesystems like unionfs which can call dput() during dentries
    kill existing code results in O(n^2) complexity.

    We observed 2 minutes shrink_dcache_sb() with only 35000 dentries.

    To avoid this effects we propose to isolate sb dentries at the end
    of LRU list.

    Signed-off-by: Denis V. Lunev
    Signed-off-by: Kirill Korotaev
    Signed-off-by: Andrey Mirkin
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis V. Lunev
     
  • As it stands this comment is confusing, and not quite grammatical.

    Signed-off-by: J. Bruce Fields
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     
  • It looks like in the end all pruners want parents removed.

    So remove unused code and function arguments.

    Signed-off-by: Miklos Szeredi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Miklos Szeredi
     
  • Since the mempages parameter is actually not used, they should be removed.

    Now there is only files_init use the mempages parameter,

    files_init(mempages);

    but I don't think the adaptation to mempages in files_init is really
    useful; and if files_init also changed to the prototype void (*func)(void),
    the wrapper vfs_caches_init would also not need the mempages parameter.

    Signed-off-by: Denis Cheng
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis Cheng
     
  • This patch marks a number of allocations that are either short-lived such as
    network buffers or are reclaimable such as inode allocations. When something
    like updatedb is called, long-lived and unmovable kernel allocations tend to
    be spread throughout the address space which increases fragmentation.

    This patch groups these allocations together as much as possible by adding a
    new MIGRATE_TYPE. The MIGRATE_RECLAIMABLE type is for allocations that can be
    reclaimed on demand, but not moved. i.e. they can be migrated by deleting
    them and re-reading the information from elsewhere.

    Signed-off-by: Mel Gorman
    Cc: Andy Whitcroft
    Cc: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

20 Jul, 2007

1 commit

  • Slab destructors were no longer supported after Christoph's
    c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
    BUGs for both slab and slub, and slob never supported them
    either.

    This rips out support for the dtor pointer from kmem_cache_create()
    completely and fixes up every single callsite in the kernel (there were
    about 224, not including the slab allocator definitions themselves,
    or the documentation references).

    Signed-off-by: Paul Mundt

    Paul Mundt
     

18 Jul, 2007

1 commit

  • I can never remember what the function to register to receive VM pressure
    is called. I have to trace down from __alloc_pages() to find it.

    It's called "set_shrinker()", and it needs Your Help.

    1) Don't hide struct shrinker. It contains no magic.
    2) Don't allocate "struct shrinker". It's not helpful.
    3) Call them "register_shrinker" and "unregister_shrinker".
    4) Call the function "shrink" not "shrinker".
    5) Reduce the 17 lines of waffly comments to 13, but document it properly.

    Signed-off-by: Rusty Russell
    Cc: David Chinner
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rusty Russell
     

09 May, 2007

4 commits

  • Remove includes of where it is not used/needed.
    Suggested by Al Viro.

    Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
    sparc64, and arm (all 59 defconfigs).

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • 1) Introduces a new method in 'struct dentry_operations'. This method
    called d_dname() might be called from d_path() to build a pathname for
    special filesystems. It is called without locks.

    Future patches (if we succeed in having one common dentry for all
    pipes/sockets) may need to change prototype of this method, but we now
    use : char *d_dname(struct dentry *dentry, char *buffer, int buflen);

    2) Adds a dynamic_dname() helper function that eases d_dname() implementations

    3) Defines d_dname method for sockets : No more sprintf() at socket
    creation. This is delayed up to the moment someone does an access to
    /proc/pid/fd/...

    4) Defines d_dname method for pipes : No more sprintf() at pipe
    creation. This is delayed up to the moment someone does an access to
    /proc/pid/fd/...

    A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a
    *nice* speedup on my Pentium(M) 1.6 Ghz :

    3.090 s instead of 3.450 s

    Signed-off-by: Eric Dumazet
    Acked-by: Christoph Hellwig
    Acked-by: Linus Torvalds
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     
  • Teach the dentry slab shrinker to aggressively shrink parent dentries when
    shrinking the dentry cache.

    This is done to attempt to improve the situation where the dentry slab cache
    gets a lot of internal fragmentation due to pages containing directory
    dentries. It is expected that this change will cause some of those dentries
    to be reaped earlier, and with less scanning.

    Needs careful testing.

    Cc: Miklos Szeredi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • The time shrink_dcache_parent() takes, grows quadratically with the depth
    of the tree under 'parent'. This starts to get noticable at about 10,000.

    These kinds of depths don't occur normally, and filesystems which invoke
    shrink_dcache_parent() via d_invalidate() seem to have other depth
    dependent timings, so it's not even easy to expose this problem.

    However with FUSE it's easy to create a deep tree and d_invalidate()
    will also get called. This can make a syscall hang for a very long
    time.

    This is the original discovery of the problem by Russ Cox:

    http://article.gmane.org/gmane.comp.file-systems.fuse.devel/3826

    The following patch fixes the quadratic behavior, by optionally allowing
    prune_dcache() to prune ancestors of a dentry in one go, instead of doing
    it one at a time.

    Common code in dput() and prune_one_dentry() is extracted into a new helper
    function d_kill().

    shrink_dcache_parent() as well as shrink_dcache_sb() are converted to use
    the ancestry-pruner option. Only for shrink_dcache_memory() is this
    behavior not desirable, so it keeps using the old algorithm.

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

    Miklos Szeredi
     

08 May, 2007

1 commit

  • This patch provides a new macro

    KMEM_CACHE(, )

    to simplify slab creation. KMEM_CACHE creates a slab with the name of the
    struct, with the size of the struct and with the alignment of the struct.
    Additional slab flags may be specified if necessary.

    Example

    struct test_slab {
    int a,b,c;
    struct list_head;
    } __cacheline_aligned_in_smp;

    test_slab_cache = KMEM_CACHE(test_slab, SLAB_PANIC)

    will create a new slab named "test_slab" of the size sizeof(struct
    test_slab) and aligned to the alignment of test slab. If it fails then we
    panic.

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

    Christoph Lameter
     

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