30 Apr, 2010

1 commit

  • * 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6:
    nfs: fix memory leak in nfs_get_sb with CONFIG_NFS_V4
    nfs: fix some issues in nfs41_proc_reclaim_complete()
    NFS: Ensure that nfs_wb_page() waits for Pg_writeback to clear
    NFS: Fix an unstable write data integrity race
    nfs: testing for null instead of ERR_PTR()
    NFS: rsize and wsize settings ignored on v4 mounts
    NFSv4: Don't attempt an atomic open if the file is a mountpoint
    SUNRPC: Fix a bug in rpcauth_prune_expired

    Linus Torvalds
     

29 Apr, 2010

1 commit

  • If dentry found stale happens to be a root of disconnected tree, we
    can't d_drop() it; its d_hash is actually part of s_anon and d_drop()
    would simply hide it from shrink_dcache_for_umount(), leading to
    all sorts of fun, including busy inodes on umount and oopsen after
    that.

    Bug had been there since at least 2006 (commit c636eb already has it),
    so it's definitely -stable fodder.

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

    Al Viro
     

23 Apr, 2010

1 commit


10 Apr, 2010

1 commit


11 Mar, 2010

1 commit


06 Mar, 2010

1 commit


07 Jan, 2010

1 commit

  • Recent change is missing to update "rehash". With that change, it will
    become the cause of adding dentry to hash twice.

    This explains the reason of Oops (dereference the freed dentry in
    __d_lookup()) on my machine.

    Signed-off-by: OGAWA Hirofumi
    Reported-by: Marvin
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Trond Myklebust

    OGAWA Hirofumi
     

04 Dec, 2009

4 commits


26 Oct, 2009

1 commit


22 Jul, 2009

1 commit

  • We just had a case in which a buggy server occasionally returns the wrong
    attributes during an OPEN call. While the client does catch this sort of
    condition in nfs4_open_done(), and causes the nfs4_atomic_open() to return
    -EISDIR, the logic in nfs_atomic_lookup() is broken, since it causes a
    fallback to an ordinary lookup instead of just returning the error.

    When the buggy server then returns a regular file for the fallback lookup,
    the VFS allows the open, and bad things start to happen, since the open
    file doesn't have any associated NFSv4 state.

    The fix is firstly to return the EISDIR/ENOTDIR errors immediately, and
    secondly to ensure that we are always careful when dereferencing the
    nfs_open_context state pointer.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

13 Jul, 2009

1 commit

  • * Remove smp_lock.h from files which don't need it (including some headers!)
    * Add smp_lock.h to files which do need it
    * Make smp_lock.h include conditional in hardirq.h
    It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

    This will make hardirq.h inclusion cheaper for every PREEMPT=n config
    (which includes allmodconfig/allyesconfig, BTW)

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

19 May, 2009

1 commit

  • The problem is that permission checking is skipped if atomic open is
    possible, but when exec opens a file, it just opens it O_READONLY which
    means EXEC permission will not be checked at that time.

    This problem is observed by the following sequence (executed as root):

    mount -t nfs4 server:/ /mnt4
    echo "ls" >/mnt4/foo
    chmod 744 /mnt4/foo
    su guest -c "mnt4/foo"

    Signed-off-by: Frank Filz
    Signed-off-by: Trond Myklebust
    Cc: stable@kernel.org
    Tested-by: Eugene Teo
    Signed-off-by: Linus Torvalds

    Frank Filz
     

02 Apr, 2009

1 commit


28 Mar, 2009

1 commit


20 Mar, 2009

1 commit


11 Mar, 2009

1 commit

  • Hi Trond,

    I have been looking at a bugreport where trying to open applications on KDE
    on a NFS mounted home fails temporarily. There have been multiple reports on
    different kernel versions pointing to this common issue:
    http://bugzilla.kernel.org/show_bug.cgi?id=12557
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/269954
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508866.html

    This issue can be reproducible consistently by doing this on a NFS mounted
    home (KDE):
    1. Open 2 xterm sessions
    2. From one of the xterm session, do "ssh -X "
    3. "stat ~/.Xauthority" on the remote SSH session
    4. Close the two xterm sessions
    5. On the server do a "stat ~/.Xauthority"
    6. Now on the client, try to open xterm
    This will fail.

    Even if the filehandle had become stale, the NFS client should invalidate
    the cache/inode and should repeat LOOKUP. Looking at the packet capture when
    the failure occurs shows that there were two subsequent ACCESS() calls with
    the same filehandle and both fails with -ESTALE error.

    I have tested the fix below. Now the client issue a LOOKUP after the
    ACCESS() call fails with -ESTALE. If all this makes sense to you, can you
    consider this for inclusion?

    Thanks,

    If the server returns an -ESTALE error due to stale filehandle in response to
    an ACCESS() call, we need to invalidate the cache and inode so that LOOKUP()
    can be retried. Without this change, the nfs client retries ACCESS() with the
    same filehandle, fails again and could lead to temporary failure of
    applications running on nfs mounted home.

    Signed-off-by: Suresh Jayaraman
    Signed-off-by: Trond Myklebust

    Suresh Jayaraman
     

24 Dec, 2008

4 commits

  • Hi.

    I've been looking at a bugzilla which describes a problem where
    a customer was advised to use either the "noac" or "actimeo=0"
    mount options to solve a consistency problem that they were
    seeing in the file attributes. It turned out that this solution
    did not work reliably for them because sometimes, the local
    attribute cache was believed to be valid and not timed out.
    (With an attribute cache timeout of 0, the cache should always
    appear to be timed out.)

    In looking at this situation, it appears to me that the problem
    is that the attribute cache timeout code has an off-by-one
    error in it. It is assuming that the cache is valid in the
    region, [read_cache_jiffies, read_cache_jiffies + attrtimeo]. The
    cache should be considered valid only in the region,
    [read_cache_jiffies, read_cache_jiffies + attrtimeo). With this
    change, the options, "noac" and "actimeo=0", work as originally
    expected.

    This problem was previously addressed by special casing the
    attrtimeo == 0 case. However, since the problem is only an off-
    by-one error, the cleaner solution is address the off-by-one
    error and thus, not require the special case.

    Thanx...

    ps

    Signed-off-by: Peter Staubach
    Signed-off-by: Trond Myklebust

    Peter Staubach
     
  • Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • This ensures that we don't have to look up the dentry again after we return
    the delegation if we know that the directory didn't change.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Signed-off-by: Trond Myklebust

    Trond Myklebust
     

23 Oct, 2008

2 commits

  • For execute permission on a regular files we need to check if file has
    any execute bits at all, regardless of capabilites.

    This check is normally performed by generic_permission() but was also
    added to the case when the filesystem defines its own ->permission()
    method. In the latter case the filesystem should be responsible for
    performing this check.

    Move the check from inode_permission() inside filesystems which are
    not calling generic_permission().

    Create a helper function execute_ok() that returns true if the inode
    is a directory or if any execute bits are present in i_mode.

    Also fix up the following code:

    - coda control file is never executable
    - sysctl files are never executable
    - hfs_permission seems broken on MAY_EXEC, remove
    - hfsplus_permission is eqivalent to generic_permission(), remove

    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     
  • New flag: LOOKUP_EXCL. Set before doing the final step of pathname
    resolution on the paths that have LOOKUP_CREATE and O_EXCL.

    Signed-off-by: Al Viro

    Al Viro
     

20 Oct, 2008

1 commit

  • Split the LRU lists in two, one set for pages that are backed by real file
    systems ("file") and one for pages that are backed by memory and swap
    ("anon"). The latter includes tmpfs.

    The advantage of doing this is that the VM will not have to scan over lots
    of anonymous pages (which we generally do not want to swap out), just to
    find the page cache pages that it should evict.

    This patch has the infrastructure and a basic policy to balance how much
    we scan the anon lists and how much we scan the file lists. The big
    policy changes are in separate patches.

    [lee.schermerhorn@hp.com: collect lru meminfo statistics from correct offset]
    [kosaki.motohiro@jp.fujitsu.com: prevent incorrect oom under split_lru]
    [kosaki.motohiro@jp.fujitsu.com: fix pagevec_move_tail() doesn't treat unevictable page]
    [hugh@veritas.com: memcg swapbacked pages active]
    [hugh@veritas.com: splitlru: BDI_CAP_SWAP_BACKED]
    [akpm@linux-foundation.org: fix /proc/vmstat units]
    [nishimura@mxp.nes.nec.co.jp: memcg: fix handling of shmem migration]
    [kosaki.motohiro@jp.fujitsu.com: adjust Quicklists field of /proc/meminfo]
    [kosaki.motohiro@jp.fujitsu.com: fix style issue of get_scan_ratio()]
    Signed-off-by: Rik van Riel
    Signed-off-by: Lee Schermerhorn
    Signed-off-by: KOSAKI Motohiro
    Signed-off-by: Hugh Dickins
    Signed-off-by: Daisuke Nishimura
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rik van Riel
     

15 Oct, 2008

2 commits

  • The cache_change_attribute is used to decide whether or not a directory has
    changed, in which case we may need to look it up again. Again, the use of
    'jiffies' leads to an issue of resolution.

    Once again, the fix is to change nfs_inode->cache_change_attribute, and
    just make it a simple counter.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • It appears that 'jiffies' timestamps do not have high enough resolution for
    nfs_inode_attrs_need_update(). One problem is that a GETATTR can be
    launched within < 1 jiffy of the last operation that updated the attribute.
    Another problem is that RPC calls can take < 1 jiffy to execute.

    We can fix this by switching the variables to use a simple global counter
    that gets incremented every time we start another GETATTR call.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

08 Oct, 2008

1 commit

  • Add the flag NFS_MOUNT_LOOKUP_CACHE_NONEG to turn off the caching of
    negative dentries. In reality what we do is to force
    nfs_lookup_revalidate() to always discard negative dentries.

    Add the flag NFS_MOUNT_LOOKUP_CACHE_NONE for enforcing stricter
    revalidation of dentries. It forces the revalidate code to always do a
    lookup instead of just checking the cached mtime of the parent directory.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

27 Jul, 2008

1 commit

  • * kill nameidata * argument; map the 3 bits in ->flags anybody cares
    about to new MAY_... ones and pass with the mask.
    * kill redundant gfs2_iop_permission()
    * sanitize ecryptfs_permission()
    * fix remaining places where ->permission() instances might barf on new
    MAY_... found in mask.

    The obvious next target in that direction is permission(9)

    folded fix for nfs_permission() breakage from Miklos Szeredi

    Signed-off-by: Al Viro

    Al Viro
     

16 Jul, 2008

10 commits