1. Dec 20, 2007
    • Kenji Kaneshige's avatar
      [IA64] Remove compiler warinings about uninitialized variable in irq_ia64.c · 373167e8
      Kenji Kaneshige authored
      
      
      This patch removes the following compiler warning messages.
      
        CC      arch/ia64/kernel/irq_ia64.o
      arch/ia64/kernel/irq_ia64.c: In function 'create_irq':
      arch/ia64/kernel/irq_ia64.c:343: warning: 'domain.bits[0u]' may be used uninitialized in this function
      arch/ia64/kernel/irq_ia64.c: In function 'assign_irq_vector':
      arch/ia64/kernel/irq_ia64.c:203: warning: 'domain.bits[0u]' may be used uninitialized in this function
      
      Signed-off-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      373167e8
    • Ian Wienand's avatar
      [IA64] set_thread_area fails in IA32 chroot · e384f414
      Ian Wienand authored
      
      
      I tried to upgrade an IA32 chroot on my IA64 to a new glibc with TLS.
      It kept dying because set_thread_area was returning -ESRCH
      (bugs.debian.org/451939).
      
      I instrumented arch/ia64/ia32/sys_ia32.c:get_free_idx() and ended up
      seeing output like
      
      [pid] idx   desc->a  desc->b
      -----------------------------
      [2710] 0 -> c6b0ffff 40dff31b
      [2710] 1 -> 0 0
      [2710] 2 -> 0 0
      
      [2710] 0 -> c6b0ffff 40dff31b
      [2710] 1 -> c6b0ffff 40dff31b
      [2710] 2 -> 0 0
      
      [2711] 0 -> c6b0ffff 40dff31b
      [2711] 1 -> c6b0ffff 40dff31b
      [2711] 2 -> 48c0ffff 40dff317
      
      which suggested to me that TLS pointers were surviving exec() calls,
      leading to GDT pointers filling up and the eventual failure of
      get_free_idx().
      
      I think the solution is flushing the tls array on exec.
      
      Signed-Off-By: default avatarIan Wienand <ianw@gelato.unsw.edu.au>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      e384f414
  2. Dec 19, 2007
  3. Dec 18, 2007