1. 12 3月, 2011 27 次提交
  2. 11 3月, 2011 8 次提交
    • A
      NFSv4.1 reclaim complete must wait for completion · c34c32ea
      Andy Adamson 提交于
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      [Trond: fix whitespace errors]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c34c32ea
    • A
    • R
      NFSv4.1: Retry CREATE_SESSION on NFS4ERR_DELAY · 7d6d63d6
      Ricardo Labiaga 提交于
      Fix bug where we currently retry the EXCHANGEID call again, eventhough
      we already have a valid clientid.  Instead, delay and retry the CREATE_SESSION
      call.
      Signed-off-by: NRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      7d6d63d6
    • F
      (try3-resend) Fix nfs_compat_user_ino64 so it doesn't cause problems if bit 31... · 3fa0b4e2
      Frank Filz 提交于
      (try3-resend) Fix nfs_compat_user_ino64 so it doesn't cause problems if bit 31 or 63 are set in fileid
      
      The problem was use of an int32, which when converted to a uint64
      is sign extended resulting in a fileid that doesn't fit in 32 bits
      even though the intent of the function is to fit the fileid into
      32 bits.
      Signed-off-by: NFrank Filz <ffilzlnx@us.ibm.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      [Trond: Added an include for compat.h]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      3fa0b4e2
    • J
      nfs: fix compilation warning · 43b7c3f0
      Jovi Zhang 提交于
      this commit fix compilation warning as following:
      linux-2.6/fs/nfs/nfs4proc.c:3265: warning: comparison of distinct pointer types lacks a cast
      Signed-off-by: NJovi Zhang <bookjovi@gmail.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      43b7c3f0
    • S
      nfs: add kmalloc return value check in decode_and_add_ds · b9f81057
      Stanislav Fomichev 提交于
      add kmalloc return value check in decode_and_add_ds
      Signed-off-by: NStanislav Fomichev <kernel@fomichev.me>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b9f81057
    • J
      nfs: close NFSv4 COMMIT vs. CLOSE race · d2224e7a
      Jeff Layton 提交于
      I've been adding in more artificial delays in the NFSv4 commit and close
      codepaths to uncover races. The kernel I'm testing has the patch to
      close the race in __rpc_wait_for_completion_task that's in Trond's
      cthon2011 branch. The reproducer I've been using does this in a loop:
      
      	mkdir("DIR");
      	fd = open("DIR/FILE", O_WRONLY|O_CREAT|O_EXCL, 0644);
      	write(fd, "abcdefg", 7);
      	close(fd);
      	unlink("DIR/FILE");
      	rmdir("DIR");
      
      The above reproducer shouldn't result in any silly-renaming. However,
      when I add a "msleep(100)" just after the nfs_commit_clear_lock call in
      nfs_commit_release, I can almost always force one to occur. If I can
      force it to occur with that, then it can happen without that delay
      given the right timing.
      
      nfs_commit_inode waits for the NFS_INO_COMMIT bit to clear when called
      with FLUSH_SYNC set. nfs_commit_rpcsetup on the other hand does not wait
      for the task to complete before putting its reference to it, so the last
      reference get put in rpc_release task and gets queued to a workqueue.
      
      In this situation, the last open context reference may be put by the
      COMMIT release instead of the close() syscall. The close() syscall
      returns too quickly and the unlink runs while the d_count is still
      high since the COMMIT release hasn't put its dentry reference yet.
      
      Fix this by having rpc_commit_rpcsetup wait for the RPC call to complete
      before putting the task reference when FLUSH_SYNC is set. With this, the
      last reference is put by the process that's initiating the FLUSH_SYNC
      commit and the race is closed.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d2224e7a
    • T
      SUNRPC: Close a race in __rpc_wait_for_completion_task() · bf294b41
      Trond Myklebust 提交于
      Although they run as rpciod background tasks, under normal operation
      (i.e. no SIGKILL), functions like nfs_sillyrename(), nfs4_proc_unlck()
      and nfs4_do_close() want to be fully synchronous. This means that when we
      exit, we want all references to the rpc_task to be gone, and we want
      any dentry references etc. held by that task to be released.
      
      For this reason these functions call __rpc_wait_for_completion_task(),
      followed by rpc_put_task() in the expectation that the latter will be
      releasing the last reference to the rpc_task, and thus ensuring that the
      callback_ops->rpc_release() has been called synchronously.
      
      This patch fixes a race which exists due to the fact that
      rpciod calls rpc_complete_task() (in order to wake up the callers of
      __rpc_wait_for_completion_task()) and then subsequently calls
      rpc_put_task() without ensuring that these two steps are done atomically.
      
      In order to avoid adding new spin locks, the patch uses the existing
      waitqueue spin lock to order the rpc_task reference count releases between
      the waiting process and rpciod.
      The common case where nobody is waiting for completion is optimised for by
      checking if the RPC_TASK_ASYNC flag is cleared and/or if the rpc_task
      reference count is 1: in those cases we drop trying to grab the spin lock,
      and immediately free up the rpc_task.
      
      Those few processes that need to put the rpc_task from inside an
      asynchronous context and that do not care about ordering are given a new
      helper: rpc_put_task_async().
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bf294b41
  3. 05 3月, 2011 1 次提交
    • N
      nfs4: Ensure that ACL pages sent over NFS were not allocated from the slab (v3) · e9e3d724
      Neil Horman 提交于
      The "bad_page()" page allocator sanity check was reported recently (call
      chain as follows):
      
        bad_page+0x69/0x91
        free_hot_cold_page+0x81/0x144
        skb_release_data+0x5f/0x98
        __kfree_skb+0x11/0x1a
        tcp_ack+0x6a3/0x1868
        tcp_rcv_established+0x7a6/0x8b9
        tcp_v4_do_rcv+0x2a/0x2fa
        tcp_v4_rcv+0x9a2/0x9f6
        do_timer+0x2df/0x52c
        ip_local_deliver+0x19d/0x263
        ip_rcv+0x539/0x57c
        netif_receive_skb+0x470/0x49f
        :virtio_net:virtnet_poll+0x46b/0x5c5
        net_rx_action+0xac/0x1b3
        __do_softirq+0x89/0x133
        call_softirq+0x1c/0x28
        do_softirq+0x2c/0x7d
        do_IRQ+0xec/0xf5
        default_idle+0x0/0x50
        ret_from_intr+0x0/0xa
        default_idle+0x29/0x50
        cpu_idle+0x95/0xb8
        start_kernel+0x220/0x225
        _sinittext+0x22f/0x236
      
      It occurs because an skb with a fraglist was freed from the tcp
      retransmit queue when it was acked, but a page on that fraglist had
      PG_Slab set (indicating it was allocated from the Slab allocator (which
      means the free path above can't safely free it via put_page.
      
      We tracked this back to an nfsv4 setacl operation, in which the nfs code
      attempted to fill convert the passed in buffer to an array of pages in
      __nfs4_proc_set_acl, which gets used by the skb->frags list in
      xs_sendpages.  __nfs4_proc_set_acl just converts each page in the buffer
      to a page struct via virt_to_page, but the vfs allocates the buffer via
      kmalloc, meaning the PG_slab bit is set.  We can't create a buffer with
      kmalloc and free it later in the tcp ack path with put_page, so we need
      to either:
      
      1) ensure that when we create the list of pages, no page struct has
         PG_Slab set
      
       or
      
      2) not use a page list to send this data
      
      Given that these buffers can be multiple pages and arbitrarily sized, I
      think (1) is the right way to go.  I've written the below patch to
      allocate a page from the buddy allocator directly and copy the data over
      to it.  This ensures that we have a put_page free-able page for every
      entry that winds up on an skb frag list, so it can be safely freed when
      the frame is acked.  We do a put page on each entry after the
      rpc_call_sync call so as to drop our own reference count to the page,
      leaving only the ref count taken by tcp_sendpages.  This way the data
      will be properly freed when the ack comes in
      
      Successfully tested by myself to solve the above oops.
      
      Note, as this is the result of a setacl operation that exceeded a page
      of data, I think this amounts to a local DOS triggerable by an
      uprivlidged user, so I'm CCing security on this as well.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Trond Myklebust <Trond.Myklebust@netapp.com>
      CC: security@kernel.org
      CC: Jeff Layton <jlayton@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e9e3d724
  4. 29 1月, 2011 3 次提交
    • C
      NFS: NFSv4 readdir loses entries · d1205f87
      Chuck Lever 提交于
      On recent 2.6.38-rc kernels, connectathon basic test 6 fails on
      NFSv4 mounts of OpenSolaris with something like:
      
      > ./test6: readdir
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors
      > basic tests failed
      > Tests failed, leaving /mnt/klimt mounted
      > [cel@matisse cthon04]$
      
      I narrowed the problem down to nfs4_decode_dirent() reporting that the
      decode buffer had overflowed while decoding the entries for those
      missing files.
      
      verify_attr_len() assumes both it's pointer arguments reside on the
      same page.  When these arguments point to locations on two different
      pages, verify_attr_len() can report false errors.  This can happen now
      that a large NFSv4 readdir result can span pages.
      
      We have reasonably good checking in nfs4_decode_dirent() anyway, so
      it should be safe to simply remove the extra checking.
      
      At a guess, this was introduced by commit 6650239a, "NFS: Don't use
      vm_map_ram() in readdir".
      
      Cc: stable@kernel.org [2.6.37]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d1205f87
    • C
      NFS: Micro-optimize nfs4_decode_dirent() · c08e76d0
      Chuck Lever 提交于
      Make the decoding of NFSv4 directory entries slightly more efficient
      by:
      
        1.  Avoiding unnecessary byte swapping when checking XDR booleans,
            and
      
        2.  Not bumping "p" when its value will be immediately replaced by
            xdr_inline_decode()
      
      This commit makes nfs4_decode_dirent() consistent with similar logic
      in the other two decode_dirent() functions.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c08e76d0
    • T
      NFS: Fix an NFS client lockdep issue · e00b8a24
      Trond Myklebust 提交于
      There is no reason to be freeing the delegation cred in the rcu callback,
      and doing so is resulting in a lockdep complaint that rpc_credcache_lock
      is being called from both softirq and non-softirq contexts.
      Reported-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      e00b8a24
  5. 26 1月, 2011 1 次提交