1. 23 3月, 2011 2 次提交
    • G
      nfs4: Fix NULL dereference at d_alloc_and_lookup() · 4667058b
      Gusev Vitaliy 提交于
      d_alloc_and_lookup() calls i_op->lookup method due to
      rootfh changes his fsid.
      
      During mount i_op of NFS root inode is set to
      nfs_mountpoint_inode_operations, if rpc_ops->getroot()
      and rpc_ops->getattr() return different fsid.
      
      After that  nfs_follow_remote_path() raised oops:
      
         BUG: unable to handle kernel NULL pointer dereference at (null)
         IP: [<          (null)>]           (null)
      
      stack trace:
      
           d_alloc_and_lookup+0x4c/0x74
           do_lookup+0x1e3/0x280
           link_path_walk+0x12e/0xab0
           nfs4_remote_get_sb+0x56/0x2c0 [nfs]
           path_walk+0x67/0xe0
           vfs_path_lookup+0x8e/0x100
           nfs_follow_remote_path+0x16f/0x3e0 [nfs]
           nfs4_try_mount+0x6f/0xd0 [nfs]
           nfs_get_sb+0x269/0x400 [nfs]
           vfs_kern_mount+0x8a/0x1f0
           do_kern_mount+0x52/0x130
           do_mount+0x20a/0x260
           sys_mount+0x90/0xe0
           system_call_fastpath+0x16/0x1b
      
      So just refresh fsid, as RFC3530 doesn't specify behavior
      in case of rootfh changes fsid.
      Signed-off-by: NVitaliy Gusev <gusev.vitaliy@nexenta.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4667058b
    • T
      SUNRPC: Never reuse the socket port after an xs_close() · 246408dc
      Trond Myklebust 提交于
      If we call xs_close(), we're in one of two situations:
       - Autoclose, which means we don't expect to resend a request
       - bind+connect failed, which probably means the port is in use
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      246408dc
  2. 22 3月, 2011 2 次提交
  3. 18 3月, 2011 4 次提交
  4. 16 3月, 2011 2 次提交
  5. 15 3月, 2011 2 次提交
  6. 12 3月, 2011 28 次提交