1. 26 Sep, 2008 7 commits
  2. 25 Sep, 2008 1 commit
  3. 23 Sep, 2008 22 commits
  4. 09 Sep, 2008 3 commits
    • Prarit Bhargava's avatar
      x86: fix memmap=exactmap boot argument · d6be118a
      Prarit Bhargava authored
      
      
      When using kdump modifying the e820 map is yielding strange results.
      
      For example starting with
      
       BIOS-provided physical RAM map:
       BIOS-e820: 0000000000000100 - 0000000000093400 (usable)
       BIOS-e820: 0000000000093400 - 00000000000a0000 (reserved)
       BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
       BIOS-e820: 000000003fee0000 - 000000003fef3000 (ACPI data)
       BIOS-e820: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
       BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
      
      and booting with args
      
      memmap=exactmap memmap=640K@0K memmap=5228K@16384K memmap=125188K@22252K memmap=76K#1047424K memmap=564K#1047500K
      
      resulted in:
      
       user-defined physical RAM map:
       user: 0000000000000000 - 0000000000093400 (usable)
       user: 0000000000093400 - 00000000000a0000 (reserved)
       user: 0000000000100000 - 000000003fee0000 (usable)
       user: 000000003fee0000 - 000000003fef3000 (ACPI data)
       user: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
       user: 000000003ff80000 - 0000000040000000 (reserved)
       user: 00000000e0000000 - 00000000f0000000 (reserved)
       user: 00000000fec00000 - 00000000fec10000 (reserved)
       user: 00000000fee00000 - 00000000fee01000 (reserved)
       user: 00000000ff000000 - 0000000100000000 (reserved)
      
      But should have resulted in:
      
       user-defined physical RAM map:
       user: 0000000000000000 - 00000000000a0000 (usable)
       user: 0000000001000000 - 000000000151b000 (usable)
       user: 00000000015bb000 - 0000000008ffc000 (usable)
       user: 000000003fee0000 - 000000003ff80000 (ACPI data)
      
      This is happening because of an improper usage of strcmp() in the
      e820 parsing code.  The strcmp() always returns !0 and never resets the
      value for e820.nr_map and returns an incorrect user-defined map.
      
      This patch fixes the problem.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d6be118a
    • James Bottomley's avatar
      lib: Correct printk %pF to work on all architectures · deac93df
      James Bottomley authored
      It was introduced by "vsprintf: add support for '%pS' and '%pF' pointer
      formats" in commit 0fe1ef24
      
      .  However,
      the current way its coded doesn't work on parisc64.  For two reasons: 1)
      parisc isn't in the #ifdef and 2) parisc has a different format for
      function descriptors
      
      Make dereference_function_descriptor() more accommodating by allowing
      architecture overrides.  I put the three overrides (for parisc64, ppc64
      and ia64) in arch/kernel/module.c because that's where the kernel
      internal linker which knows how to deal with function descriptors sits.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      deac93df
    • Jarod Wilson's avatar
      [S390] CVE-2008-1514: prevent ptrace padding area read/write in 31-bit mode · 3d6e48f4
      Jarod Wilson authored
      When running a 31-bit ptrace, on either an s390 or s390x kernel,
      reads and writes into a padding area in struct user_regs_struct32
      will result in a kernel panic.
      
      This is also known as CVE-2008-1514.
      
      Test case available here:
      http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/user-area-padding.c?cvsroot=systemtap
      
      
      
      Steps to reproduce:
      1) wget the above
      2) gcc -o user-area-padding-31bit user-area-padding.c -Wall -ggdb2 -D_GNU_SOURCE -m31
      3) ./user-area-padding-31bit
      <panic>
      
      Test status
      -----------
      Without patch, both s390 and s390x kernels panic. With patch, the test case,
      as well as the gdb testsuite, pass without incident, padding area reads
      returning zero, writes ignored.
      
      Nb: original version returned -EINVAL on write attempts, which broke the
      gdb test and made the test case slightly unhappy, Jan Kratochvil suggested
      the change to return 0 on write attempts.
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Tested-by: default avatarJan Kratochvil <jan.kratochvil@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      3d6e48f4
  5. 08 Sep, 2008 3 commits
  6. 07 Sep, 2008 2 commits
    • Hugh Dickins's avatar
      powerpc: Fix rare boot build breakage · 4ff23fa9
      Hugh Dickins authored
      
      
      A make -j20 powerpc kernel build broke a couple of months ago saying:
      In file included from arch/powerpc/boot/gunzip_util.h:13,
                       from arch/powerpc/boot/prpmc2800.c:21:
      arch/powerpc/boot/zlib.h:85: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘*’ token
      arch/powerpc/boot/zlib.h:630: warning: type defaults to ‘int’ in declaration of ‘Byte’
      arch/powerpc/boot/zlib.h:630: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
      
      It happened again yesterday: too rare for me to confirm the fix, but
      it looks like the list of dependants on gunzip_util.h was incomplete.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      4ff23fa9
    • Andre Detsch's avatar
      powerpc/spufs: Fix possible scheduling of a context to multiple SPEs · b2e601d1
      Andre Detsch authored
      
      
      We currently have a race when scheduling a context to a SPE -
      after we have found a runnable context in spusched_tick, the same
      context may have been scheduled by spu_activate().
      
      This may result in a panic if we try to unschedule a context that has
      been freed in the meantime.
      
      This change exits spu_schedule() if the context has already been
      scheduled, so we don't end up scheduling it twice.
      Signed-off-by: default avatarAndre Detsch <adetsch@br.ibm.com>
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      b2e601d1
  7. 06 Sep, 2008 2 commits