1. 05 2月, 2013 1 次提交
  2. 05 11月, 2012 1 次提交
  3. 28 7月, 2012 7 次提交
  4. 15 2月, 2012 2 次提交
  5. 14 9月, 2011 1 次提交
  6. 26 1月, 2011 1 次提交
    • C
      NLM: Fix "kernel BUG at fs/lockd/host.c:417!" or ".../host.c:283!" · 80c30e8d
      Chuck Lever 提交于
      Nick Bowler <nbowler@elliptictech.com> reports:
      
      > We were just having some NFS server troubles, and my client machine
      > running 2.6.38-rc1+ (specifically, commit 2b1caf6e) crashed
      > hard (syslog output appended to this mail).
      >
      > I'm not sure what the exact timeline was or how to reproduce this,
      > but the server was rebooted during all this.  Since I've never seen
      > this happen before, it is possibly a regression from previous kernel
      > releases.  However, I recently updated my nfs-utils (on the client) to
      > version 1.2.3, so that might be related as well.
      
        [ BUG output redacted ]
      
      When done searching, the for_each_host loop in next_host_state() falls
      through and returns the final host on the host chain without bumping
      it's reference count.
      
      Since the host's ref count is only one at that point, releasing the
      host in nlm_host_rebooted() attempts to destroy the host prematurely,
      and therefore hits a BUG().
      
      Likely, the original intent of the for_each_host behavior in
      next_host_state() was to handle the case when the host chain is empty.
      Searching the chain and finding no suitable host to return needs to be
      handled as well.
      
      Defensively restructure next_host_state() always to return NULL when
      the loop falls through.
      
      Introduced by commit b10e30f6 "lockd: reorganize nlm_host_rebooted".
      
      Cc: J. Bruce Fields <bfields@fieldses.org>
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      80c30e8d
  7. 05 1月, 2011 1 次提交
  8. 17 12月, 2010 10 次提交
  9. 16 11月, 2010 1 次提交
    • T
      NLM: Fix a regression in lockd · 8e35f8e7
      Trond Myklebust 提交于
      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 92476850 (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: NNick Bowler <nbowler@elliptictech.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      8e35f8e7
  10. 02 10月, 2010 1 次提交
  11. 09 2月, 2010 1 次提交
  12. 21 8月, 2009 1 次提交
  13. 10 8月, 2009 1 次提交
  14. 07 1月, 2009 11 次提交