1. 05 6月, 2015 2 次提交
  2. 04 6月, 2015 2 次提交
  3. 02 6月, 2015 5 次提交
  4. 01 6月, 2015 4 次提交
  5. 31 5月, 2015 19 次提交
  6. 29 5月, 2015 4 次提交
    • S
      tracing/mm: don't trace mm_page_pcpu_drain on offline cpus · 649b8de2
      Shreyas B. Prabhu 提交于
      Since tracepoints use RCU for protection, they must not be called on
      offline cpus.  trace_mm_page_pcpu_drain can be called on an offline cpu
      in this scenario caught by LOCKDEP:
      
           ===============================
           [ INFO: suspicious RCU usage. ]
           4.1.0-rc1+ #9 Not tainted
           -------------------------------
           include/trace/events/kmem.h:265 suspicious rcu_dereference_check() usage!
      
          other info that might help us debug this:
      
          RCU used illegally from offline CPU!
          rcu_scheduler_active = 1, debug_locks = 1
           1 lock held by swapper/5/0:
            #0:  (&(&zone->lock)->rlock){..-...}, at: [<c0000000002073b0>] .free_pcppages_bulk+0x70/0x920
      
          stack backtrace:
           CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.1.0-rc1+ #9
           Call Trace:
             .dump_stack+0x98/0xd4 (unreliable)
             .lockdep_rcu_suspicious+0x108/0x170
             .free_pcppages_bulk+0x60c/0x920
             .free_hot_cold_page+0x208/0x280
             .destroy_context+0x90/0xd0
             .__mmdrop+0x58/0x160
             .idle_task_exit+0xf0/0x100
             .pnv_smp_cpu_kill_self+0x58/0x2c0
             .cpu_die+0x34/0x50
             .arch_cpu_idle_dead+0x20/0x40
             .cpu_startup_entry+0x708/0x7a0
             .start_secondary+0x36c/0x3a0
             start_secondary_prolog+0x10/0x14
      
      Fix this by converting mm_page_pcpu_drain trace point into
      TRACE_EVENT_CONDITION where condition is cpu_online(smp_processor_id())
      Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
      Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      649b8de2
    • S
      tracing/mm: don't trace mm_page_free on offline cpus · 1f0c27b5
      Shreyas B. Prabhu 提交于
      Since tracepoints use RCU for protection, they must not be called on
      offline cpus.  trace_mm_page_free can be called on an offline cpu in this
      scenario caught by LOCKDEP:
      
           ===============================
           [ INFO: suspicious RCU usage. ]
           4.1.0-rc1+ #9 Not tainted
           -------------------------------
           include/trace/events/kmem.h:170 suspicious rcu_dereference_check() usage!
      
          other info that might help us debug this:
      
          RCU used illegally from offline CPU!
          rcu_scheduler_active = 1, debug_locks = 1
           no locks held by swapper/1/0.
      
          stack backtrace:
           CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
           Call Trace:
             .dump_stack+0x98/0xd4 (unreliable)
             .lockdep_rcu_suspicious+0x108/0x170
             .free_pages_prepare+0x494/0x680
             .free_hot_cold_page+0x50/0x280
             .destroy_context+0x90/0xd0
             .__mmdrop+0x58/0x160
             .idle_task_exit+0xf0/0x100
             .pnv_smp_cpu_kill_self+0x58/0x2c0
             .cpu_die+0x34/0x50
             .arch_cpu_idle_dead+0x20/0x40
             .cpu_startup_entry+0x708/0x7a0
             .start_secondary+0x36c/0x3a0
             start_secondary_prolog+0x10/0x14
      
      Fix this by converting mm_page_free trace point into TRACE_EVENT_CONDITION
      where condition is cpu_online(smp_processor_id())
      Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
      Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1f0c27b5
    • S
      tracing/mm: don't trace kmem_cache_free on offline cpus · e5feb1eb
      Shreyas B. Prabhu 提交于
      Since tracepoints use RCU for protection, they must not be called on
      offline cpus.  trace_kmem_cache_free can be called on an offline cpu in
      this scenario caught by LOCKDEP:
      
          ===============================
          [ INFO: suspicious RCU usage. ]
          4.1.0-rc1+ #9 Not tainted
          -------------------------------
          include/trace/events/kmem.h:148 suspicious rcu_dereference_check() usage!
      
          other info that might help us debug this:
      
          RCU used illegally from offline CPU!
          rcu_scheduler_active = 1, debug_locks = 1
          no locks held by swapper/1/0.
      
          stack backtrace:
          CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
          Call Trace:
            .dump_stack+0x98/0xd4 (unreliable)
            .lockdep_rcu_suspicious+0x108/0x170
            .kmem_cache_free+0x344/0x4b0
            .__mmdrop+0x4c/0x160
            .idle_task_exit+0xf0/0x100
            .pnv_smp_cpu_kill_self+0x58/0x2c0
            .cpu_die+0x34/0x50
            .arch_cpu_idle_dead+0x20/0x40
            .cpu_startup_entry+0x708/0x7a0
            .start_secondary+0x36c/0x3a0
            start_secondary_prolog+0x10/0x14
      
      Fix this by converting kmem_cache_free trace point into
      TRACE_EVENT_CONDITION where condition is cpu_online(smp_processor_id())
      Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
      Reported-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e5feb1eb
    • D
      percpu_counter: batch size aware __percpu_counter_compare() · 80188b0d
      Dave Chinner 提交于
      XFS uses non-stanard batch sizes for avoiding frequent global
      counter updates on it's allocated inode counters, as they increment
      or decrement in batches of 64 inodes. Hence the standard percpu
      counter batch of 32 means that the counter is effectively a global
      counter. Currently Xfs uses a batch size of 128 so that it doesn't
      take the global lock on every single modification.
      
      However, Xfs also needs to compare accurately against zero, which
      means we need to use percpu_counter_compare(), and that has a
      hard-coded batch size of 32, and hence will spuriously fail to
      detect when it is supposed to use precise comparisons and hence
      the accounting goes wrong.
      
      Add __percpu_counter_compare() to take a custom batch size so we can
      use it sanely in XFS and factor percpu_counter_compare() to use it.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      80188b0d
  7. 28 5月, 2015 4 次提交
    • J
      mac80211: Fix mac80211.h docbook comments · 3a7af58f
      Jonathan Corbet 提交于
      A couple of enums in mac80211.h became structures recently, but the
      comments didn't follow suit, leading to errors like:
      
        Error(.//include/net/mac80211.h:367): Cannot parse enum!
        Documentation/DocBook/Makefile:93: recipe for target 'Documentation/DocBook/80211.xml' failed
        make[1]: *** [Documentation/DocBook/80211.xml] Error 1
        Makefile:1361: recipe for target 'mandocs' failed
        make: *** [mandocs] Error 2
      
      Fix the comments comments accordingly.  Added a couple of other small
      comment fixes while I was there to silence other recently-added docbook
      warnings.
      Reported-by: NJim Davis <jim.epost@gmail.com>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3a7af58f
    • J
      ethtool: Add helper routines to pass vf to rx_flow_spec · 8cf6f497
      John Fastabend 提交于
      The ring_cookie is 64 bits wide which is much larger than can be used
      for actual queue index values. So provide some helper routines to
      pack a VF index into the cookie. This is useful to steer packets to
      a VF ring without having to know the queue layout of the device.
      
      CC: Alex Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8cf6f497
    • R
      cpumask_set_cpu_local_first => cpumask_local_spread, lament · f36963c9
      Rusty Russell 提交于
      da91309e (cpumask: Utility function to set n'th cpu...) created a
      genuinely weird function.  I never saw it before, it went through DaveM.
      (He only does this to make us other maintainers feel better about our own
      mistakes.)
      
      cpumask_set_cpu_local_first's purpose is say "I need to spread things
      across N online cpus, choose the ones on this numa node first"; you call
      it in a loop.
      
      It can fail.  One of the two callers ignores this, the other aborts and
      fails the device open.
      
      It can fail in two ways: allocating the off-stack cpumask, or through a
      convoluted codepath which AFAICT can only occur if cpu_online_mask
      changes.  Which shouldn't happen, because if cpu_online_mask can change
      while you call this, it could return a now-offline cpu anyway.
      
      It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
      drawn to my attention by Geert, who said this causes a warning on Sparc.
      It sets a single bit in a cpumask instead of returning a cpu number,
      because that's what the callers want.
      
      It could be made more efficient by passing the previous cpu rather than
      an index, but that would be more invasive to the callers.
      
      Fixes: da91309e
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased)
      Tested-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      f36963c9
    • E
      tcp/dccp: warn user for preferred ip_local_port_range · ed2dfd90
      Eric Dumazet 提交于
      After commit 07f4c900 ("tcp/dccp: try to not exhaust
      ip_local_port_range in connect()") it is advised to have an even number
      of ports described in /proc/sys/net/ipv4/ip_local_port_range
      
      This means start/end values should have a different parity.
      
      Let's warn sysadmins of this, so that they can update their settings
      if they want to.
      Suggested-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed2dfd90