NFS Client file access problem firefox

From Linux NFS

---

Revision as of 20:07, 29 July 2011

About

• Kernel version: 2.6.37-rc1
• Bug 21902
• Reported by: Hans de Bruin (November 3, 2010)
• Fixed 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>