1. 17 Apr, 2013 1 commit
    • Thadeu Lima de Souza Cascardo's avatar
      RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled · 5b0c2759
      Thadeu Lima de Souza Cascardo authored
      Commit c079c287 ("RDMA/cxgb4: Fix error handling in create_qp()")
      broke SQ allocation.  Instead of falling back to host allocation when
      on-chip allocation fails, it tries to allocate both.  And when it
      does, and we try to free the address from the genpool using the host
      address, we hit a BUG and the system crashes as below.
      
      We create a new function that has the previous behavior and properly
      propagate the error, as intended.
      
          kernel BUG at /usr/src/packages/BUILD/kernel-ppc64-3.0.68/linux-3.0/lib/genalloc.c:340!
          Oops: Exception in kernel mode, sig: 5 [#1]
          SMP NR_CPUS=1024 NUMA pSeries
          Modules linked in: rdma_ucm rdma_cm ib_addr ib_cm iw_cm ib_sa ib_mad ib_uverbs iw_cxgb4 ib_core ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables fuse loop dm_mod ipv6 ipv6_lib sr_mod cdrom ibmveth(X) cxgb4 sg ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh ibmvscsic(X) scsi_transport_srp scsi_tgt scsi_mod
          Supported: Yes
          NIP: c00000000037d41c LR: d000000003913824 CTR: c00000000037d3b0
          REGS: c0000001f350ae50 TRAP: 0700   Tainted: G            X  (3.0.68-0.9-ppc64)
          MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24042482  XER: 00000001
          TASK = c0000001f6f2a840[3616] 'rping' THREAD: c0000001f3508000 CPU: 0
          GPR00: c0000001f6e875c8 c0000001f350b0d0 c000000000fc9690 c0000001f6e875c0
          GPR04: 00000000000c0000 0000000000010000 0000000000000000 c0000000009d482a
          GPR08: 000000006a170000 0000000000100000 c0000001f350b140 c0000001f6e875c8
          GPR12: d000000003915dd0 c000000003f40000 000000003e3ecfa8 c0000001f350bea0
          GPR16: c0000001f350bcd0 00000000003c0000 0000000000040100 c0000001f6e74a80
          GPR20: d00000000399a898 c0000001f6e74ac8 c0000001fad91600 c0000001f6e74ab0
          GPR24: c0000001f7d23f80 0000000000000000 0000000000000002 000000006a170000
          GPR28: 000000000000000c c0000001f584c8d0 d000000003925180 c0000001f6e875c8
          NIP [c00000000037d41c] .gen_pool_free+0x6c/0xf8
          LR [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4]
          Call Trace:
          [c0000001f350b0d0] [c0000001f350b180] 0xc0000001f350b180 (unreliable)
          [c0000001f350b170] [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4]
          [c0000001f350b210] [d00000000390fd70] .dealloc_sq+0x90/0xb0 [iw_cxgb4]
          [c0000001f350b280] [d00000000390fe08] .destroy_qp+0x78/0xf8 [iw_cxgb4]
          [c0000001f350b310] [d000000003912738] .c4iw_destroy_qp+0x208/0x2d0 [iw_cxgb4]
          [c0000001f350b460] [d000000003861874] .ib_destroy_qp+0x5c/0x130 [ib_core]
          [c0000001f350b510] [d0000000039911bc] .ib_uverbs_cleanup_ucontext+0x174/0x4f8 [ib_uverbs]
          [c0000001f350b5f0] [d000000003991568] .ib_uverbs_close+0x28/0x70 [ib_uverbs]
          [c0000001f350b670] [c0000000001e7b2c] .__fput+0xdc/0x278
          [c0000001f350b720] [c0000000001a9590] .remove_vma+0x68/0xd8
          [c0000001f350b7b0] [c0000000001a9720] .exit_mmap+0x120/0x160
          [c0000001f350b8d0] [c0000000000af330] .mmput+0x80/0x160
          [c0000001f350b960] [c0000000000b5d0c] .exit_mm+0x1ac/0x1e8
          [c0000001f350ba10] [c0000000000b8154] .do_exit+0x1b4/0x4b8
          [c0000001f350bad0] [c0000000000b84b0] .do_group_exit+0x58/0xf8
          [c0000001f350bb60] [c0000000000ce9f4] .get_signal_to_deliver+0x2f4/0x5d0
          [c0000001f350bc60] [c000000000017ee4] .do_signal_pending+0x6c/0x3e0
          [c0000001f350bdb0] [c0000000000182cc] .do_signal+0x74/0x78
          [c0000001f350be30] [c000000000009e74] do_work+0x24/0x28
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Cc: Emil Goode <emilgoode@gmail.com>
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      5b0c2759
  2. 15 Apr, 2013 1 commit
  3. 14 Apr, 2013 10 commits
  4. 13 Apr, 2013 3 commits
    • Suleiman Souhlal's avatar
      vfs: Revert spurious fix to spinning prevention in prune_icache_sb · 5b55d708
      Suleiman Souhlal authored
      Revert commit 62a3ddef ("vfs: fix spinning prevention in prune_icache_sb").
      
      This commit doesn't look right: since we are looking at the tail of the
      list (sb->s_inode_lru.prev) if we want to skip an inode, we should put
      it back at the head of the list instead of the tail, otherwise we will
      keep spinning on it.
      
      Discovered when investigating why prune_icache_sb came top in perf
      reports of a swapping load.
      Signed-off-by: default avatarSuleiman Souhlal <suleiman@google.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org # v3.2+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5b55d708
    • Linus Torvalds's avatar
      kobject: fix kset_find_obj() race with concurrent last kobject_put() · a49b7e82
      Linus Torvalds authored
      Anatol Pomozov identified a race condition that hits module unloading
      and re-loading.  To quote Anatol:
      
       "This is a race codition that exists between kset_find_obj() and
        kobject_put().  kset_find_obj() might return kobject that has refcount
        equal to 0 if this kobject is freeing by kobject_put() in other
        thread.
      
        Here is timeline for the crash in case if kset_find_obj() searches for
        an object tht nobody holds and other thread is doing kobject_put() on
        the same kobject:
      
          THREAD A (calls kset_find_obj())     THREAD B (calls kobject_put())
          splin_lock()
                                               atomic_dec_return(kobj->kref), counter gets zero here
                                               ... starts kobject cleanup ....
                                               spin_lock() // WAIT thread A in kobj_kset_leave()
          iterate over kset->list
          atomic_inc(kobj->kref) (counter becomes 1)
          spin_unlock()
                                               spin_lock() // taken
                                               // it does not know that thread A increased counter so it
                                               remove obj from list
                                               spin_unlock()
                                               vfree(module) // frees module object with containing kobj
      
          // kobj points to freed memory area!!
          kobject_put(kobj) // OOPS!!!!
      
        The race above happens because module.c tries to use kset_find_obj()
        when somebody unloads module.  The module.c code was introduced in
        commit 6494a93d"
      
      Anatol supplied a patch specific for module.c that worked around the
      problem by simply not using kset_find_obj() at all, but rather than make
      a local band-aid, this just fixes kset_find_obj() to be thread-safe
      using the proper model of refusing the get a new reference if the
      refcount has already dropped to zero.
      
      See examples of this proper refcount handling not only in the kref
      documentation, but in various other equivalent uses of this pattern by
      grepping for atomic_inc_not_zero().
      
      [ Side note: the module race does indicate that module loading and
        unloading is not properly serialized wrt sysfs information using the
        module mutex.  That may require further thought, but this is the
        correct fix at the kobject layer regardless. ]
      Reported-analyzed-and-tested-by: default avatarAnatol Pomozov <anatol.pomozov@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a49b7e82
    • Josef Bacik's avatar
      Btrfs: make sure nbytes are right after log replay · 4bc4bee4
      Josef Bacik authored
      While trying to track down a tree log replay bug I noticed that fsck was always
      complaining about nbytes not being right for our fsynced file.  That is because
      the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
      nbytes are not necessarily updated properly when we log it.  So to fix this we
      need to set nbytes to whatever it is on the inode that is on disk, so when we
      replay the extents we can just add the bytes that are being added as we replay
      the extent.  This makes it work for the case that we have the wrong nbytes or
      the case that we logged everything and nbytes is actually correct.  With this
      I'm no longer getting nbytes errors out of btrfsck.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      4bc4bee4
  5. 12 Apr, 2013 20 commits
  6. 11 Apr, 2013 5 commits