Getcwd() incorrectly returning ENOENT

From Linux NFS

Jump to: navigation, search

Contents

About

  • Kernel version: 2.6.30, 2.6.31, 2.6.32-rc5
  • bug 14541
  • Reported by: Daniel J Blueman (November 4, 2009)
  • Fixed by: Trond Myklebust (November 5, 2009)

Symptoms

  • Caused by race condition that appeared in a65318bf3afc93ce49227e849d213799b072c5fd
  • To observe the change to user-level behaviour (after the reproducer commands):
# make clean
# strace -ffe getcwd make -n >list
[pid  3829] getcwd(0x7fffa269a380, 4096) = -1 ENOENT (No such file or
directory)
make: getcwd: No such file or directory
  • this impacts userspace and causes varying levels of failure, which often are benign, but can break applications
    • it's impossible to build an Ubuntu/Debian kernel over NFS4 since 2.6.30-rc.
$ sudo bash
# apt-get install build-essential
# apt-get build-dep apt
# mount server:/ /mnt -tnfs4 && cd /mnt
# apt-get source apt
# cd apt-0.7.23.1ubuntu2
# ./configure && make
 -> "getcwd: No such file or directory" 

Cause

commit a65318bf3afc93ce49227e849d213799b072c5fd
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Mar 11 14:10:28 2009 -0400

    NFSv4: Simplify some cache consistency post-op GETATTRs
    
    Certain asynchronous operations such as write() do not expect
    (or care) that other metadata such as the file owner, mode, acls, ...
    change. All they want to do is update and/or check the change attribute,
    ctime, and mtime.
    By skipping the file owner and group update, we also avoid having to do a
    potential idmapper upcall for these asynchronous RPC calls.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

Resolution

commit 96d25e532234bec1a1989e6e1baf702d43a78b0d
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Nov 11 16:15:42 2009 +0900

    NFSv4: Fix a cache validation bug which causes getcwd() to return ENOENT
    
    Changeset a65318bf3afc93ce49227e849d213799b072c5fd (NFSv4: Simplify some
    cache consistency post-op GETATTRs) incorrectly changed the getattr
    bitmap for readdir().
    This causes the readdir() function to fail to return a
    fileid/inode number, which again exposed a bug in the NFS readdir code that
    causes spurious ENOENT errors to appear in applications (see
    http://bugzilla.kernel.org/show_bug.cgi?id=14541).
    
    The immediate band aid is to revert the incorrect bitmap change, but more
    long term, we should change the NFS readdir code to cope with the
    fact that NFSv4 servers are not required to support fileids/inode numbers.
    
    Reported-by: Daniel J Blueman <daniel.blueman@gmail.com>
    Cc: stable@kernel.org
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Personal tools