1. 29 7月, 2006 1 次提交
    • B
      [PATCH] x86_64: Enlarge debug stack for nested kprobes · a4045dff
      bibo mao 提交于
      In x86_64 platform, INT1 and INT3 trap stack is IST stack called DEBUG_STACK,
      when INT1/INT3 trap happens, system will switch to DEBUG_STACK by hardware.
      Current DEBUG_STACK size is 4K, when int1/int3 trap happens, kernel will
      minus current DEBUG_STACK IST value by 4k. But if int3/int1 trap is nested,
      it will destroy other vector's IST stack. This patch modifies this, it sets
      DEBUG_STACK size as 8K and allows two level of nested int1/int3 trap.
      
      Kprobe DEBUG_STACK may be nested, because kprobe handler may be probed
      by other kprobes.
      
      Thanks jbeulich for pointing out error in the first patch.
      
      [AK: nested kprobes are pretty dubious. Hopefully one nest
      will be enough. This will cost 8K per CPU (4K more than before)]
      Signed-off-by: Nbibo, mao <bibo.mao@intel.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a4045dff
  2. 28 7月, 2006 3 次提交
  3. 26 7月, 2006 1 次提交
    • A
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      Arjan van de Ven 提交于
      The patch below moves the cpu hotplugging higher up in the cpufreq
      layering; this is needed to avoid recursive taking of the cpu hotplug
      lock and to otherwise detangle the mess.
      
      The new rules are:
      1. you must do lock_cpu_hotplug() around the following functions:
         __cpufreq_driver_target
         __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
         __cpufreq_set_policy
      2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
         lock in any way; they are called with the lock taken already
      3. if your governer spawns a thread that does things, like calling
         __cpufreq_driver_target, your thread must honor rule #1.
      4. the policy lock and other cpufreq internal locks nest within
         the lock_cpu_hotplug() lock.
      
      I'm not entirely happy about how the __cpufreq_governor rule ended up
      (conditional locking rule depending on the argument) but basically all
      callers pass this as a constant so it's not too horrible.
      
      The patch also removes the cpufreq_governor() function since during the
      locking audit it turned out to be entirely unused (so no need to fix it)
      
      The patch works on my testbox, but it could use more testing
      (otoh... it can't be much worse than the current code)
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      153d7f3f
  4. 25 7月, 2006 6 次提交
  5. 24 7月, 2006 1 次提交
    • L
      cpu hotplug: simplify and hopefully fix locking · aa953877
      Linus Torvalds 提交于
      The CPU hotplug locking was quite messy, with a recursive lock to
      handle the fact that both the actual up/down sequence wanted to
      protect itself from being re-entered, but the callbacks that it
      called also tended to want to protect themselves from CPU events.
      
      This splits the lock into two (one to serialize the whole hotplug
      sequence, the other to protect against the CPU present bitmaps
      changing). The latter still allows recursive usage because some
      subsystems (ondemand policy for cpufreq at least) had already gotten
      too used to the lax locking, but the locking mistakes are hopefully
      now less fundamental, and we now warn about recursive lock usage
      when we see it, in the hope that it can be fixed.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      aa953877
  6. 22 7月, 2006 6 次提交
  7. 17 7月, 2006 2 次提交
  8. 15 7月, 2006 20 次提交