Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 01 4月, 2012 7 次提交
  3. 23 3月, 2012 3 次提交
  5. 22 3月, 2012 1 次提交
  7. 21 3月, 2012 2 次提交
  9. 20 3月, 2012 1 次提交
  11. 11 3月, 2012 2 次提交
  13. 09 3月, 2012 1 次提交
  15. 03 3月, 2012 3 次提交
    • L
      vfs: export full_name_hash() function to modules · ae942ae7
      由 Linus Torvalds 提交于 
      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: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ae942ae7
    • L
      vfs: split up name hashing in link_path_walk() into helper function · 200e9ef7
      由 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: NLinus Torvalds <torvalds@linux-foundation.org>
      200e9ef7
    • L
      vfs: uninline full_name_hash() · 0145acc2
      由 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: NLinus Torvalds <torvalds@linux-foundation.org>
      0145acc2
  17. 29 2月, 2012 1 次提交
  19. 14 2月, 2012 1 次提交
  21. 18 1月, 2012 1 次提交
  23. 04 1月, 2012 10 次提交
  25. 08 11月, 2011 1 次提交
    • A
      VFS: we need to set LOOKUP_JUMPED on mountpoint crossing · a3fbbde7
      由 Al Viro 提交于 
      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 <<'EOF'
    #include <unistd.h>
    #include <fcntl.h>
    #include <stdio.h>
    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: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3fbbde7
  27. 02 11月, 2011 1 次提交
    • A
      readlinkat: ensure we return ENOENT for the empty pathname for normal lookups · 1fa1e7f6
      由 Andy Whitcroft 提交于 
      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 65cfc672
  Author: Al Viro <viro@zeniv.linux.org.uk>
  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: NAndy Whitcroft <apw@canonical.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: <stable@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      1fa1e7f6
  29. 28 10月, 2011 4 次提交
  31. 27 9月, 2011 1 次提交
    • L
      vfs: remove LOOKUP_NO_AUTOMOUNT flag · b6c8069d
      由 Linus Torvalds 提交于 
      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: NIan Kent <raven@themaw.net>
Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b6c8069d