1. 03 7月, 2008 10 次提交
  2. 02 7月, 2008 11 次提交
  3. 01 7月, 2008 8 次提交
    • G
      rcu: fix hotplug vs rcu race · 8558f8f8
      Gautham R Shenoy 提交于
      Dhaval Giani reported this warning during cpu hotplug stress-tests:
      
      | On running kernel compiles in parallel with cpu hotplug:
      |
      | WARNING: at arch/x86/kernel/smp.c:118
      | native_smp_send_reschedule+0x21/0x36()
      | Modules linked in:
      | Pid: 27483, comm: cc1 Not tainted 2.6.26-rc7 #1
      | [...]
      |  [<c0110355>] native_smp_send_reschedule+0x21/0x36
      |  [<c014fe8f>] force_quiescent_state+0x47/0x57
      |  [<c014fef0>] call_rcu+0x51/0x6d
      |  [<c01713b3>] __fput+0x130/0x158
      |  [<c0171231>] fput+0x17/0x19
      |  [<c016fd99>] filp_close+0x4d/0x57
      |  [<c016fdff>] sys_close+0x5c/0x97
      
      IMHO the warning is a spurious one.
      
      cpu_online_map is updated by the _cpu_down() using stop_machine_run().
      Since force_quiescent_state is invoked from irqs disabled section,
      stop_machine_run() won't be executing while a cpu is executing
      force_quiescent_state(). Hence the cpu_online_map is stable while we're
      in the irq disabled section.
      
      However, a cpu might have been offlined _just_ before we disabled irqs
      while entering force_quiescent_state(). And rcu subsystem might not yet
      have handled the CPU_DEAD notification, leading to the offlined cpu's
      bit being set in the rcp->cpumask.
      
      Hence cpumask = (rcp->cpumask & cpu_online_map) to prevent sending
      smp_reschedule() to an offlined CPU.
      
      Here's the timeline:
      
      CPU_A						 CPU_B
      --------------------------------------------------------------
      cpu_down():					.
      .					   	.
      .						.
      stop_machine(): /* disables preemption,		.
      		 * and irqs */			.
      .						.
      .						.
      take_cpu_down();				.
      .						.
      .						.
      .						.
      cpu_disable(); /*this removes cpu 		.
      		*from cpu_online_map 		.
      		*/				.
      .						.
      .						.
      restart_machine(); /* enables irqs */		.
      ------WINDOW DURING WHICH rcp->cpumask is stale ---------------
      .						call_rcu();
      .						/* disables irqs here */
      .						.force_quiescent_state();
      .CPU_DEAD:					.for_each_cpu(rcp->cpumask)
      .						.   smp_send_reschedule();
      .						.
      .						.   WARN_ON() for offlined CPU!
      .
      .
      .
      rcu_cpu_notify:
      .
      -------- WINDOW ENDS ------------------------------------------
      rcu_offline_cpu() /* Which calls cpu_quiet()
      		   * which removes
      		   * cpu from rcp->cpumask.
      		   */
      
      If a new batch was started just before calling stop_machine_run(), the
      "tobe-offlined" cpu is still present in rcp-cpumask.
      
      During a cpu-offline, from take_cpu_down(), we queue an rt-prio idle
      task as the next task to be picked by the scheduler. We also call
      cpu_disable() which will disable any further interrupts and remove the
      cpu's bit from the cpu_online_map.
      
      Once the stop_machine_run() successfully calls take_cpu_down(), it calls
      schedule(). That's the last time a schedule is called on the offlined
      cpu, and hence the last time when rdp->passed_quiesc will be set to 1
      through rcu_qsctr_inc().
      
      But the cpu_quiet() will be on this cpu will be called only when the
      next RCU_SOFTIRQ occurs on this CPU. So at this time, the offlined CPU
      is still set in rcp->cpumask.
      
      Now coming back to the idle_task which truely offlines the CPU, it does
      check for a pending RCU and raises the softirq, since it will find
      rdp->passed_quiesc to be 0 in this case. However, since the cpu is
      offline I am not sure if the softirq will trigger on the CPU.
      
      Even if it doesn't the rcu_offline_cpu() will find that rcp->completed
      is not the same as rcp->cur, which means that our cpu could be holding
      up the grace period progression. Hence we call cpu_quiet() and move
      ahead.
      
      But because of the window explained in the timeline, we could still have
      a call_rcu() before the RCU subsystem executes it's CPU_DEAD
      notification, and we send smp_send_reschedule() to offlined cpu while
      trying to force the quiescent states. The appended patch adds comments
      and prevents checking for offlined cpu everytime.
      
      cpu_online_map is updated by the _cpu_down() using stop_machine_run().
      Since force_quiescent_state is invoked from irqs disabled section,
      stop_machine_run() won't be executing while a cpu is executing
      force_quiescent_state(). Hence the cpu_online_map is stable while we're
      in the irq disabled section.
      Reported-by: NDhaval Giani <dhaval@linux.vnet.ibm.com>
      Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
      Acked-by: NDhaval Giani <dhaval@linux.vnet.ibm.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Rusty Russel <rusty@rustcorp.com.au>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8558f8f8
    • T
      x86: fix NODES_SHIFT Kconfig range · efac4189
      Thomas Gleixner 提交于
      commit 43238382
             x86: change size of node ids from u8 to s16
      
      set the range for NODES_SHIFT to 1..15.
      
      The possible range is 1..9
      
      Fixes Bugzilla #10726
      Reported-by: NDave Jones <davej@codemonkey.org.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      efac4189
    • D
    • E
      mac80211: don't accept WEP keys other than WEP40 and WEP104 · 23976efe
      Emmanuel Grumbach 提交于
      This patch makes mac80211 refuse a WEP key whose length is not WEP40 nor
      WEP104.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      23976efe
    • P
      hostap: fix sparse warnings · 1bcca3c4
      Pavel Roskin 提交于
      Rewrite AID calculation in handle_pspoll() to avoid truncating bits.
      Make hostap_80211_header_parse() static, don't export it.  Avoid
      shadowing variables.
      Signed-off-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1bcca3c4
    • P
      hostap: don't report useless WDS frames by default · 15ea0ebc
      Pavel Roskin 提交于
      DEBUG_EXTRA is reported to the kernel log by default, but DEBUG_EXTRA2
      is not.  Unrelated WDS frames pollute the log unnecessarily.
      Signed-off-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      15ea0ebc
    • J
      textsearch: fix Boyer-Moore text search bug · aebb6a84
      Joonwoo Park 提交于
      The current logic has a bug which cannot find matching pattern, if the
      pattern is matched from the first character of target string.
      for example:
      	pattern=abc, string=abcdefg
      	pattern=a,   string=abcdefg
      Searching algorithm should return 0 for those things.
      Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aebb6a84
    • J
      netfilter: nf_conntrack_tcp: fixing to check the lower bound of valid ACK · 84ebe1cd
      Jozsef Kadlecsik 提交于
      Lost connections was reported by Thomas Bätzler (running 2.6.25 kernel) on
      the netfilter mailing list (see the thread "Weird nat/conntrack Problem
      with PASV FTP upload"). He provided tcpdump recordings which helped to
      find a long lingering bug in conntrack.
      
      In TCP connection tracking, checking the lower bound of valid ACK could
      lead to mark valid packets as INVALID because:
      
       - We have got a "higher or equal" inequality, but the test checked
         the "higher" condition only; fixed.
       - If the packet contains a SACK option, it could occur that the ACK
         value was before the left edge of our (S)ACK "window": if a previous
         packet from the other party intersected the right edge of the window
         of the receiver, we could move forward the window parameters beyond
         accepting a valid ack. Therefore in this patch we check the rightmost
         SACK edge instead of the ACK value in the lower bound of valid (S)ACK
         test.
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84ebe1cd
  4. 30 6月, 2008 11 次提交