1. 13 1月, 2018 1 次提交
  2. 22 11月, 2017 1 次提交
  3. 03 10月, 2017 2 次提交
  4. 02 10月, 2017 1 次提交
  5. 06 4月, 2017 2 次提交
    • J
      fm10k: future-proof state bitmaps using DECLARE_BITMAP · 46929557
      Jacob Keller 提交于
      This ensures that future programmers do not have to remember to re-size
      the bitmaps due to adding new values. Although this is unlikely for this
      driver, it may happen and it's best to prevent it from ever being an
      issue.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      46929557
    • J
      fm10k: use a BITMAP for flags to avoid race conditions · 3ee7b3a3
      Jacob Keller 提交于
      Replace bitwise operators and #defines with a BITMAP and enumeration
      values. This is similar to how we handle the "state" values as well.
      
      This has two distinct advantages over the old method. First, we ensure
      correctness of operations which are currently problematic due to race
      conditions. Suppose that two kernel threads are running, such as the
      watchdog and an ethtool ioctl, and both modify flags. We'll say that the
      watchdog is CPU A, and the ethtool ioctl is CPU B.
      
      CPU A sets FLAG_1, which can be seen as
        CPU A read FLAGS
        CPU A write FLAGS | FLAG_1
      
      CPU B sets FLAG_2, which can be seen as
        CPU B read FLAGS
        CPU A write FLAGS | FLAG_2
      
      However, "|=" and "&=" operators are not actually atomic. So this could
      be ordered like the following:
      
      CPU A read FLAGS -> variable
      CPU B read FLAGS -> variable
      CPU A write FLAGS (variable | FLAG_1)
      CPU B write FLAGS (variable | FLAG_2)
      
      Notice how the 2nd write from CPU B could actually undo the write from
      CPU A because it isn't guaranteed that the |= operation is atomic.
      
      In practice the race windows for most flag writes is incredibly narrow
      so it is not easy to isolate issues. However, the more flags we have,
      the more likely they will cause problems. Additionally, if such
      a problem were to arise, it would be incredibly difficult to track down.
      
      Second, there is an additional advantage beyond code correctness. We can
      now automatically size the BITMAP if more flags were added, so that we
      do not need to remember that flags is u32 and thus if we added too many
      flags we would over-run the variable. This is not a likely occurrence
      for fm10k driver, but this patch can serve as an example for other
      drivers which have many more flags.
      
      This particular change does have a bit of trouble converting some of the
      idioms previously used with the #defines for flags. Specifically, when
      converting FM10K_FLAG_RSS_FIELD_IPV[46]_UDP flags. This whole operation
      was actually quite problematic, because we actually stored flags
      separately. This could more easily show the problem of the above
      re-ordering issue.
      
      This is really difficult to test whether atomics make a difference in
      practical scenarios, but you can ensure that basic functionality remains
      the same. This patch has a lot of code coverage, but most of it is
      relatively simple.
      
      While we are modifying these files, update their copyright year.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3ee7b3a3
  6. 08 1月, 2017 3 次提交
  7. 03 10月, 2016 1 次提交
  8. 29 8月, 2016 5 次提交
  9. 21 7月, 2016 4 次提交
  10. 30 6月, 2016 2 次提交
  11. 21 4月, 2016 6 次提交
  12. 06 4月, 2016 5 次提交
    • J
      fm10k: use ethtool_rxfh_indir_default for default redirection table · 0ea7fae4
      Jacob Keller 提交于
      The fm10k driver used its own code for generating a default indirection
      table on device load, which was not the same as the default generated by
      ethtool when indir_size of 0 is passed to SRXFH. Take advantage of
      ethtool_rxfh_indir_default() and simplify code to write the redirection
      table to reduce some code duplication.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0ea7fae4
    • J
      fm10k: correctly clean up when init_queueing_scheme fails · 4be37c42
      Jacob Keller 提交于
      Fix a kernel panic that occurs during surprise removal. Clear the
      interface queue counts upon fm10k_init_msix_capability failure. This
      prevents further code (fm10k_update_stats etc.) from attempting to
      access unallocated queue vector or ring memory.
      
      [  628.692648] BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
      [  628.692805] IP: [<ffffffffa0475caf>] fm10k_update_stats+0x7f/0x2c0 [fm10k]
      [  628.693173] PGD 0
      [  628.693759] Oops: 0000 [#1] SMP
      [  628.699321] CPU: 10 PID: 8164 Comm: kworker/10:0 Tainted: G           OE  ------------   3.10.0-327.el7.x86_64 #1
      [  628.700096] Hardware name: Supermicro X9DAi/X9DAi, BIOS 3.2 05/09/2015
      [  628.700894] Workqueue: pciehp-1 pciehp_power_thread
      [  628.701686] task: ffff88086559c500 ti: ffff8808593c0000 task.ti: ffff8808593c0000
      [  628.702493] RIP: 0010:[<ffffffffa0475caf>]  [<ffffffffa0475caf>] fm10k_update_stats+0x7f/0x2c0 [fm10k]
      [  628.703310] RSP: 0018:ffff8808593c3b00  EFLAGS: 00010282
      [  628.704132] RAX: 0000000000000000 RBX: ffff880860760000 RCX: 0000000000000000
      [  628.704963] RDX: ffff880860760b08 RSI: 0000000000000000 RDI: 0000000000000000
      [  628.705794] RBP: ffff8808593c3b40 R08: 0000000000000000 R09: 0000000000000000
      [  628.706604] R10: 0000000000000000 R11: ffff880860760c40 R12: 0000000000000080
      [  628.707420] R13: ffff8808607608c0 R14: ffff880860779ec0 R15: ffff880860779f40
      [  628.708238] FS:  0000000000000000(0000) GS:ffff88086f000000(0000) knlGS:0000000000000000
      [  628.709071] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  628.709923] CR2: 0000000000000068 CR3: 000000000194a000 CR4: 00000000001407e0
      [  628.710752] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  628.711596] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  628.712438] Stack:
      [  628.713255]  ffff880860764458 ffff8808607608c0 ffff880860760000 ffff880860760000
      [  628.714088]  0000000000000080 ffff8808607608c0 ffff880860779ec0 ffff880860779f40
      [  628.714925]  ffff8808593c3b88 ffffffffa04780c5 ffff880860764458 0000000a8163cb5b
      [  628.715752] Call Trace:
      [  628.716560]  [<ffffffffa04780c5>] fm10k_down+0x155/0x1f0 [fm10k]
      [  628.717367]  [<ffffffffa0479958>] fm10k_close+0x28/0xd0 [fm10k]
      [  628.718184]  [<ffffffff81526365>] __dev_close_many+0x85/0xd0
      [  628.718986]  [<ffffffff815264d8>] dev_close_many+0x98/0x120
      [  628.719764]  [<ffffffff81527ab8>] rollback_registered_many+0xa8/0x230
      [  628.720527]  [<ffffffff81527c80>] rollback_registered+0x40/0x70
      [  628.721294]  [<ffffffff81529198>] unregister_netdevice_queue+0x48/0x80
      [  628.722052]  [<ffffffff815291ec>] unregister_netdev+0x1c/0x30
      [  628.722816]  [<ffffffffa04762b8>] fm10k_remove+0xd8/0xe0 [fm10k]
      [  628.723581]  [<ffffffff81328c7b>] pci_device_remove+0x3b/0xb0
      [  628.724340]  [<ffffffff813f5fbf>] __device_release_driver+0x7f/0xf0
      [  628.725088]  [<ffffffff813f6053>] device_release_driver+0x23/0x30
      [  628.725814]  [<ffffffff81321fe4>] pci_stop_bus_device+0x94/0xa0
      [  628.726535]  [<ffffffff813220d2>] pci_stop_and_remove_bus_device+0x12/0x20
      [  628.727249]  [<ffffffff8133de40>] pciehp_unconfigure_device+0xb0/0x1b0
      [  628.727964]  [<ffffffff8133d822>] pciehp_disable_slot+0x52/0xd0
      [  628.728664]  [<ffffffff8133d98a>] pciehp_power_thread+0xea/0x150
      [  628.729358]  [<ffffffff8109d5fb>] process_one_work+0x17b/0x470
      [  628.730036]  [<ffffffff8109e3cb>] worker_thread+0x11b/0x400
      [  628.730730]  [<ffffffff8109e2b0>] ? rescuer_thread+0x400/0x400
      [  628.731385]  [<ffffffff810a5aef>] kthread+0xcf/0xe0
      [  628.732036]  [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
      [  628.732674]  [<ffffffff81645858>] ret_from_fork+0x58/0x90
      [  628.733289]  [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
      [  628.733883] Code: 83 e8 01 48 8d 97 40 02 00 00 45 31 c0 4c 8d 9c c7 48 02 0
      [  628.735202] RIP  [<ffffffffa0475caf>] fm10k_update_stats+0x7f/0x2c0 [fm10k]
      [  628.735732]  RSP <ffff8808593c3b00>
      [  628.736285] CR2: 0000000000000068
      [  628.736846] ---[ end trace 9156088b311aff42 ]---
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4be37c42
    • J
      fm10k: base queue scheme covered by RSS · b3525696
      Jacob Keller 提交于
      In fm10k_set_num_queues, we previously assigned the base template. This
      would always be overwritten by either fm10k_set_qos_queues or
      fm10k_set_rss_queues. In either case, we don't need the base values, so
      we can just remove them.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b3525696
    • B
      fm10k: cleanup remaining right-bit-shifted 1 · fcdb0a99
      Bruce Allan 提交于
      Use BIT() macro instead.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fcdb0a99
    • B
      fm10k: Move constants to the right of binary operators · 1aab144c
      Bruce Allan 提交于
      The semantic patch that makes this change is available
      in scripts/coccinelle/misc/compare_const_fl.cocci.
      
      More information about semantic patching is available at
      http://coccinelle.lip6.fr/Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1aab144c
  13. 18 3月, 2016 1 次提交
    • J
      mm: introduce page reference manipulation functions · fe896d18
      Joonsoo Kim 提交于
      The success of CMA allocation largely depends on the success of
      migration and key factor of it is page reference count.  Until now, page
      reference is manipulated by direct calling atomic functions so we cannot
      follow up who and where manipulate it.  Then, it is hard to find actual
      reason of CMA allocation failure.  CMA allocation should be guaranteed
      to succeed so finding offending place is really important.
      
      In this patch, call sites where page reference is manipulated are
      converted to introduced wrapper function.  This is preparation step to
      add tracepoint to each page reference manipulation function.  With this
      facility, we can easily find reason of CMA allocation failure.  There is
      no functional change in this patch.
      
      In addition, this patch also converts reference read sites.  It will
      help a second step that renames page._count to something else and
      prevents later attempt to direct access to it (Suggested by Andrew).
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fe896d18
  14. 17 2月, 2016 1 次提交
  15. 22 12月, 2015 1 次提交
  16. 14 12月, 2015 3 次提交
  17. 06 12月, 2015 1 次提交