NFS Client file access problem firefox

From Linux NFS

Latest revision as of 20:10, 29 July 2011

About

• Kernel version: 2.6.37-rc1
• Bug 21902
• Reported by: Hans de Bruin (November 3, 2010)
• Closed by: Rafael J. Wysocki (November 18, 2010)

Symptoms

• After startup Firefox reports:
  • The bookmarks and history system will not be functional because one of Firefox's files is in use by another application. Some security software can cause this problem.

First bad commit

• This problem was introduced by commit 9247685088398cf21bcb513bd2832b4cd42516c4

commit 9247685088398cf21bcb513bd2832b4cd42516c4
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Oct 20 11:53:01 2010 -0400

    SUNRPC: Properly initialize sock_xprt.srcaddr in all cases
    
    The source address field in the transport's sock_xprt is initialized
    ONLY IF the RPC application passed a pointer to a source address
    during the call to rpc_create().  However, xs_bind() subsequently uses
    the value of this field without regard to whether the source address
    was initialized during transport creation or not.
    
    So far we've been lucky: the uninitialized value of this field is
    zeroes.  xs_bind(), until recently, used only the sin[6]_addr field in
    this sockaddr, and all zeroes is a valid value for this: it means
    ANYADDR.  This is a happy coincidence.
    
    However, xs_bind() now wants to use the sa_family field as well, and
    expects it to be initialized to something other than zero.
    
    Therefore, the source address sockaddr field should be fully
    initialized at transport create time in _every_ case, not just when
    the RPC application wants to use a specific bind address.
    
    Bruce added a workaround for this missing initialization by adjusting
    commit 6bc9638a, but the "right" way to do this is to ensure that the
    source address sockaddr is always correctly initialized from the
    get-go.
    
    This patch doesn't introduce a behavior change.  It's simply a
    clean-up of Bruce's fix, to prevent future problems of this kind.  It
    may look like overkill, but
    
      a) it clearly documents the default initial value of this field,
    
      b) it doesn't assume that the sockaddr_storage memory is first
         initialized to any particular value, and
    
      c) it will fail verbosely if some unknown address family is passed
         in
    
    Originally introduced by commit d3bc9a1d.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

Resolution

• This problem was fixed by commit 8e35f8e7c61c88f9a979a4e6f7f4ffd4c158a88a

commit 8e35f8e7c61c88f9a979a4e6f7f4ffd4c158a88a
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Nov 2 09:11:55 2010 -0400

    NLM: Fix a regression in lockd
    
    Nick Bowler reports:
    There are no unusual messages on the client... but I just logged into
    the server and I see lots of messages of the following form:
    
      nfsd: request from insecure port (192.168.8.199:35766)!
      nfsd: request from insecure port (192.168.8.199:35766)!
      nfsd: request from insecure port (192.168.8.199:35766)!
      nfsd: request from insecure port (192.168.8.199:35766)!
      nfsd: request from insecure port (192.168.8.199:35766)!
    
    Bisected to commit 9247685088398cf21bcb513bd2832b4cd42516c4 (SUNRPC:
    Properly initialize sock_xprt.srcaddr in all cases)
    
    Apparently, removing the 'transport->srcaddr.ss_family = family' from
    xs_create_sock() triggers this due to nlmclnt_lookup_host() incorrectly
    initialising the srcaddr family to AF_UNSPEC.
    
    Reported-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>