1. 22 6月, 2013 6 次提交
  2. 05 6月, 2013 1 次提交
    • M
      IB/qib: Fix lockdep splat in qib_alloc_lkey() · f3bdf344
      Mike Marciniszyn 提交于
      The following backtrace is reported with CONFIG_PROVE_RCU:
      
          drivers/infiniband/hw/qib/qib_keys.c:64 suspicious rcu_dereference_check() usage!
          other info that might help us debug this:
          rcu_scheduler_active = 1, debug_locks = 1
          4 locks held by kworker/0:1/56:
          #0:  (events){.+.+.+}, at: [<ffffffff8107a4f5>] process_one_work+0x165/0x4a0
          #1:  ((&wfc.work)){+.+.+.}, at: [<ffffffff8107a4f5>] process_one_work+0x165/0x4a0
          #2:  (device_mutex){+.+.+.}, at: [<ffffffffa0148dd8>] ib_register_device+0x38/0x220 [ib_core]
          #3:  (&(&dev->lk_table.lock)->rlock){......}, at: [<ffffffffa017e81c>] qib_alloc_lkey+0x3c/0x1b0 [ib_qib]
      
          stack backtrace:
          Pid: 56, comm: kworker/0:1 Not tainted 3.10.0-rc1+ #6
          Call Trace:
          [<ffffffff810c0b85>] lockdep_rcu_suspicious+0xe5/0x130
          [<ffffffffa017e8e1>] qib_alloc_lkey+0x101/0x1b0 [ib_qib]
          [<ffffffffa0184886>] qib_get_dma_mr+0xa6/0xd0 [ib_qib]
          [<ffffffffa01461aa>] ib_get_dma_mr+0x1a/0x50 [ib_core]
          [<ffffffffa01678dc>] ib_mad_port_open+0x12c/0x390 [ib_mad]
          [<ffffffff810c2c55>] ?  trace_hardirqs_on_caller+0x105/0x190
          [<ffffffffa0167b92>] ib_mad_init_device+0x52/0x110 [ib_mad]
          [<ffffffffa01917c0>] ?  sl2vl_attr_show+0x30/0x30 [ib_qib]
          [<ffffffffa0148f49>] ib_register_device+0x1a9/0x220 [ib_core]
          [<ffffffffa01b1685>] qib_register_ib_device+0x735/0xa40 [ib_qib]
          [<ffffffff8106ba98>] ? mod_timer+0x118/0x220
          [<ffffffffa017d425>] qib_init_one+0x1e5/0x400 [ib_qib]
          [<ffffffff812ce86e>] local_pci_probe+0x4e/0x90
          [<ffffffff81078118>] work_for_cpu_fn+0x18/0x30
          [<ffffffff8107a566>] process_one_work+0x1d6/0x4a0
          [<ffffffff8107a4f5>] ?  process_one_work+0x165/0x4a0
          [<ffffffff8107c9c9>] worker_thread+0x119/0x370
          [<ffffffff8107c8b0>] ?  manage_workers+0x180/0x180
          [<ffffffff8108294e>] kthread+0xee/0x100
          [<ffffffff81082860>] ?  __init_kthread_worker+0x70/0x70
          [<ffffffff815c04ac>] ret_from_fork+0x7c/0xb0
          [<ffffffff81082860>] ?  __init_kthread_worker+0x70/0x70
      
      Per Documentation/RCU/lockdep-splat.txt, the code now uses rcu_access_pointer()
      vs. rcu_dereference().
      Reported-by: NJay Fenlason <fenlason@redhat.com>
      Reviewed-by: NDean Luick <dean.luick@intel.com>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f3bdf344
  3. 29 5月, 2013 1 次提交
  4. 08 5月, 2013 2 次提交
  5. 30 4月, 2013 2 次提交
  6. 25 4月, 2013 3 次提交
  7. 20 4月, 2013 2 次提交
  8. 17 4月, 2013 6 次提交
    • M
      IB/qib: Correct qib_verbs_register_sysfs() error handling · c9bdad3c
      Mike Marciniszyn 提交于
      qib_verbs_register_sysfs() never cleans up from a failure.
      Additionally, the caller of qib_verbs_register_sysfs() doesn't
      return the correct "ret" value.
      
      This patch resolves both of those issues.
      Reported-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Reviewed-by: NDean Luick <dean.luick@intel.com>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      c9bdad3c
    • M
      IB/ipath: Correct ipath_verbs_register_sysfs() error handling · 137200a4
      Mike Marciniszyn 提交于
      ipath_verbs_register_sysfs() never returned the correct error
      code from device_create_file and never cleaned up from a failure.
      Additionally, the caller of ipath_verbs_register_sysfs() doesn't
      return the correct "ret" value.
      
      This patch resolves all of these issues.
      Reported-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Reviewed-by: NDean Luick <dean.luick@intel.com>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      137200a4
    • T
      RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled · 5b0c2759
      Thadeu Lima de Souza Cascardo 提交于
      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: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Cc: Emil Goode <emilgoode@gmail.com>
      Cc: <stable@vger.kernel.org>
      Acked-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      5b0c2759
    • A
      RDMA: Rename random32() to prandom_u32() · cc529c0d
      Akinobu Mita 提交于
      Use more preferable function name which implies using a pseudo-random
      number generator.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Reviewed-by: NSteve Wise <swise@opengridcomputing.com>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: Steve Wise <swise@chelsio.com>
      Cc: linux-rdma@vger.kernel.org
      Reviewed-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      cc529c0d
    • C
      RDMA/cxgb3: Fix uninitialized variable · bc4ba94c
      Cong Ding 提交于
      The variable npages might be used uninitialized.
      Signed-off-by: NCong Ding <dinggnu@gmail.com>
      Acked-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      bc4ba94c
    • S
      IB/mlx4: Fetch XRC SRQ in the CQ polling code · f3cca4b1
      Shlomo Pongratz 提交于
      An XRC target QP may redirect to more than one XRC SRQ.  This means
      that for work completions associated with a XRC TGT QP, the srq field
      in the QP has no usage and the real XRC SRQ need to be retrived using
      the information from the XRCETH placed into the CQE, do that.
      Signed-off-by: NShlomo Pongratz <shlomop@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f3cca4b1
  9. 06 4月, 2013 1 次提交
  10. 23 3月, 2013 3 次提交
  11. 18 3月, 2013 1 次提交
    • C
      tcp: Remove TCPCT · 1a2c6181
      Christoph Paasch 提交于
      TCPCT uses option-number 253, reserved for experimental use and should
      not be used in production environments.
      Further, TCPCT does not fully implement RFC 6013.
      
      As a nice side-effect, removing TCPCT increases TCP's performance for
      very short flows:
      
      Doing an apache-benchmark with -c 100 -n 100000, sending HTTP-requests
      for files of 1KB size.
      
      before this patch:
      	average (among 7 runs) of 20845.5 Requests/Second
      after:
      	average (among 7 runs) of 21403.6 Requests/Second
      Signed-off-by: NChristoph Paasch <christoph.paasch@uclouvain.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a2c6181
  12. 15 3月, 2013 1 次提交
  13. 14 3月, 2013 8 次提交
  14. 04 3月, 2013 1 次提交
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  15. 28 2月, 2013 2 次提交
    • T
      idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c · e8c8d1bc
      Tejun Heo 提交于
      MAX_IDR_MASK is another weirdness in the idr interface.  As idr covers
      whole positive integer range, it's defined as 0x7fffffff or INT_MAX.
      
      Its usage in idr_find(), idr_replace() and idr_remove() is bizarre.
      They basically mask off the sign bit and operate on the rest, so if
      the caller, by accident, passes in a negative number, the sign bit
      will be masked off and the remaining part will be used as if that was
      the input, which is worse than crashing.
      
      The constant is visible in idr.h and there are several users in the
      kernel.
      
      * drivers/i2c/i2c-core.c:i2c_add_numbered_adapter()
      
        Basically used to test if adap->nr is a negative number which isn't
        -1 and returns -EINVAL if so.  idr_alloc() already has negative
        @start checking (w/ WARN_ON_ONCE), so this can go away.
      
      * drivers/infiniband/core/cm.c:cm_alloc_id()
        drivers/infiniband/hw/mlx4/cm.c:id_map_alloc()
      
        Used to wrap cyclic @start.  Can be replaced with max(next, 0).
        Note that this type of cyclic allocation using idr is buggy.  These
        are prone to spurious -ENOSPC failure after the first wraparound.
      
      * fs/super.c:get_anon_bdev()
      
        The ID allocated from ida is masked off before being tested whether
        it's inside valid range.  ida allocated ID can never be a negative
        number and the masking is unnecessary.
      
      Update idr_*() functions to fail with -EINVAL when negative @id is
      specified and update other MAX_IDR_MASK users as described above.
      
      This leaves MAX_IDR_MASK without any user, remove it and relocate
      other MAX_IDR_* constants to lib/idr.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: "Marciniszyn, Mike" <mike.marciniszyn@intel.com>
      Cc: Jack Morgenstein <jackm@dev.mellanox.co.il>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Acked-by: NWolfram Sang <wolfram@the-dreams.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8c8d1bc
    • T
      IB/qib: convert to idr_alloc() · 80f22b44
      Tejun Heo 提交于
      Convert to the much saner new idr interface.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Mike Marciniszyn <infinipath@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80f22b44