25 Mar, 2012

1 commit

  • Pull cleanup of fs/ and lib/ users of module.h from Paul Gortmaker:
    "Fix up files in fs/ and lib/ dirs to only use module.h if they really
    need it.

    These are trivial in scope vs the work done previously. We now have
    things where any few remaining cleanups can be farmed out to arch or
    subsystem maintainers, and I have done so when possible. What is
    remaining here represents the bits that don't clearly lie within a
    single arch/subsystem boundary, like the fs dir and the lib dir.

    Some duplicate includes arising from overlapping fixes from
    independent subsystem maintainer submissions are also quashed."

    Fix up trivial conflicts due to clashes with other include file cleanups
    (including some due to the previous bug.h cleanup pull).

    * tag 'module-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    lib: reduce the use of module.h wherever possible
    fs: reduce the use of module.h wherever possible
    includecheck: delete any duplicate instances of module.h

    Linus Torvalds
     

23 Mar, 2012

4 commits

  • While doing the fs/namei.c cleanups, I ran sparse on it, and it pointed
    out other large integers and a couple of cases of us using '0' instead
    of the proper 'NULL'.

    Sparse still doesn't understand some of the conditional locking going
    on, but that's no excuse for not fixing up the trivial stuff.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • In commit commit 1de5b41cd3b2 ("fs/namei.c: fix warnings on 32-bit")
    Andrew said that there must be a tidier way of doing this.

    This is that tidier way.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • We want it to match what hash_name() is doing, which means extra
    multiply by 9 in this case...

    Reported-and-Tested-by: Konrad Rzeszutek Wilk
    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Merge first batch of patches from Andrew Morton:
    "A few misc things and all the MM queue"

    * emailed from Andrew Morton : (92 commits)
    memcg: avoid THP split in task migration
    thp: add HPAGE_PMD_* definitions for !CONFIG_TRANSPARENT_HUGEPAGE
    memcg: clean up existing move charge code
    mm/memcontrol.c: remove unnecessary 'break' in mem_cgroup_read()
    mm/memcontrol.c: remove redundant BUG_ON() in mem_cgroup_usage_unregister_event()
    mm/memcontrol.c: s/stealed/stolen/
    memcg: fix performance of mem_cgroup_begin_update_page_stat()
    memcg: remove PCG_FILE_MAPPED
    memcg: use new logic for page stat accounting
    memcg: remove PCG_MOVE_LOCK flag from page_cgroup
    memcg: simplify move_account() check
    memcg: remove EXPORT_SYMBOL(mem_cgroup_update_page_stat)
    memcg: kill dead prev_priority stubs
    memcg: remove PCG_CACHE page_cgroup flag
    memcg: let css_get_next() rely upon rcu_read_lock()
    cgroup: revert ss_id_lock to spinlock
    idr: make idr_get_next() good for rcu_read_lock()
    memcg: remove unnecessary thp check in page stat accounting
    memcg: remove redundant returns
    memcg: enum lru_list lru
    ...

    Linus Torvalds
     

22 Mar, 2012

3 commits

  • i386 allnoconfig:

    fs/namei.c: In function 'has_zero':
    fs/namei.c:1617: warning: integer constant is too large for 'unsigned long' type
    fs/namei.c:1617: warning: integer constant is too large for 'unsigned long' type
    fs/namei.c: In function 'hash_name':
    fs/namei.c:1635: warning: integer constant is too large for 'unsigned long' type

    There must be a tidier way of doing this.

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

    Andrew Morton
     
  • Pull vfs pile 1 from Al Viro:
    "This is _not_ all; in particular, Miklos' and Jan's stuff is not there
    yet."

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (64 commits)
    ext4: initialization of ext4_li_mtx needs to be done earlier
    debugfs-related mode_t whack-a-mole
    hfsplus: add an ioctl to bless files
    hfsplus: change finder_info to u32
    hfsplus: initialise userflags
    qnx4: new helper - try_extent()
    qnx4: get rid of qnx4_bread/qnx4_getblk
    take removal of PF_FORKNOEXEC to flush_old_exec()
    trim includes in inode.c
    um: uml_dup_mmap() relies on ->mmap_sem being held, but activate_mm() doesn't hold it
    um: embed ->stub_pages[] into mmu_context
    gadgetfs: list_for_each_safe() misuse
    ocfs2: fix leaks on failure exits in module_init
    ecryptfs: make register_filesystem() the last potential failure exit
    ntfs: forgets to unregister sysctls on register_filesystem() failure
    logfs: missing cleanup on register_filesystem() failure
    jfs: mising cleanup on register_filesystem() failure
    make configfs_pin_fs() return root dentry on success
    configfs: configfs_create_dir() has parent dentry in dentry->d_parent
    configfs: sanitize configfs_create()
    ...

    Linus Torvalds
     
  • Pull kmap_atomic cleanup from Cong Wang.

    It's been in -next for a long time, and it gets rid of the (no longer
    used) second argument to k[un]map_atomic().

    Fix up a few trivial conflicts in various drivers, and do an "evil
    merge" to catch some new uses that have come in since Cong's tree.

    * 'kmap_atomic' of git://github.com/congwang/linux: (59 commits)
    feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal
    highmem: kill all __kmap_atomic() [swarren@nvidia.com: highmem: Fix ARM build break due to __kmap_atomic rename]
    drbd: remove the second argument of k[un]map_atomic()
    zcache: remove the second argument of k[un]map_atomic()
    gma500: remove the second argument of k[un]map_atomic()
    dm: remove the second argument of k[un]map_atomic()
    tomoyo: remove the second argument of k[un]map_atomic()
    sunrpc: remove the second argument of k[un]map_atomic()
    rds: remove the second argument of k[un]map_atomic()
    net: remove the second argument of k[un]map_atomic()
    mm: remove the second argument of k[un]map_atomic()
    lib: remove the second argument of k[un]map_atomic()
    power: remove the second argument of k[un]map_atomic()
    kdb: remove the second argument of k[un]map_atomic()
    udf: remove the second argument of k[un]map_atomic()
    ubifs: remove the second argument of k[un]map_atomic()
    squashfs: remove the second argument of k[un]map_atomic()
    reiserfs: remove the second argument of k[un]map_atomic()
    ocfs2: remove the second argument of k[un]map_atomic()
    ntfs: remove the second argument of k[un]map_atomic()
    ...

    Linus Torvalds
     

21 Mar, 2012

2 commits


20 Mar, 2012

2 commits

  • Acked-by: Benjamin LaHaise
    Signed-off-by: Cong Wang

    Cong Wang
     
  • * branch 'dcache-word-accesses':
    vfs: use 'unsigned long' accesses for dcache name comparison and hashing

    This does the name hashing and lookup using word-sized accesses when
    that is efficient, namely on x86 (although any little-endian machine
    with good unaligned accesses would do).

    It does very much depend on little-endian logic, but it's a very hot
    couple of functions under some real loads, and this patch improves the
    performance of __d_lookup_rcu() and link_path_walk() by up to about 30%.
    Giving a 10% improvement on some very pathname-heavy benchmarks.

    Because we do make unaligned accesses past the filename, the
    optimization is disabled when CONFIG_DEBUG_PAGEALLOC is active, and we
    effectively depend on the fact that on x86 we don't really ever have the
    last page of usable RAM followed immediately by any IO memory (due to
    ACPI tables, BIOS buffer areas etc).

    Some of the bit operations we do are a bit "subtle". It's commented,
    but you do need to really think about the code. Or just consider it
    black magic.

    Thanks to people on G+ for some of the optimized bit tricks.

    Linus Torvalds
     

11 Mar, 2012

2 commits

  • complete_walk() returns either ECHILD or ESTALE. do_last() turns this into
    ECHILD unconditionally. If not in RCU mode, this error will reach userspace
    which is complete nonsense.

    Signed-off-by: Miklos Szeredi
    CC: stable@vger.kernel.org
    Signed-off-by: Al Viro

    Miklos Szeredi
     
  • complete_walk() already puts nd->path, no need to do it again at cleanup time.

    This would result in Oopses if triggered, apparently the codepath is not too
    well exercised.

    Signed-off-by: Miklos Szeredi
    CC: stable@vger.kernel.org
    Signed-off-by: Al Viro

    Miklos Szeredi
     

09 Mar, 2012

1 commit


03 Mar, 2012

3 commits

  • Commit 5707c87f "vfs: uninline full_name_hash()" broke the modular
    build, because it needs exporting now that it isn't inlined any more.

    Reported-by: Tetsuo Handa
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • The code in link_path_walk() that finds out the length and the hash of
    the next path component is some of the hottest code in the kernel. And
    I have a version of it that does things at the full width of the CPU
    wordsize at a time, but that means that we *really* want to split it up
    into a separate helper function.

    So this re-organizes the code a bit and splits the hashing part into a
    helper function called "hash_name()". It returns the length of the
    pathname component, while at the same time computing and writing the
    hash to the appropriate location.

    The code generation is slightly changed by this patch, but generally for
    the better - and the added abstraction actually makes the code easier to
    read too. And the new interface is well suited for replacing just the
    "hash_name()" function with alternative implementations.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • .. and also use it in lookup_one_len() rather than open-coding it.

    There aren't any performance-critical users, so inlining it is silly.
    But it wouldn't matter if it wasn't for the fact that the word-at-a-time
    dentry name patches want to conditionally replace the function, and
    uninlining it sets the stage for that.

    So again, this is a preparatory patch that doesn't change any semantics,
    and only prepares for a much cleaner and testable word-at-a-time dentry
    name accessor patch.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

29 Feb, 2012

1 commit


14 Feb, 2012

1 commit


18 Jan, 2012

1 commit


07 Jan, 2012

1 commit


04 Jan, 2012

10 commits


08 Nov, 2011

1 commit

  • Mountpoint crossing is similar to following procfs symlinks - we do
    not get ->d_revalidate() called for dentry we have arrived at, with
    unpleasant consequences for NFS4.

    Simple way to reproduce the problem in mainline:

    cat >/tmp/a.c <
    #include
    #include
    main()
    {
    struct flock fl = {.l_type = F_RDLCK, .l_whence = SEEK_SET, .l_len = 1};
    if (fcntl(0, F_SETLK, &fl))
    perror("setlk");
    }
    EOF
    cc /tmp/a.c -o /tmp/test

    then on nfs4:

    mount --bind file1 file2
    /tmp/test < file1 # ok
    /tmp/test < file2 # spews "setlk: No locks available"...

    What happens is the missing call of ->d_revalidate() after mountpoint
    crossing and that's where NFS4 would issue OPEN request to server.

    The fix is simple - treat mountpoint crossing the same way we deal with
    following procfs-style symlinks. I.e. set LOOKUP_JUMPED...

    Cc: stable@kernel.org
    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

02 Nov, 2011

1 commit

  • Since the commit below which added O_PATH support to the *at() calls, the
    error return for readlink/readlinkat for the empty pathname has switched
    from ENOENT to EINVAL:

    commit 65cfc6722361570bfe255698d9cd4dccaf47570d
    Author: Al Viro
    Date: Sun Mar 13 15:56:26 2011 -0400

    readlinkat(), fchownat() and fstatat() with empty relative pathnames

    This is both unexpected for userspace and makes readlink/readlinkat
    inconsistant with all other interfaces; and inconsistant with our stated
    return for these pathnames.

    As the readlinkat call does not have a flags parameter we cannot use the
    AT_EMPTY_PATH approach used in the other calls. Therefore expose whether
    the original path is infact entry via a new user_path_at_empty() path
    lookup function. Use this to determine whether to default to EINVAL or
    ENOENT for failures.

    Addresses http://bugs.launchpad.net/bugs/817187

    [akpm@linux-foundation.org: remove unused getname_flags()]
    Signed-off-by: Andy Whitcroft
    Cc: Christoph Hellwig
    Cc: Al Viro
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Christoph Hellwig

    Andy Whitcroft
     

28 Oct, 2011

4 commits


27 Sep, 2011

2 commits

  • That flag no longer makes sense, since we don't look up automount points
    as eagerly any more. Additionally, it turns out that the NO_AUTOMOUNT
    handling was buggy to begin with: it would avoid automounting even for
    cases where we really *needed* to do the automount handling, and could
    return ENOENT for autofs entries that hadn't been instantiated yet.

    With our new non-eager automount semantics, one discussion has been
    about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
    newfstatat() and fstatat64() system calls), but it's probably not worth
    it: you can always force at least directory automounting by simply
    adding the final '/' to the filename, which works for *all* of the stat
    family system calls, old and new.

    So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
    result of our bad default behavior.

    Acked-by: Ian Kent
    Acked-by: Trond Myklebust
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Since we've now turned around and made LOOKUP_FOLLOW *not* force an
    automount, we want to add the ability to force an automount event on
    lookup even if we don't happen to have one of the other flags that force
    it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)

    Most cases will never want to use this, since you'd normally want to
    delay automounting as long as possible, which usually implies
    LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
    the automount any more).

    But Trond argued sufficiently forcefully that at a minimum bind mounting
    a file and quotactl will want to force the automount lookup. Some other
    cases (like nfs_follow_remote_path()) could use it too, although
    LOOKUP_DIRECTORY would work there as well.

    This commit just adds the flag and logic, no users yet, though. It also
    doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
    was made irrelevant by the same change that made us not follow on
    LOOKUP_FOLLOW.

    Cc: Trond Myklebust
    Cc: Ian Kent
    Cc: Jeff Layton
    Cc: Miklos Szeredi
    Cc: David Howells
    Cc: Al Viro
    Cc: Greg KH
    Signed-off-by: Linus Torvalds

    Linus Torvalds