1. 25 1月, 2017 2 次提交
  2. 11 1月, 2017 15 次提交
  3. 23 12月, 2016 3 次提交
  4. 19 12月, 2016 1 次提交
  5. 16 12月, 2016 1 次提交
    • L
      rdma: fix buggy code that the compiler warns about · d3ea5478
      Linus Torvalds 提交于
      Get rid of this warning:
      
        drivers/infiniband/sw/rdmavt/cq.c: In function ‘rvt_cq_exit’:
        drivers/infiniband/sw/rdmavt/cq.c:542:2: warning: ‘worker’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          kthread_destroy_worker(worker);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      by fixing the function to actually work.
      
      Fixes: 6efaf10f ("IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker")
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d3ea5478
  6. 15 12月, 2016 3 次提交
    • J
      IB/rdmavt: Only put mmap_info ref if it exists · 22dccc54
      Jim Foraker 提交于
      rvt_create_qp() creates qp->ip only when a qp creation request comes from
      userspace (udata is not NULL).  If we exceed the number of available
      queue pairs however, the error path always attempts to put a kref to this
      structure.  If the requestor is inside the kernel, this leads to a crash.
      
      We fix this by checking that qp->ip is not NULL before caling kref_put().
      Signed-off-by: NJim Foraker <foraker1@llnl.gov>
      Acked-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Acked-by: NJonathan Toppins <jtoppins@redhat.com>
      Acked-by: NAlex Estrin <alex.estrin@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      22dccc54
    • P
      IB/rdmavt: Handle the kthread worker using the new API · f5eabf5e
      Petr Mladek 提交于
      Use the new API to create and destroy the cq kthread worker.
      The API hides some implementation details.
      
      In particular, kthread_create_worker() allocates and initializes
      struct kthread_worker. It runs the kthread the right way and stores
      task_struct into the worker structure. In addition, the *on_cpu()
      variant binds the kthread to the given cpu and the related memory
      node.
      
      kthread_destroy_worker() flushes all pending works, stops
      the kthread and frees the structure.
      
      This patch does not change the existing behavior. Note that we must
      use the on_cpu() variant because the function starts the kthread
      and it must bind it to the right CPU before waking. The numa node
      is associated for given CPU as well.
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f5eabf5e
    • P
      IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker · 6efaf10f
      Petr Mladek 提交于
      The memory barrier is not enough to protect queuing works into
      a destroyed cq kthread. Just imagine the following situation:
      
      CPU1				CPU2
      
      rvt_cq_enter()
        worker =  cq->rdi->worker;
      
      				rvt_cq_exit()
      				  rdi->worker = NULL;
      				  smp_wmb();
      				  kthread_flush_worker(worker);
      				  kthread_stop(worker->task);
      				  kfree(worker);
      
      				  // nothing queued yet =>
      				  // nothing flushed and
      				  // happily stopped and freed
      
        if (likely(worker)) {
           // true => read before CPU2 acted
           cq->notify = RVT_CQ_NONE;
           cq->triggered++;
           kthread_queue_work(worker, &cq->comptask);
      
        BANG: worker has been flushed/stopped/freed in the meantime.
      
      This patch solves this by protecting the critical sections by
      rdi->n_cqs_lock. It seems that this lock is not much contended
      and looks reasonable for this purpose.
      
      One catch is that rvt_cq_enter() might be called from IRQ context.
      Therefore we must always take the lock with IRQs disabled to avoid
      a possible deadlock.
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      6efaf10f
  7. 14 12月, 2016 2 次提交
  8. 13 12月, 2016 13 次提交