1. 20 May, 2015 4 commits
  2. 18 May, 2015 1 commit
  3. 11 Aug, 2014 4 commits
  4. 01 Apr, 2014 1 commit
  5. 31 Jul, 2013 1 commit
    • Jack Morgenstein's avatar
      IB/core: Create QP1 using the pkey index which contains the default pkey · ef5ed416
      Jack Morgenstein authored
      
      
      Currently, QP1 is created using pkey index 0. This patch simply looks
      for the index containing the default pkey, rather than hard-coding
      pkey index 0.
      
      This change will have no effect in native mode, since QP0 and QP1 are
      created before the SM configures the port, so pkey table will still be
      the default table defined by the IB Spec, in C10-123: "If non-volatile
      storage is not used to hold P_Key Table contents, then if a PM
      (Partition Manager) is not present, and prior to PM initialization of
      the P_Key Table, the P_Key Table must act as if it contains a single
      valid entry, at P_Key_ix = 0, containing the default partition
      key. All other entries in the P_Key Table must be invalid."
      
      Thus, in the native mode case, the driver will find the default pkey
      at index 0 (so it will be no different than the hard-coding).
      
      However, in SR-IOV mode, for VFs, the pkey table may be
      paravirtualized, so that the VF's pkey index zero may not necessarily
      be mapped to the real pkey index 0. For VFs, therefore, it is
      important to find the virtual index which maps to the real default
      pkey.
      
      This commit does the following for QP1 creation:
      
      1. Find the pkey index containing the default pkey, and use that index
         if found.  ib_find_pkey() returns the index of the
         limited-membership default pkey (0x7FFF) if the full-member default
         pkey is not in the table.
      
      2. If neither form of the default pkey is found, use pkey index 0
         (previous behavior).
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Reviewed-by: default avatarSean Hefty <sean.hefty@intel.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      ef5ed416
  6. 21 Aug, 2012 2 commits
    • Tejun Heo's avatar
      workqueue: deprecate __cancel_delayed_work() · 136b5721
      Tejun Heo authored
      
      
      Now that cancel_delayed_work() can be safely called from IRQ handlers,
      there's no reason to use __cancel_delayed_work().  Use
      cancel_delayed_work() instead of __cancel_delayed_work() and mark the
      latter deprecated.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarJens Axboe <axboe@kernel.dk>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      136b5721
    • Tejun Heo's avatar
      workqueue: use mod_delayed_work() instead of __cancel + queue · e7c2f967
      Tejun Heo authored
      
      
      Now that mod_delayed_work() is safe to call from IRQ handlers,
      __cancel_delayed_work() followed by queue_delayed_work() can be
      replaced with mod_delayed_work().
      
      Most conversions are straight-forward except for the following.
      
      * net/core/link_watch.c: linkwatch_schedule_work() was doing a quite
        elaborate dancing around its delayed_work.  Collapse it such that
        linkwatch_work is queued for immediate execution if LW_URGENT and
        existing timer is kept otherwise.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> 
      e7c2f967
  7. 24 Apr, 2012 2 commits
  8. 26 Feb, 2012 1 commit
  9. 31 Oct, 2011 1 commit
  10. 06 Oct, 2011 1 commit
  11. 23 May, 2011 1 commit
  12. 13 Oct, 2010 1 commit
  13. 24 May, 2010 1 commit
  14. 16 May, 2010 1 commit
  15. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  16. 11 Mar, 2010 1 commit
  17. 06 Mar, 2010 1 commit
  18. 07 Sep, 2009 2 commits
    • Hal Rosenstock's avatar
      IB/mad: Allow tuning of QP0 and QP1 sizes · b76aabc3
      Hal Rosenstock authored
      
      
      MADs are UD and can be dropped if there are no receives posted, so
      allow receive queue size to be set with a module parameter in case the
      queue needs to be lengthened.  Send side tuning is done for symmetry
      with receive.
      Signed-off-by: default avatarHal Rosenstock <hal.rosenstock@gmail.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      b76aabc3
    • Roland Dreier's avatar
      IB/mad: Fix possible lock-lock-timer deadlock · 6b2eef8f
      Roland Dreier authored
      Lockdep reported a possible deadlock with cm_id_priv->lock,
      mad_agent_priv->lock and mad_agent_priv->timed_work.timer; this
      happens because the mad module does
      
      	cancel_delayed_work(&mad_agent_priv->timed_work);
      
      while holding mad_agent_priv->lock.  cancel_delayed_work() internally
      does del_timer_sync(&mad_agent_priv->timed_work.timer).
      
      This can turn into a deadlock because mad_agent_priv->lock is taken
      inside cm_id_priv->lock, so we can get the following set of contexts
      that deadlock each other:
      
       A: holding cm_id_priv->lock, waiting for mad_agent_priv->lock
       B: holding mad_agent_priv->lock, waiting for del_timer_sync()
       C: interrupt during mad_agent_priv->timed_work.timer that takes
          cm_id_priv->lock
      
      Fix this by using the new __cancel_delayed_work() interface (which
      internally does del_timer() instead of del_timer_sync()) in all the
      places where we are holding a lock.
      
      Addresses: http://bugzilla.kernel.org/show_bug.cgi?id=13757
      
      Reported-by: default avatarBart Van Assche <bart.vanassche@gmail.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      6b2eef8f
  19. 06 Sep, 2009 1 commit
    • Roland Dreier's avatar
      IB: Use DEFINE_SPINLOCK() for static spinlocks · 6276e08a
      Roland Dreier authored
      
      
      Rather than just defining static spinlock_t variables and then
      initializing them later in init functions, simply define them with
      DEFINE_SPINLOCK() and remove the calls to spin_lock_init().  This cleans
      up the source a tad and also shrinks the compiled code; eg on x86-64:
      
      add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-40 (-40)
      function                                     old     new   delta
      ib_uverbs_init                               336     326     -10
      ib_mad_init_module                           147     137     -10
      ib_sa_init                                   123     103     -20
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      6276e08a
  20. 03 Mar, 2009 1 commit
    • Ralph Campbell's avatar
      IB/mad: Fix ib_post_send_mad() returning 0 with no generate send comp · 4780c195
      Ralph Campbell authored
      
      
      If ib_post_send_mad() returns 0, the API guarantees that there will be
      a callback to send_buf->mad_agent->send_handler() so that the sender
      can call ib_free_send_mad().  Otherwise, the ib_mad_send_buf will be
      leaked and the mad_agent reference count will never go to zero and the
      IB device module cannot be unloaded.  The above can happen without
      this patch if process_mad() returns (IB_MAD_RESULT_SUCCESS |
      IB_MAD_RESULT_CONSUMED).
      
      If process_mad() returns IB_MAD_RESULT_SUCCESS and there is no agent
      registered to receive the mad being sent, handle_outgoing_dr_smp()
      returns zero which causes a MAD packet which is at the end of the
      directed route to be incorrectly sent on the wire but doesn't cause a
      hang since the HCA generates a send completion.
      Signed-off-by: default avatarRalph Campbell <ralph.campbell@qlogic.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      4780c195
  21. 27 Feb, 2009 2 commits
    • Ralph Campbell's avatar
      IB/mad: initialize mad_agent_priv before putting on lists · d9620a4c
      Ralph Campbell authored
      
      
      There is a potential race in ib_register_mad_agent() where the struct
      ib_mad_agent_private is not fully initialized before it is added to
      the list of agents per IB port. This means the ib_mad_agent_private
      could be seen before the refcount, spin locks, and linked lists are
      initialized.  The fix is to initialize the structure earlier.
      Signed-off-by: default avatarRalph Campbell <ralph.campbell@qlogic.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      d9620a4c
    • Ralph Campbell's avatar
      IB/mad: Fix null pointer dereference in local_completions() · 1d9bc6d6
      Ralph Campbell authored
      
      
      handle_outgoing_dr_smp() can queue a struct ib_mad_local_private
      *local on the mad_agent_priv->local_work work queue with
      local->mad_priv == NULL if device->process_mad() returns
      IB_MAD_RESULT_SUCCESS | IB_MAD_RESULT_REPLY and
      (!ib_response_mad(&mad_priv->mad.mad) ||
      !mad_agent_priv->agent.recv_handler).
      
      In this case, local_completions() will be called with local->mad_priv
      == NULL. The code does check for this case and skips calling
      recv_mad_agent->agent.recv_handler() but recv == 0 so
      kmem_cache_free() is called with a NULL pointer.
      
      Also, since recv isn't reinitialized each time through the loop, it
      can cause a memory leak if recv should have been zero.
      Signed-off-by: default avatarRalph Campbell <ralph.campbell@qlogic.com>
      1d9bc6d6
  22. 14 Oct, 2008 1 commit
  23. 21 Sep, 2008 1 commit
  24. 23 May, 2008 1 commit
  25. 25 Jan, 2008 4 commits
  26. 03 Aug, 2007 2 commits