1. 25 Mar, 2007 4 commits
  2. 24 Mar, 2007 17 commits
  3. 20 Mar, 2007 8 commits
  4. 16 Mar, 2007 1 commit
  5. 14 Mar, 2007 1 commit
  6. 11 Mar, 2007 7 commits
  7. 09 Mar, 2007 2 commits
    • David S. Miller's avatar
      SPARC64: Fix memory corruption in pci_4u_free_consistent() · ec333318
      David S. Miller authored
      The second argument to free_npages() was being incorrectly
      calculated, which would thus access far past the end of the
      arena->map[] bitmap.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      ec333318
    • Hugh Dickins's avatar
      make ppc64 current preempt-safe · 00966235
      Hugh Dickins authored
      Repeated -j20 kernel builds on a G5 Quad running an SMP PREEMPT kernel
      would often collapse within a day, some exec failing with "Bad address".
      In each case examined, load_elf_binary was doing a kernel_read, but
      generic_file_aio_read's access_ok saw current->thread.fs.seg as USER_DS
      instead of KERNEL_DS.
      
      objdump of filemap.o shows gcc 4.1.0 emitting "mr r5,r13 ... ld r9,416(r5)"
      here for get_paca()->__current, instead of the expected and much more usual
      "ld r9,416(r13)"; I've seen other gcc4s do the same, but perhaps not gcc3s.
      
      So, if the task is preempted and rescheduled on a different cpu in between
      the mr and the ld, r5 will be looking at a different paca_struct from the
      one it's now on, pick up the wrong __current, and perhaps the wrong seg.
      Presumably much worse could happen elsewhere, though that split is rare.
      
      Other architectures appear to be safe (x86_64's read_pda is more limiting
      than get_paca), but ppc64 needs to force "current" into one instruction.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      00966235