1. 08 7月, 2008 10 次提交
    • J
      x86: compile error fix for smpboot.c · f307d25e
      Jeremy Fitzhardinge 提交于
      Without this patch, my link fails with:
      
      arch/x86/kernel/built-in.o(.cpuinit.text+0x3c6e): In function `get_local_pda':
      : undefined reference to `_cpu_pda'
      arch/x86/kernel/built-in.o(.cpuinit.text+0x3cd1): In function `get_local_pda':
      : undefined reference to `after_bootmem'
      arch/x86/kernel/built-in.o(.cpuinit.text+0x3cec): In function `get_local_pda':
      : undefined reference to `_cpu_pda'
      make[2]: *** [.tmp_vmlinux1] Error 1
      
      Caused by commit 766da892634694f795b18b9538407816896fc470
          x86: remove static boot_cpu_pda array v2
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f307d25e
    • M
      x86: leave initial __cpu_pda array in place until cpus are booted · 5deb0b2a
      Mike Travis 提交于
      Ingo Molnar wrote:
      ...
      > they crashed after about 3 randconfig iterations with:
      >
      >   early res: 4 [8000-afff] PGTABLE
      >   early res: 5 [b000-b87f] MEMNODEMAP
      > PANIC: early exception 0e rip 10:ffffffff8077a150 error 2 cr2 37
      > Pid: 0, comm: swapper Not tainted 2.6.25-sched-devel.git-x86-latest.git #14
      >
      > Call Trace:
      >  [<ffffffff81466196>] early_idt_handler+0x56/0x6a
      >  [<ffffffff8077a150>] ? numa_set_node+0x30/0x60
      >  [<ffffffff8077a129>] ? numa_set_node+0x9/0x60
      >  [<ffffffff8147a543>] numa_init_array+0x93/0xf0
      >  [<ffffffff8147b039>] acpi_scan_nodes+0x3b9/0x3f0
      >  [<ffffffff8147a496>] numa_initmem_init+0x136/0x150
      >  [<ffffffff8146da5f>] setup_arch+0x48f/0x700
      >  [<ffffffff802566ea>] ? clockevents_register_notifier+0x3a/0x50
      >  [<ffffffff81466a87>] start_kernel+0xd7/0x440
      >  [<ffffffff81466422>] x86_64_start_kernel+0x222/0x280
      ...
      Here's the fixup...  This one should follow the previous patches.
      
      Thanks,
      Mike
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5deb0b2a
    • M
      x86: remove static boot_cpu_pda array v2 · 3461b0af
      Mike Travis 提交于
        * Remove the boot_cpu_pda array and pointer table from the data section.
          Allocate the pointer table and array during init.  do_boot_cpu()
          will reallocate the pda in node local memory and if the cpu is being
          brought up before the bootmem array is released (after_bootmem = 0),
          then it will free the initial pda.  This will happen for all cpus
          present at system startup.
      
          This removes 512k + 32k bytes from the data section.
      
      For inclusion into sched-devel/latest tree.
      
      Based on:
      	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
          +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3461b0af
    • M
      x86: remove the static 256k node_to_cpumask_map · 9f248bde
      Mike Travis 提交于
        * Consolidate node_to_cpumask operations and remove the 256k
          byte node_to_cpumask_map.  This is done by allocating the
          node_to_cpumask_map array after the number of possible nodes
          (nr_node_ids) is known.
      
        * Debug printouts when CONFIG_DEBUG_PER_CPU_MAPS is active have
          been increased.  It now shows faults when calling node_to_cpumask()
          and node_to_cpumask_ptr().
      
      For inclusion into sched-devel/latest tree.
      
      Based on:
      	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
          +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9f248bde
    • M
      x86: restore pda nodenumber field · 7891a24e
      Mike Travis 提交于
        * Restore the nodenumber field in the x86_64 pda.  This field is slightly
          different than the x86_cpu_to_node_map mainly because it's a static
          indication of which node the cpu is on while the cpu to node map is a
          dyanamic mapping that may get reset if the cpu goes offline.  This also
          simplifies the numa_node_id() macro.
      
      For inclusion into sched-devel/latest tree.
      
      Based on:
      	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
          +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7891a24e
    • M
      x86: cleanup early per cpu variables/accesses v4 · 23ca4bba
      Mike Travis 提交于
        * Introduce a new PER_CPU macro called "EARLY_PER_CPU".  This is
          used by some per_cpu variables that are initialized and accessed
          before there are per_cpu areas allocated.
      
          ["Early" in respect to per_cpu variables is "earlier than the per_cpu
          areas have been setup".]
      
          This patchset adds these new macros:
      
      	DEFINE_EARLY_PER_CPU(_type, _name, _initvalue)
      	EXPORT_EARLY_PER_CPU_SYMBOL(_name)
      	DECLARE_EARLY_PER_CPU(_type, _name)
      
      	early_per_cpu_ptr(_name)
      	early_per_cpu_map(_name, _idx)
      	early_per_cpu(_name, _cpu)
      
          The DEFINE macro defines the per_cpu variable as well as the early
          map and pointer.  It also initializes the per_cpu variable and map
          elements to "_initvalue".  The early_* macros provide access to
          the initial map (usually setup during system init) and the early
          pointer.  This pointer is initialized to point to the early map
          but is then NULL'ed when the actual per_cpu areas are setup.  After
          that the per_cpu variable is the correct access to the variable.
      
          The early_per_cpu() macro is not very efficient but does show how to
          access the variable if you have a function that can be called both
          "early" and "late".  It tests the early ptr to be NULL, and if not
          then it's still valid.  Otherwise, the per_cpu variable is used
          instead:
      
      	#define early_per_cpu(_name, _cpu) 			\
      		(early_per_cpu_ptr(_name) ?			\
      			early_per_cpu_ptr(_name)[_cpu] :	\
      			per_cpu(_name, _cpu))
      
          A better method is to actually check the pointer manually.  In the
          case below, numa_set_node can be called both "early" and "late":
      
      	void __cpuinit numa_set_node(int cpu, int node)
      	{
      	    int *cpu_to_node_map = early_per_cpu_ptr(x86_cpu_to_node_map);
      
      	    if (cpu_to_node_map)
      		    cpu_to_node_map[cpu] = node;
      	    else
      		    per_cpu(x86_cpu_to_node_map, cpu) = node;
      	}
      
        * Add a flag "arch_provides_topology_pointers" that indicates pointers
          to topology cpumask_t maps are available.  Otherwise, use the function
          returning the cpumask_t value.  This is useful if cpumask_t set size
          is very large to avoid copying data on to/off of the stack.
      
        * The coverage of CONFIG_DEBUG_PER_CPU_MAPS has been increased while
          the non-debug case has been optimized a bit.
      
        * Remove an unreferenced compiler warning in drivers/base/topology.c
      
        * Clean up #ifdef in setup.c
      
      For inclusion into sched-devel/latest tree.
      
      Based on:
      	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
          +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      23ca4bba
    • M
      x86: modify Kconfig to allow up to 4096 cpus · 1184dc2f
      Mike Travis 提交于
        * Increase the limit of NR_CPUS to 4096 and introduce a boolean
          called "MAXSMP" which when set (e.g. "allyesconfig"), will set
          NR_CPUS = 4096 and NODES_SHIFT = 9 (512).
      
        * Changed max setting for NODES_SHIFT from 15 to 9 to accurately
          reflect the real limit.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1184dc2f
    • M
      x86: fix remove cpu_pda table patch · 7496b606
      Mike Travis 提交于
      Mike Travis wrote:
      > Ingo Molnar wrote:
      >> * Mike Travis <travis@sgi.com> wrote:
      >>
      >>> [Ingo - please replace "PATCH 07/11" with this one.]
      
      > >>>     *	Remove 544k bytes from the kernel by removing the boot_cpu_pda
      > >>> 	array from the data section and allocating it during startup.
      
      >>> 	Fixed panic in setup_per_cpu_areas when HOTPLUG_CPU not set.
      >>>
      >>> For inclusion into sched-devel/latest tree.
      >> sched-devel.git randconfig testing found another crash with your queue:
      >>
      >> [    0.111060] Brought up 1 CPUs
      >> [    0.111986] Total of 1 processors activated (4022.73 BogoMIPS).
      >> [    0.112987] Testing NMI watchdog ... <1>BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
      >> [    0.114982] IP: [<ffffffff8180d4a0>] check_nmi_watchdog+0xb0/0x210
      >> [    0.114982] PGD 0
      >> [    0.114982] Oops: 0000 [1] SMP
      >> [    0.114982] CPU 0
      >> [............]
      >>
      >>  http://redhat.com/~mingo/misc/config-Mon_Apr_28_23_25_25_CEST_2008.bad
      >>  http://redhat.com/~mingo/misc/log-Mon_Apr_28_23_25_25_CEST_2008.bad
      >>
      >> 	Ingo
      >
      > Hi Ingo,
      >
      > I need a bit more information on your hardware configuration.  Building a
      > kernel with the above config file started up fine on both the Intel and AMD
      > boxes.
      >
      > Based on the above output it looks like it might be a UP machine?
      ...
      
      Ok, I think I found it.  In check_nmi_watchdog():
      
              for (cpu = 0; cpu < NR_CPUS; cpu++)
                      prev_nmi_count[cpu] = cpu_pda(cpu)->__nmi_count;
      
      As I mentioned it works fine on both of my systems so could you try it out?
      
      Thanks!
      Mike
      --
      
        * Change function check_nmi_watchdog() to use nr_cpu_ids instead of NR_CPUS.
      
      Based on:
      	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
          +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7496b606
    • Y
      x86: don't call pxm_to_node again · dbb6152e
      Yinghai Lu 提交于
      also make bus_numa work even if ACPI_NUMA is not defined.
      
      don't call pxm_to_node again, and use node directly.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dbb6152e
    • Y
      x86: make dev_to_node return online node · b755de8d
      Yinghai Lu 提交于
      a numa system (with multi HT chains) may return node without ram. Aka it
      is not online. Try to get an online node, otherwise return -1.
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b755de8d
  2. 05 7月, 2008 5 次提交
  3. 04 7月, 2008 4 次提交
  4. 03 7月, 2008 2 次提交
    • A
      arch/x86/mm/init_64.c: early_memtest(): fix types · 27df66a4
      Andrew Morton 提交于
      fix this warning:
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:524: warning: passing argument 2 of 'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27df66a4
    • H
      x86: fix Intel Mac booting with EFI · 216705d2
      Hugh Dickins 提交于
      Fedora reports that mem_init()'s zap_low_mappings(), extended to SMP in
      61165d7a x86: fix app crashes after SMP
      resume causes 32-bit Intel Mac machines to reboot very early when
      booting with EFI.
      
      The EFI code appears to manage low mappings for itself when needed; but
      like many before it, confuses PSE with PAE.  So it has only been mapping
      half the space it needed when PSE but not PAE.  This remained unnoticed
      until we moved the SMP zap_low_mappings() before
      efi_enter_virtual_mode().  Presumably could have been noticed years ago
      if anyone ran a UP kernel on such machines?
      Reported-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Glauber Costa <gcosta@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NPeter Jones <pjones@redhat.com>
      216705d2
  5. 02 7月, 2008 3 次提交
  6. 01 7月, 2008 4 次提交
  7. 30 6月, 2008 2 次提交
    • T
      ptrace GET/SET FPXREGS broken · 11dbc963
      TAKADA Yoshihito 提交于
      When I update kernel 2.6.25 from 2.6.24, gdb does not work.
      On 2.6.25, ptrace(PTRACE_GETFPXREGS, ...) returns ENODEV.
      
      But 2.6.24 kernel's ptrace() returns EIO.
      It is issue of compatibility.
      
      I attached test program as pt.c and patch for fix it.
      
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <signal.h>
      #include <errno.h>
      #include <sys/ptrace.h>
      #include <sys/types.h>
      
      struct user_fxsr_struct {
      	unsigned short	cwd;
      	unsigned short	swd;
      	unsigned short	twd;
      	unsigned short	fop;
      	long	fip;
      	long	fcs;
      	long	foo;
      	long	fos;
      	long	mxcsr;
      	long	reserved;
      	long	st_space[32];	/* 8*16 bytes for each FP-reg = 128 bytes */
      	long	xmm_space[32];	/* 8*16 bytes for each XMM-reg = 128 bytes */
      	long	padding[56];
      };
      
      int main(void)
      {
        pid_t pid;
      
        pid = fork();
      
        switch(pid){
        case -1:/*  error */
          break;
        case 0:/*  child */
          child();
          break;
        default:
          parent(pid);
          break;
        }
        return 0;
      }
      
      int child(void)
      {
        ptrace(PTRACE_TRACEME);
        kill(getpid(), SIGSTOP);
        sleep(10);
        return 0;
      }
      int parent(pid_t pid)
      {
        int ret;
        struct user_fxsr_struct fpxregs;
      
        ret = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpxregs);
        if(ret < 0){
          printf("%d: %s.\n", errno, strerror(errno));
        }
        kill(pid, SIGCONT);
        wait(pid);
        return 0;
      }
      
      /* in the kerel, at kernel/i387.c get_fpxregs() */
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      11dbc963
    • Z
      x86: fix cpu hotplug crash · fcb43042
      Zhang, Yanmin 提交于
      Vegard Nossum reported crashes during cpu hotplug tests:
      
        http://marc.info/?l=linux-kernel&m=121413950227884&w=4
      
      In function _cpu_up, the panic happens when calling
      __raw_notifier_call_chain at the second time. Kernel doesn't panic when
      calling it at the first time. If just say because of nr_cpu_ids, that's
      not right.
      
      By checking the source code, I found that function do_boot_cpu is the culprit.
      Consider below call chain:
       _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
      
      So do_boot_cpu is called in the end. In do_boot_cpu, if
      boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later
      on, when _cpu_up calls __raw_notifier_call_chain at the second time to
      report CPU_UP_CANCELED, because this cpu is already cleared from
      cpu_possible_map, get_cpu_sysdev returns NULL.
      
      Many resources are related to cpu_possible_map, so it's better not to
      change it.
      
      Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in
      cpu_possible_map.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Tested-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcb43042
  8. 26 6月, 2008 1 次提交
    • D
      x86: section/warning fixes · 0b1faeef
      Daniel J Blueman 提交于
      WARNING: arch/x86/mm/built-in.o(.text+0x3a1): Section mismatch in
      reference from the function set_pte_phys() to the function
      .init.text:spp_getpage()
      The function set_pte_phys() references
      the function __init spp_getpage().
      This is often because set_pte_phys lacks a __init
      annotation or the annotation of spp_getpage is wrong.
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:520: warning: passing argument 2 of
      'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b1faeef
  9. 25 6月, 2008 9 次提交
    • B
      Blackfin arch: fix up section mismatch warning · 8d0a6003
      Bryan Wu 提交于
      --
      WARNING: vmlinux.o(.text+0x721a): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x7238): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x7250): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x7264): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72a2): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72bc): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72d4): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72e8): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      --
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      8d0a6003
    • S
      Blackfin arch: fix bug - kernel boot fails when Spinlock and rw-lock debugging enabled · 71a7d155
      Sonic Zhang 提交于
      Initialize the lock of bad_irq_desc properly.
      The content of irq_desc array is replaced by bad_irq_desc in blackfin
      arch irqchip init code. So, do it properly as common irq init code.
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      71a7d155
    • G
      x86: KVM guest: Use the paravirt clocksource structs and functions · f6e16d5a
      Gerd Hoffmann 提交于
      This patch updates the kvm host code to use the pvclock structs
      and functions, thereby making it compatible with Xen.
      
      The patch also fixes an initialization bug: on SMP systems the
      per-cpu has two different locations early at boot and after CPU
      bringup.  kvmclock must take that in account when registering the
      physical address within the host.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      f6e16d5a
    • G
      KVM: Make kvm host use the paravirt clocksource structs · 50d0a0f9
      Gerd Hoffmann 提交于
      This patch updates the kvm host code to use the pvclock structs.
      It also makes the paravirt clock compatible with Xen.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      50d0a0f9
    • G
      x86: Make xen use the paravirt clocksource structs and functions · 1c7b67f7
      Gerd Hoffmann 提交于
      This patch updates the xen guest to use the pvclock structs
      and helper functions.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      1c7b67f7
    • G
      x86: Add structs and functions for paravirt clocksource · 7af192c9
      Gerd Hoffmann 提交于
      This patch adds structs for the paravirt clocksource ABI
      used by both xen and kvm (pvclock-abi.h).
      
      It also adds some helper functions to read system time and
      wall clock time from a paravirtual clocksource (pvclock.[ch]).
      They are based on the xen code.  They are enabled using
      CONFIG_PARAVIRT_CLOCK.
      
      Subsequent patches of this series will put the code in use.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      7af192c9
    • J
      [IA64] Eliminate NULL test after alloc_bootmem in iosapic_alloc_rte() · e2569b7e
      Julia Lawall 提交于
      As noted by Akinobu Mita alloc_bootmem and related functions never return
      NULL and always return a zeroed region of memory.  Thus a NULL test or
      memset after calls to these functions is unnecessary.
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e2569b7e
    • C
      [IA64] Handle count==0 in sn2_ptc_proc_write() · 8097110d
      Cliff Wickman 提交于
      The fix applied in e0c6d97c
      "security hole in sn2_ptc_proc_write" didn't take into account
      the case where count==0 (which results in a buffer underrun
      when adding the trailing '\0').  Thanks to Andi Kleen for
      pointing this out.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      8097110d
    • J
      [IA64] Fix boot failure on ia64/sn2 · 2826f8c0
      Jes Sorensen 提交于
      Call check_sal_cache_flush() after platform_setup() as
      check_sal_cache_flush() now relies on being able to call platform
      vector code.
      
      Problem was introduced by: 3463a93d
      "Update check_sal_cache_flush to use platform_send_ipi()"
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Tested-by: NAlex Chiang: <achiang@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      2826f8c0