1. 03 7月, 2008 14 次提交
  2. 02 7月, 2008 13 次提交
  3. 01 7月, 2008 10 次提交
    • 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
    • R
      sched: fix divide error when trying to configure rt_period to zero · 619b0488
      Raistlin 提交于
      Here it is another little Oops we found while configuring invalid values
      via cgroups:
      
      echo 0 > /dev/cgroups/0/cpu.rt_period_us
      or
      echo 4294967296 > /dev/cgroups/0/cpu.rt_period_us
      
      [  205.509825] divide error: 0000 [#1]
      [  205.510151] Modules linked in:
      [  205.510151]
      [  205.510151] Pid: 2339, comm: bash Not tainted (2.6.26-rc8 #33)
      [  205.510151] EIP: 0060:[<c030c6ef>] EFLAGS: 00000293 CPU: 0
      [  205.510151] EIP is at div64_u64+0x5f/0x70
      [  205.510151] EAX: 0000389f EBX: 00000000 ECX: 00000000 EDX: 00000000
      [  205.510151] ESI: d9800000 EDI: 00000000 EBP: c6cede60 ESP: c6cede50
      [  205.510151]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [  205.510151] Process bash (pid: 2339, ti=c6cec000 task=c79be370 task.ti=c6cec000)
      [  205.510151] Stack: d9800000 0000389f c05971a0 d9800000 c6cedeb4 c0214dbd 00000000 00000000
      [  205.510151]        c6cede88 c0242bd8 c05377c0 c7a41b40 00000000 00000000 00000000 c05971a0
      [  205.510151]        c780ed20 c7508494 c7a41b40 00000000 00000002 c6cedebc c05971a0 ffffffea
      [  205.510151] Call Trace:
      [  205.510151]  [<c0214dbd>] ? __rt_schedulable+0x1cd/0x240
      [  205.510151]  [<c0242bd8>] ? cgroup_file_open+0x18/0xe0
      [  205.510151]  [<c0214fe4>] ? tg_set_bandwidth+0xa4/0xf0
      [  205.510151]  [<c0215066>] ? sched_group_set_rt_period+0x36/0x50
      [  205.510151]  [<c021508e>] ? cpu_rt_period_write_uint+0xe/0x10
      [  205.510151]  [<c0242dc5>] ? cgroup_file_write+0x125/0x160
      [  205.510151]  [<c0232c15>] ? hrtimer_interrupt+0x155/0x190
      [  205.510151]  [<c02f047f>] ? security_file_permission+0xf/0x20
      [  205.510151]  [<c0277ad8>] ? rw_verify_area+0x48/0xc0
      [  205.510151]  [<c0283744>] ? dupfd+0x104/0x130
      [  205.510151]  [<c027838c>] ? vfs_write+0x9c/0x160
      [  205.510151]  [<c0242ca0>] ? cgroup_file_write+0x0/0x160
      [  205.510151]  [<c027850d>] ? sys_write+0x3d/0x70
      [  205.510151]  [<c0203019>] ? sysenter_past_esp+0x6a/0x91
      [  205.510151]  =======================
      [  205.510151] Code: 0f 45 de 31 f6 0f ad d0 d3 ea f6 c1 20 0f 45 c2 0f 45 d6 89 45 f0 89 55 f4 8b 55 f4 31 c9 8b 45 f0 39 d3 89 c6 77 08 89 d0 31 d2 <f7> f3 89 c1 83 c4 08 89 f0 f7 f3 89 ca 5b 5e 5d c3 55 89 e5 56
      [  205.510151] EIP: [<c030c6ef>] div64_u64+0x5f/0x70 SS:ESP 0068:c6cede50
      
      The attached patch solves the issue for me.
      
      I'm checking as soon as possible for the period not being zero since, if
      it is, going ahead is useless. This way we also save a mutex_lock() and
      a read_lock() wrt doing it inside tg_set_bandwidth() or
      __rt_schedulable().
      Signed-off-by: NDario Faggioli <raistlin@linux.it>
      Signed-off-by: NMichael Trimarchi <trimarchimichael@yahoo.it>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      619b0488
    • 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
    • C
      [ARM] 5131/1: Annotate platform_secondary_init with trace_hardirqs_off · 08383ef2
      Catalin Marinas 提交于
      This patch annotates the platform_secondary_init function in
      arch/arm/mach-realview/platsmp.c with trace_hardirqs_off to avoid a
      warning when LOCKDEP and TRACE_IRQFLAGS are enabled.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      08383ef2
  4. 30 6月, 2008 3 次提交