1. 02 2月, 2018 3 次提交
  2. 14 11月, 2017 1 次提交
  3. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  4. 15 10月, 2017 1 次提交
  5. 23 8月, 2017 4 次提交
  6. 01 8月, 2017 2 次提交
    • M
      IB/{rdmavt, hfi1, qib}: Fix panic with post receive and SGE compression · 3ffea7d8
      Mike Marciniszyn 提交于
      The server side of qperf panics as follows:
      
      [242446.336860] IP: report_bug+0x64/0x10
      [242446.341031] PGD 1c0c067
      [242446.341032] P4D 1c0c067
      [242446.343951] PUD 1c0d063
      [242446.346870] PMD 8587ea067
      [242446.349788] PTE 800000083e14016
      [242446.352901]
      [242446.358352] Oops: 0003 [#1] SM
      [242446.437919] CPU: 1 PID: 7442 Comm: irq/92-hfi1_0 k Not tainted 4.12.0-mam-asm #1
      [242446.446365] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0018.C4.072020161249 07/20/201
      [242446.458397] task: ffff8808392d2b80 task.stack: ffffc9000664000
      [242446.465097] RIP: 0010:report_bug+0x64/0x10
      [242446.469859] RSP: 0018:ffffc900066439c0 EFLAGS: 0001000
      [242446.475784] RAX: ffffffffa06647e4 RBX: ffffffffa06461e1 RCX: 000000000000000
      [242446.483840] RDX: 0000000000000907 RSI: ffffffffa0675040 RDI: ffffffffffff740
      [242446.491897] RBP: ffffc900066439e0 R08: 0000000000000001 R09: 000000000000025
      [242446.499953] R10: ffffffff81a253df R11: 0000000000000133 R12: ffffc90006643b3
      [242446.508010] R13: ffffffffa065bbf0 R14: 00000000000001e5 R15: 000000000000000
      [242446.516067] FS:  0000000000000000(0000) GS:ffff88085f640000(0000) knlGS:000000000000000
      [242446.525191] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003
      [242446.531698] CR2: ffffffffa06647ee CR3: 0000000001c09000 CR4: 00000000001406e
      [242446.539756] Call Trace
      [242446.542582]  fixup_bug+0x2c/0x5
      [242446.546277]  do_trap+0x12b/0x18
      [242446.549972]  do_error_trap+0x89/0x11
      [242446.554171]  ? hfi1_copy_sge+0x271/0x2b0 [hfi1
      [242446.559324]  ? ttwu_do_wakeup+0x1e/0x14
      [242446.563795]  ? ttwu_do_activate+0x77/0x8
      [242446.568363]  do_invalid_op+0x20/0x3
      [242446.572448]  invalid_op+0x1e/0x3
      [242446.576247] RIP: 0010:hfi1_copy_sge+0x271/0x2b0 [hfi1
      [242446.582075] RSP: 0018:ffffc90006643be8 EFLAGS: 0001004
      [242446.587999] RAX: 0000000000000000 RBX: ffff88083e0fa240 RCX: 000000000000000
      [242446.596058] RDX: 0000000000000000 RSI: ffff880842508000 RDI: ffff88083e0fa24
      [242446.604116] RBP: ffffc90006643c28 R08: 0000000000000000 R09: 000000000000000
      [242446.612172] R10: ffffc90009473640 R11: 0000000000000133 R12: 000000000000000
      [242446.620228] R13: 0000000000000000 R14: 0000000000002000 R15: ffff88084250800
      [242446.628293]  ? hfi1_copy_sge+0x1a1/0x2b0 [hfi1
      [242446.633449]  hfi1_rc_rcv+0x3da/0x1270 [hfi1
      [242446.638312]  ? sc_buffer_alloc+0x113/0x150 [hfi1
      [242446.643662]  hfi1_ib_rcv+0x1c9/0x2e0 [hfi1
      [242446.648428]  process_receive_ib+0x19a/0x270 [hfi1
      [242446.653866]  ? process_rcv_qp_work+0xd2/0x160 [hfi1
      [242446.659505]  handle_receive_interrupt_nodma_rtail+0x184/0x2e0 [hfi1
      [242446.666693]  ? irq_finalize_oneshot+0x100/0x10
      [242446.671846]  receive_context_thread+0x1b/0x140 [hfi1
      [242446.677576]  irq_thread_fn+0x1e/0x4
      [242446.681659]  irq_thread+0x13c/0x1b
      [242446.685646]  ? irq_forced_thread_fn+0x60/0x6
      [242446.690604]  kthread+0x112/0x15
      [242446.694298]  ? irq_thread_check_affinity+0xe0/0xe
      [242446.699738]  ? kthread_park+0x60/0x6
      [242446.703919]  ? do_syscall_64+0x67/0x15
      [242446.708292]  ret_from_fork+0x25/0x3
      [242446.712374] Code: 63 78 04 44 0f b7 70 08 41 89 d0 4c 8d 2c 38 41 83 e0 01 f6 c2 02 74 17 66 45 85 c0 74 11 f6 c2 04 b9 01 00 00 00 75 bb 83 ca 04 <66> 89 50 0a 66 45 85 c0 74 52 0f b6 48 0b 41 0f b7 f6 4d 89 e0
      [242446.733527] RIP: report_bug+0x64/0x100 RSP: ffffc900066439c
      [242446.739935] CR2: ffffffffa06647e
      [242446.743763] ---[ end trace 0e90a20d0aa494f7 ]--
      
      The root cause is that the qib/hfi1 post receive call to rvt_lkey_ok()
      doesn't interpret the new return value from rvt_lkey_ok() properly
      leading to an mr reference count underrun.
      
      Additionally, remove an unused argument in rvt_sge_adjacent()
      aw well as an unneeded incr local in rvt_post_one_wr().
      
      Fixes: Commit 14fe13fc ("IB/rdmavt: Compress adjacent SGEs in rvt_lkey_ok()")
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      3ffea7d8
    • K
      IB/hfi1: Serve the most starved iowait entry first · bcad2913
      Kaike Wan 提交于
      When an egress resource(SDMA descriptors, pio credits) is not available,
      a sending thread will be put on the resource's wait queue. When the
      resource becomes available again, up to a fixed number of sending threads
      can be awakened sequentially and removed from the wait queue, depending
      on the number of waiting threads and the number of free resources. Since
      each awakened sending thread will send as many packets as possible, it
      is highly likely that the first sending thread will consume all the
      egress resources. Subsequently, it will be put back to the end of the wait
      queue. Depending on the timing when the later sending threads wake up,
      they may not be able to send any packet and be again put back to the end
      of the wait queue sequentially, right behind the first sending thread.
      This starvation cycle continues until some sending threads exceed their
      retry limit and consequently fail.
      
      This patch fixes the issue by two simple approaches:
      (1) Any starved sending thread will be put to the head of the wait queue
      while a served sending thread will be put to the tail;
      (2) The most starved sending thread will be served first.
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NKaike Wan <kaike.wan@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      bcad2913
  7. 28 6月, 2017 3 次提交
  8. 05 5月, 2017 1 次提交
  9. 02 5月, 2017 1 次提交
  10. 29 4月, 2017 3 次提交
  11. 06 4月, 2017 2 次提交
  12. 19 2月, 2017 4 次提交
  13. 12 12月, 2016 3 次提交
  14. 16 11月, 2016 1 次提交
  15. 02 10月, 2016 2 次提交
  16. 03 8月, 2016 5 次提交
  17. 26 5月, 2016 1 次提交
  18. 29 4月, 2016 1 次提交
  19. 18 3月, 2016 1 次提交