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>
    • 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>
    • 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:
      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
      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>
  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>
    • 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>
  7. 06 Sep, 2008 2 commits