Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 163
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 01 10月, 2005 3 次提交
    • R
      [PATCH] x86_64 early numa init fix · 85cc5135
      由 Ravikiran G Thirumalai 提交于 
      The tests Alok carried out on Petr's box confirmed that cpu_to_node[BP] is
not setup early enough by numa_init_array due to the x86_64 changes in
2.6.14-rc*, and unfortunately set wrongly by the work around code in
numa_init_array().  cpu_to_node[0] gets set with 1 early and later gets set
properly to 0 during identify_cpu() when all cpus are brought up, but
confusing the numa slab in the process.

Here is a quick fix for this.  The right fix obviously is to have
cpu_to_node[bsp] setup early for numa_init_array().  The following patch
will fix the problem now, and the code can stay on even when
cpu_to_node{BP] gets fixed early correctly.

Thanks to Petr for access to his box.

Signed off by: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: NAlok N Kataria <alokk@calsoftinc.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      85cc5135
    • R
      [PATCH] x86_64: fix the BP node_to_cpumask · e6a045a5
      由 Ravikiran G Thirumalai 提交于 
      Fix the BP node_to_cpumask.  2.6.14-rc* broke the boot cpu bit as the
cpu_to_node(0) is now not setup early enough for numa_init_array.
cpu_to_node[] is setup much later at srat_detect_node on acpi srat based
em64t machines.  This seems like a problem on amd machines too, Tested on
em64t though.  /sys/devices/system/node/node0/cpumap shows up sanely after
this patch.

Signed off by: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: NShai Fultheim <shai@scalex86.org>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e6a045a5
    • Z
      [PATCH] utilization of kprobe_mutex is incorrect on x86_64 · 2dd960d6
      由 Zhang, Yanmin 提交于 
      The up()/down() orders are incorrect in arch/x86_64/kprobes.c file.
kprobe_mutext is used to protect the free kprobe instruction slot list.
arch_prepare_kprobe applies for a slot from the free list, and
arch_remove_kprobe returns a slot to the free list.  The incorrect up()/down()
orders to operate on kprobe_mutex fail to protect the free list.  If 2 threads
try to get/return kprobe instruction slot at the same time, the free slot list
might be broken, or a free slot might be applied by 2 threads.
Signed-off-by: NZhang Yanmin <Yanmin.zhang@intel.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2dd960d6
  3. 30 9月, 2005 2 次提交
  5. 28 9月, 2005 1 次提交
  7. 22 9月, 2005 1 次提交
  9. 18 9月, 2005 2 次提交
  11. 15 9月, 2005 3 次提交
    • D
      [LIB]: Consolidate _atomic_dec_and_lock() · 4db2ce01
      由 David S. Miller 提交于 
      Several implementations were essentialy a common piece of C code using
the cmpxchg() macro.  Put the implementation in one spot that everyone
can share, and convert sparc64 over to using this.

Alpha is the lone arch-specific implementation, which codes up a
special fast path for the common case in order to avoid GP reloading
which a pure C version would require.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4db2ce01
    • L
      Partially revert "Fix time going twice as fast problem on ATI Xpress chipsets" · 1619cca2
      由 Linus Torvalds 提交于 
      Commit 66759a01 introduced the fix for
time ticking too fast on some boards by disabling one of the doubly
connected timer pins on ATI boards.

However, it ends up being _much_ too broad a brush, and that just makes
some other ATI boards not work at all since they now have no timer
source.

So disable the automatic ATI southbridge detection, and just rely on
people who see this problem disabling it by hand with the option
"disable_timer_pin_1" on the kernel command line.

Maybe somebody can figure out the proper tests at a later date.
Acked-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1619cca2
    • H
      [PATCH] error path in setup_arg_pages() misses vm_unacct_memory() · 2fd4ef85
      由 Hugh Dickins 提交于 
      Pavel Emelianov and Kirill Korotaev observe that fs and arch users of
security_vm_enough_memory tend to forget to vm_unacct_memory when a
failure occurs further down (typically in setup_arg_pages variants).

These are all users of insert_vm_struct, and that reservation will only
be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some
cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't.

So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into
Committed_AS each time they're run.  But don't add VM_ACCOUNT to them,
it's inappropriate to reserve against the very unlikely case that gdb
be used to COW a vDSO page - we ought to do something about that in
do_wp_page, but there are yet other inconsistencies to be resolved.

The safe and economical way to fix this is to let insert_vm_struct do
the security_vm_enough_memory check when it finds VM_ACCOUNT is set.

And the MIPS irix_brk has been calling security_vm_enough_memory before
calling do_brk which repeats it, doubly accounting and so also leaking.
Remove that, and all the fs and arch calls to security_vm_enough_memory:
give it a less misleading name later on.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-Off-By: NKirill Korotaev <dev@sw.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2fd4ef85
  13. 14 9月, 2005 1 次提交
  15. 13 9月, 2005 27 次提交