1. 05 5月, 2009 1 次提交
    • A
      x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo · 35d11680
      Andreas Herrmann 提交于
      Commit 7ad728f9
      (cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
      changed the output of /proc/cpuinfo for siblings:
      
      Example on an AMD Phenom:
      
        physical id   : 0
        siblings : 1
        core id	   : 3
        cpu cores  : 4
      
      Before that commit it was:
      
        physical id	: 0
        siblings : 4
        core id	   : 3
        cpu cores  : 4
      
      Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
      This is due to the following hunk of above commit:
      
      |  --- a/arch/x86/kernel/cpu/proc.c
      |  +++ b/arch/x86/kernel/cpu/proc.c
      |  @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
      |          if (c->x86_max_cores * smp_num_siblings > 1) {
      |                  seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
      |                  seq_printf(m, "siblings\t: %d\n",
      |  -                          cpus_weight(per_cpu(cpu_core_map, cpu)));
      |  +                          cpumask_weight(cpu_sibling_mask(cpu)));
      |                  seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
      |                  seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
      |                  seq_printf(m, "apicid\t\t: %d\n", c->apicid);
      
      This was a mistake, because the impact line shows that this side-effect
      was not anticipated:
      
         Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y
      
      So revert the respective hunk to restore the old behavior.
      
      [ Impact: fix sibling-info regression in /proc/cpuinfo ]
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      LKML-Reference: <20090504182859.GA29045@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      35d11680
  2. 04 5月, 2009 1 次提交
  3. 02 5月, 2009 1 次提交
  4. 30 4月, 2009 1 次提交
    • J
      x86: gettimeofday() vDSO: fix segfault when tv == NULL · 2f65dd47
      John Wright 提交于
      According to the gettimeofday(2) manual:
      
             If either tv or tz is NULL, the corresponding structure is not
             set or returned.
      
      Since it is legal to give NULL as the tv argument, the code should make
      sure tv is not NULL before trying to dereference it.
      
      This issue manifests itself on x86_64 when vdso=0 is not on the kernel
      command-line and libc uses the vDSO for gettimeofday() (e.g. glibc >=
      2.7).  A simple reproducer:
      
        #include <stdio.h>
        #include <sys/time.h>
      
        int main(void)
        {
            struct timezone tz;
      
            gettimeofday(NULL, &tz);
      
            return 0;
        }
      
      See http://bugs.debian.org/466491 for more details.
      
      [ Impact: fix gettimeofday(NULL, &tz) segfault ]
      Signed-off-by: NJohn Wright <john.wright@hp.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: John Wright <john.wright@hp.com>
      LKML-Reference: <1241037121-14805-1-git-send-email-john.wright@hp.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2f65dd47
  5. 29 4月, 2009 2 次提交
  6. 28 4月, 2009 11 次提交
  7. 27 4月, 2009 14 次提交
  8. 24 4月, 2009 4 次提交
  9. 23 4月, 2009 5 次提交