1. 16 Dec, 2010 3 commits
    • Andres Salomon's avatar
      x86, olpc: Speed up device tree creation during boot · b5318d30
      Andres Salomon authored
      Calling alloc_bootmem() for tiny chunks of memory over and over is really
      slow; on an XO-1, it caused the time between when the kernel started
      booting and when the display came alive (post-lxfb probe) to increase
      to 44s.  This patch optimizes the prom_early_alloc function by
      calling alloc_bootmem for 4k-sized blocks of memory, and handing out
      chunks of that to callers.  With this patch, the time between kernel load
      and display initialization decreased to 23s.  If there's a better way to
      do this early in the boot process, please let me know.
      
      (Note: increasing the chunk size to 16k didn't noticably affect boot time,
      and wasted 9k.)
      
      v4: clarify comment, requested by hpa
      v3: fix wasted memory buglet found by Milton Miller, and style fix.
      v2: reorder prom_early_alloc as suggested by Grant.
      Signed-off-by: default avatarAndres Salomon <dilinger@queued.net>
      LKML-Reference: <20101129153951.74202a84@queued.net>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      b5318d30
    • Andres Salomon's avatar
      x86, olpc: Add OLPC device-tree support · c10d1e26
      Andres Salomon authored
      Make use of PROC_DEVICETREE to export the tree, and sparc's PROMTREE code to
      call into OLPC's Open Firmware to build the tree.
      
      v5: fix buglet with root node check (introduced in v4)
      
      v4: address some minor style issues pointed out by Grant, and explicitly cast
          negative phandle checks to s32.
      
      v3: rename olpc_prom to olpc_dt
        - rework Kconfig entries
        - drop devtree build hook from proc, instead adding a call to x86's
          paging_init (similarly to how sparc64 does it)
        - switch allocation from using slab to alloc_bootmem.  this allows
          the DT to be built earlier during boot (during setup_arch); the
          downside is that there are some 1200 bootmem reservations that are
          done during boot.  Not ideal..
        - add a helper olpc_ofw_is_installed function to test for the
          existence and successful detection of OLPC's OFW.
      Signed-off-by: default avatarAndres Salomon <dilinger@queued.net>
      LKML-Reference: <20101116220952.26526a80@queued.net>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      c10d1e26
    • Andres Salomon's avatar
      x86, of: Define irq functions to allow drivers/of/* to build on x86 · 4722d194
      Andres Salomon authored
      - Define a stub irq_create_of_mapping for x86 as a stop-gap solution until
         drivers/of/irq is further along.
       - Define irq_dispose_mapping for x86 to appease of_i2c.c
      
      These are needed to allow stuff in drivers/of/ to build on x86.  This stuff
      will eventually get replaced; quoting Grant,
      
      "The long term plan is to have the drivers/of/ code handling the mapping
      intelligently like powerpc currently does."  But for now, just provide
      these functions.
      Signed-off-by: default avatarAndres Salomon <dilinger@queued.net>
      LKML-Reference: <20101111214526.5de7121b@queued.net>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      4722d194
  2. 07 Dec, 2010 3 commits
  3. 06 Dec, 2010 10 commits
  4. 04 Dec, 2010 8 commits
    • Guy Martin's avatar
      parisc: Fix GSC PS/2 driver name for keyboard and mouse · 7bfbeae9
      Guy Martin authored
      Fix kernel warnings caused by the driver name of GSC PS/2 containing '/'.
      
      The following warnings are observed on a K410 system :
      
      [   10.700000] name 'GSC PS/2 keyboard'
      [   10.732000] ------------[ cut here ]------------
      [   10.772000] WARNING: at fs/proc/generic.c:323
      [   10.828000] Modules linked in:
      [   10.916000]
      [   10.916000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   10.936000] PSW: 00000000000001000000000000001111 Not tainted
      [   10.992000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   11.060000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   11.124000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   11.184000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   11.248000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   11.308000] r20-23  00000000 00000028 104cd858 00000000
      [   11.372000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   11.436000] r28-31  0000002b 00000078 4fc40800 0000000d
      [   11.496000] sr00-03  00000000 00000000 00000000 00000000
      [   11.560000] sr04-07  00000000 00000000 00000000 00000000
      [   11.624000]
      [   11.688000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   11.704000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   11.772000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   11.836000]  ORIG_R28: 4fc40940
      [   11.904000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   11.940000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   11.996000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   12.052000] Backtrace:
      [   12.108000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   12.136000]
      [   12.188000] ---[ end trace 91bf6ece17e322dd ]---
      [   12.208000] serio: GSC PS/2 keyboard port at 0x0001c000 irq 19 @ 10:12:7
      [   12.264000] name 'GSC PS/2 mouse'
      [   12.344000] ------------[ cut here ]------------
      [   12.384000] WARNING: at fs/proc/generic.c:323
      [   12.436000] Modules linked in:
      [   12.524000]
      [   12.528000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   12.544000] PSW: 00000000000001000000000000001111 Tainted: G        W
      [   12.600000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   12.680000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   12.740000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   12.804000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   12.868000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   12.928000] r20-23  00000000 00000025 104cd858 00000000
      [   12.992000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   13.056000] r28-31  00000028 00000078 4fc40800 0000000d
      [   13.116000] sr00-03  00000000 00000000 00000000 00000000
      [   13.180000] sr04-07  00000000 00000000 00000000 00000000
      [   13.244000]
      [   13.308000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   13.324000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   13.392000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   13.456000]  ORIG_R28: 4fc40940
      [   13.524000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   13.560000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   13.616000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   13.672000] Backtrace:
      [   13.728000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   13.756000]
      [   13.808000] ---[ end trace 91bf6ece17e322de ]---
      [   13.828000] serio: GSC PS/2 mouse port at 0x00020100 irq 19 @ 10:12:8
      Signed-off-by: default avatarGuy Martin <gmsoft@tuxicoman.be>
      Acked-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      7bfbeae9
    • Guy Martin's avatar
      parisc: KittyHawk LCD fix · 79a04296
      Guy Martin authored
      K class aka KittyHawk don't have LED support on their LCD. Installing
      HP-UX confirmed this. The current led_wq fills the LCD with black
      characters each time it runs.
      
      The patch prevents the led_wq workqueue and its proc entry to be
      created for KittyHawk machines.
      
      It also increase min_cmd_delay as currently, one character out of two
      is lost when a string is sent to the LCD.
      Signed-off-by: default avatarGuy Martin <gmsoft@tuxicoman.be>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.c>
      79a04296
    • James Bottomley's avatar
      parisc: convert the rest of the irq handlers to simple/percpu · 51890613
      James Bottomley authored
      The generic conversion eliminates the spurious no_ack and no_end
      routines, converts all the cascaded handlers to handle_simple_irq() and
      makes iosapic use a modified handle_percpu_irq() to become the same as
      the CPU irq's.  This isn't an essential change, but it eliminates the
      mask/unmask overhead of handle_level_irq().
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Tested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      51890613
    • James Bottomley's avatar
      parisc: fix dino/gsc interrupts · d16cd297
      James Bottomley authored
      The essential problem we're currently having is that dino (and gsc) is a
      cascaded CPU interrupt.  Under the old __do_IRQ() handler, our CPU
      interrupts basically did an ack followed by an end.  In the new scheme,
      we replaced them with level handlers which do a mask, an ack and then an
      unmask (but no end).  Instead, with the renaming of end to eoi, we
      actually want to call the percpu flow handlers, because they actually
      have all the characteristics we want.
      
      This patch does the conversion and gets my C360 booting again.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      d16cd297
    • Rabin Vincent's avatar
      ARM: 6523/1: iop: ensure sched_clock() is notrace · a5542a0f
      Rabin Vincent authored
      Include sched.h to ensure sched_clock() has the notrace
      annotation, and mark any functions it calls as notrace
      too.
      Include sched.h to ensure sched_clock() has the notrace
      annotation, and mark any functions it calls as notrace
      too.
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a5542a0f
    • Marcelo Roberto Jimenez's avatar
      ARM: 6456/1: Fix for building DEBUG with sa11xx_base.c as a module. · b9f515e3
      Marcelo Roberto Jimenez authored
      This patch fixes a compilation issue when compiling PCMCIA SA1100
      support as a module with PCMCIA_DEBUG enabled. The symbol
      soc_pcmcia_debug was not beeing exported.
      ARM: pcmcia: Fix for building DEBUG with sa11xx_base.c as a module.
      
      This patch fixes a compilation issue when compiling PCMCIA SA1100
      support as a module with PCMCIA_DEBUG enabled. The symbol
      soc_pcmcia_debug was not beeing exported.
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarMarcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b9f515e3
    • Dave Martin's avatar
      ARM: 6519/1: kuser: Fix incorrect cmpxchg syscall in kuser helpers · 55afd264
      Dave Martin authored
      The existing code invokes the syscall with rubbish in r7,
      due to what looks like an incorrect literal load idiom.
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarDave Martin <dave.martin@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      55afd264
    • Tero Roponen's avatar
      slub: Fix a crash during slabinfo -v · 37d57443
      Tero Roponen authored
      Commit f7cb1933 ("SLUB: Pass active
      and inactive redzone flags instead of boolean to debug functions")
      missed two instances of check_object(). This caused a lot of warnings
      during 'slabinfo -v' finally leading to a crash:
      
        BUG ext4_xattr: Freepointer corrupt
        ...
        BUG buffer_head: Freepointer corrupt
        ...
        BUG ext4_alloc_context: Freepointer corrupt
        ...
        ...
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        IP: [<ffffffff810a291f>] file_sb_list_del+0x1c/0x35
        PGD 79d78067 PUD 79e67067 PMD 0
        Oops: 0002 [#1] SMP
        last sysfs file: /sys/kernel/slab/:t-0000192/validate
      
      This patch fixes the problem by converting the two missed instances.
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarTero Roponen <tero.roponen@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      37d57443
  5. 03 Dec, 2010 13 commits
  6. 02 Dec, 2010 3 commits
    • Jeremy Fitzhardinge's avatar
      xen: prevent crashes with non-HIGHMEM 32-bit kernels with largeish memory · 2a4c92fa
      Jeremy Fitzhardinge authored
      If this is a non-HIGHMEM 32-bit kernel, then the page structures only go
      up to the limit of addressable memory, even if more memory is physically
      present.  Don't try to add that extra memory to the balloon.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      2a4c92fa
    • Nelson Elhage's avatar
      do_exit(): make sure that we run with get_fs() == USER_DS · 33dd94ae
      Nelson Elhage authored
      If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
      otherwise reset before do_exit().  do_exit may later (via mm_release in
      fork.c) do a put_user to a user-controlled address, potentially allowing
      a user to leverage an oops into a controlled write into kernel memory.
      
      This is only triggerable in the presence of another bug, but this
      potentially turns a lot of DoS bugs into privilege escalations, so it's
      worth fixing.  I have proof-of-concept code which uses this bug along
      with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
      I've tested that this is not theoretical.
      
      A more logical place to put this fix might be when we know an oops has
      occurred, before we call do_exit(), but that would involve changing
      every architecture, in multiple places.
      
      Let's just stick it in do_exit instead.
      
      [akpm@linux-foundation.org: update code comment]
      Signed-off-by: default avatarNelson Elhage <nelhage@ksplice.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      33dd94ae
    • KOSAKI Motohiro's avatar
      ksm: annotate ksm_thread_mutex is no deadlock source · a0b0f58c
      KOSAKI Motohiro authored
      commit 62b61f61 ("ksm: memory hotremove migration only") caused the
      following new lockdep warning.
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        -------------------------------------------------------
        bash/1621 is trying to acquire lock:
         ((memory_chain).rwsem){.+.+.+}, at: [<ffffffff81079339>]
        __blocking_notifier_call_chain+0x69/0xc0
      
        but task is already holding lock:
         (ksm_thread_mutex){+.+.+.}, at: [<ffffffff8113a3aa>]
        ksm_memory_callback+0x3a/0xc0
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (ksm_thread_mutex){+.+.+.}:
             [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
             [<ffffffff81505d74>] __mutex_lock_common+0x44/0x3f0
             [<ffffffff81506228>] mutex_lock_nested+0x48/0x60
             [<ffffffff8113a3aa>] ksm_memory_callback+0x3a/0xc0
             [<ffffffff8150c21c>] notifier_call_chain+0x8c/0xe0
             [<ffffffff8107934e>] __blocking_notifier_call_chain+0x7e/0xc0
             [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff813afbfb>] memory_notify+0x1b/0x20
             [<ffffffff81141b7c>] remove_memory+0x1cc/0x5f0
             [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
             [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
             [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
             [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
             [<ffffffff8114f398>] vfs_write+0xc8/0x190
             [<ffffffff8114fc14>] sys_write+0x54/0x90
             [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b
      
        -> #0 ((memory_chain).rwsem){.+.+.+}:
             [<ffffffff8108b5ba>] __lock_acquire+0x155a/0x1600
             [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
             [<ffffffff81506601>] down_read+0x51/0xa0
             [<ffffffff81079339>] __blocking_notifier_call_chain+0x69/0xc0
             [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff813afbfb>] memory_notify+0x1b/0x20
             [<ffffffff81141f1e>] remove_memory+0x56e/0x5f0
             [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
             [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
             [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
             [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
             [<ffffffff8114f398>] vfs_write+0xc8/0x190
             [<ffffffff8114fc14>] sys_write+0x54/0x90
             [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b
      
      But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
      have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.
      
      Thus, This patch annotate ksm_thread_mutex is not deadlock source.
      
      [akpm@linux-foundation.org: update comment, from Hugh]
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a0b0f58c