Skip to content
  1. Feb 24, 2010
  2. Feb 22, 2010
  3. Feb 20, 2010
  4. Feb 19, 2010
    • David S. Miller's avatar
      sparc64: Fix sun4u execute bit check in TSB I-TLB load. · 1f474646
      David S. Miller authored
      
      
      Thanks to testcase and report from Brad Spengler:
      
      --------------------
      #include <stdio.h>
      
      typedef int (* _wee)(void);
      
      int main(void)
      {
              char buf[8] = { '\x81', '\xc7', '\xe0', '\x08', '\x81', '\xe8',
                              '\x00', '\x00' };
              _wee wee;
              printf("%p\n", &buf);
              wee = (_wee)&buf;
              wee();
      
              return 0;
      }
      --------------------
      
      TSB I-tlb load code tries to use andcc to check the _PAGE_EXEC_4U bit,
      but that's bit 12 so it gets sign extended all the way up to bit 63
      and the test nearly always passes as a result.
      
      Use sethi to fix the bug.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f474646
    • Frederic Weisbecker's avatar
      hw-breakpoint: Keep track of dr7 local enable bits · 326264a0
      Frederic Weisbecker authored
      
      
      When the user enables breakpoints through dr7, he can choose
      between "local" or "global" enable bits but given how linux is
      implemented, both have the same effect.
      
      That said we don't keep track how the user enabled the breakpoints
      so when the user requests the dr7 value, we only translate the
      "enabled" status using the global enabled bits. It means that if
      the user enabled a breakpoint using the local enabled bit, reading
      back dr7 will set the global bit and clear the local one.
      
      Apps like Wine expect a full dr7 POKEUSER/PEEKUSER match for emulated
      softwares that implement old reverse engineering protection schemes.
      
      We fix that by keeping track of the whole dr7 value given by the user
      in the thread structure to drop this bug. We'll think about
      something more proper later.
      
      This fixes a 2.6.32 - 2.6.33-x ptrace regression.
      
      Reported-and-tested-by: default avatarMichael Stefaniuc <mstefani@redhat.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarK.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Maneesh Soni <maneesh@linux.vnet.ibm.com>
      Cc: Alexandre Julliard <julliard@winehq.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
      326264a0
    • Frederic Weisbecker's avatar
      hw-breakpoints: Accept breakpoints on NULL address · 84d71092
      Frederic Weisbecker authored
      
      
      Before we had a generic breakpoint API, ptrace was accepting
      breakpoints on NULL address in x86. The new API refuse them,
      without given strong reasons. We need to follow the previous
      behaviour as some userspace apps like Wine need such NULL
      breakpoints to ensure old emulated software protections
      are still working.
      
      This fixes a 2.6.32 - 2.6.33-x ptrace regression.
      
      Reported-and-tested-by: default avatarMichael Stefaniuc <mstefani@redhat.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarK.Prasad <prasad@linux.vnet.ibm.com>
      Acked-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Maneesh Soni <maneesh@linux.vnet.ibm.com>
      Cc: Alexandre Julliard <julliard@winehq.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
      84d71092
  5. Feb 18, 2010
  6. Feb 17, 2010
    • Ranjith Lohithakshan's avatar
      omap: Remove DEBUG_FS dependency for mux name checking · b72c7d54
      Ranjith Lohithakshan authored
      
      
      The check for a valid mux name should be performed regardless of whether
      DEBUG_FS is enabled or not. Otherwise without DEBUG_FS, we get:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1]
      last sysfs file:
      Modules linked in:
      CPU: 0    Not tainted  (2.6.33-rc8 #10)
      PC is at strcmp+0x18/0x40
      LR is at omap_mux_init_signal+0x68/0x14c
      ...
      
      This fixes the issue currently seen with boards not booting up
      if DEBUG_FS is not enabled in defconfig.
      
      Note that the earlier ifndef + ifdef now becomes simpler ifdef else:
      If CONFIG_OMAP_MUX is selected, we use pin names. If it's not selected,
      we only want the GPIO to mux register mapping.
      
      Signed-off-by: default avatarRanjith Lohithakshan <ranjithl@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      b72c7d54
  7. Feb 16, 2010
  8. Feb 15, 2010
    • Paul Mundt's avatar
      sh64: fix tracing of signals. · 4b505db9
      Paul Mundt authored
      
      
      This follows the parisc change to ensure that tracehook_signal_handler()
      is aware of when we are single-stepping in order to ptrace_notify()
      appropriately. While this was implemented for 32-bit SH, sh64 neglected
      to make use of TIF_SINGLESTEP when it was folded in with the 32-bit code,
      resulting in ptrace_notify() never being called.
      
      As sh64 uses all of the other abstractions already, this simply plugs in
      the thread flag in the appropriate enable/disable paths and fixes up the
      tracehook notification accordingly. With this in place, sh64 is brought
      in line with what 32-bit is already doing.
      
      Reported-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      4b505db9
  9. Feb 13, 2010
    • Peter Tyser's avatar
      powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem · d1d47ec6
      Peter Tyser authored
      
      
      Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
      the "cpu-release-addr" device tree property to contain the physical RAM
      location that secondary cores were spinning at.  Previously, the
      "cpu-release-addr" property contained a value referencing the boot page
      translation address range of 0xfffffxxx, which then indirectly accessed
      RAM.
      
      The "cpu-release-addr" is currently ioremapped and the secondary cores
      kicked.  However, due to the recent change in "cpu-release-addr", it
      sometimes points to a memory location in low memory that cannot be
      ioremapped.  For example on a P2020-based board with 512MB of RAM the
      following error occurs on bootup:
      
        <...>
        mpic: requesting IPIs ...
        __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
        Unable to handle kernel paging request for data at address 0x00000014
        Faulting instruction address: 0xc05df9b0
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2 P2020 RDB
        Modules linked in:
        <... eventual kernel panic>
      
      Adding logic to conditionally ioremap or access memory directly resolves
      the issue.
      
      Signed-off-by: default avatarPeter Tyser <ptyser@xes-inc.com>
      Signed-off-by: default avatarNate Case <ncase@xes-inc.com>
      Reported-by: default avatarDipen Dudhat <B09055@freescale.com>
      Tested-by: default avatarDipen Dudhat <B09055@freescale.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      d1d47ec6
    • Anton Vorontsov's avatar
      powerpc/85xx: Fix oops during MSI driver probe on MPC85xxMDS boards · fa644298
      Anton Vorontsov authored
      
      
      MPC85xx chips report the wrong value in feature reporting register,
      and that causes the following oops:
      
       Unable to handle kernel paging request for data at address 0x00000c00
       Faulting instruction address: 0xc0019294
       Oops: Kernel access of bad area, sig: 11 [#1]
       MPC8569 MDS
       Modules linked in:
       [...]
       NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
       LR [c0019124] mpic_set_irq_type+0x180/0x368
       Call Trace:
       [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
       [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
       [ef851db0] [c007b550] set_irq_type+0x40/0x7c
       [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
       [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
       [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
       [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
       [...]
      
      This is because mpic_alloc() assigns wrong values to
      mpic->isu_{size,shift,mask}, and things eventually break when
      _mpic_irq_read() is trying to use them.
      
      This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
      
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      fa644298
  10. Feb 12, 2010
  11. Feb 11, 2010
  12. Feb 10, 2010
  13. Feb 09, 2010
Loading