1. 28 1月, 2011 4 次提交
  2. 26 1月, 2011 6 次提交
  3. 25 1月, 2011 4 次提交
  4. 23 1月, 2011 4 次提交
    • M
      x86: Fix jump label with RO/NX module protection crash · 89696913
      matthieu castet 提交于
      If we use jump table in module init, there are marked
      as removed in __jump_table section after init is done.
      
      But we already applied ro permissions on the module, so
      we can't modify a read only section (crash in
      remove_jump_label_module_init).
      
      Make the __jump_table section rw.
      Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
      Cc: Xiaotian Feng <xtfeng@gmail.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Siarhei Liakh <sliakh.lkml@gmail.com>
      Cc: Xuxian Jiang <jiang@cs.ncsu.edu>
      Cc: James Morris <jmorris@namei.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Kees Cook <kees.cook@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4D3C3F20.7030203@free.fr>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89696913
    • G
      m68k/amiga: Fix "debug=mem" · 5df1abdb
      Geert Uytterhoeven 提交于
      `debug=mem' on Amiga has been broken for a while.
      early_param() processing is done very/too early, i.e. before
      amiga_identify() / amiga_chip_init(), causing amiga_savekmsg_setup() not
      to find any Chip RAM.
      
      As we don't plan to free this memory anyway, just steal it from the initial
      Chip RAM memory block instead.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      5df1abdb
    • G
      m68k/atari: Rename "scc" to "atari_scc" · de339e4b
      Geert Uytterhoeven 提交于
      It's a way too generic name for a global #define and conflicts with a variable
      with the same name, causing build errors like:
      
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c: In function ‘_si_clkctl_cc’:
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected identifier or ‘(’ before ‘volatile’
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected ‘)’ before ‘(’ token
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1421: error: incompatible types in assignment
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1422: error: invalid operands to binary &
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1423: error: invalid operands to binary &
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1424: error: invalid operands to binary |
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: incompatible type for argument 4 of ‘bcmsdh_reg_write’
      | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1428: error: invalid operands to binary &
      | make[8]: *** [drivers/staging/brcm80211/brcmfmac/../util/siutils.o] Error 1
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      de339e4b
    • G
      m68k: Uninline strchr() · f9b07897
      Geert Uytterhoeven 提交于
      Some versions of gcc replace calls to strstr() with single-character
      "needle" string parameters by calls to strchr() behind our back.
      
      If strchr() is defined as an inline function, this causes linking errors
      like
      
      	ERROR: "strchr" [drivers/target/target_core_mod.ko] undefined!
      
      As m68k is the only architecture that has an inline strchr() and this
      inline version is not an optimized asm version, uninline strchr() and use
      the standard out-of-line C version in lib/string.c instead.
      
      This also decreases the defconfig/allmodconfig kernel image sizes by a few
      hundred bytes.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      f9b07897
  5. 22 1月, 2011 2 次提交
    • B
      x86, hotplug: Fix powersavings with offlined cores on AMD · 93789b32
      Borislav Petkov 提交于
      ea530692 made a CPU use monitor/mwait
      when offline. This is not the optimal choice for AMD wrt to powersavings
      and we'd prefer our cores to halt (i.e. enter C1) instead. For this, the
      same selection whether to use monitor/mwait has to be used as when we
      select the idle routine for the machine.
      
      With this patch, offlining cores 1-5 on a X6 machine allows core0 to
      boost again.
      
      [ hpa: putting this in urgent since it is a (power) regression fix ]
      Reported-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: stable@kernel.org # 37.x
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.hl>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <1295534572-10730-1-git-send-email-bp@amd64.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      93789b32
    • S
      xen: p2m: correctly initialize partial p2m leaf · 8e1b4cf2
      Stefan Bader 提交于
      After changing the p2m mapping to a tree by
      
        commit 58e05027
          xen: convert p2m to a 3 level tree
      
      and trying to boot a DomU with 615MB of memory, the following crash was
      observed in the dump:
      
      kernel direct mapping tables up to 26f00000 @ 1ec4000-1fff000
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<c0107397>] xen_set_pte+0x27/0x60
      *pdpt = 0000000000000000 *pde = 0000000000000000
      
      Adding further debug statements showed that when trying to set up
      pfn=0x26700 the returned mapping was invalid.
      
      pfn=0x266ff calling set_pte(0xc1fe77f8, 0x6b3003)
      pfn=0x26700 calling set_pte(0xc1fe7800, 0x3)
      
      Although the last_pfn obtained from the startup info is 0x26700, which
      should in turn not be hit, the additional 8MB which are added as extra
      memory normally seem to be ok. This lead to looking into the initial
      p2m tree construction, which uses the smaller value and assuming that
      there is other code handling the extra memory.
      
      When the p2m tree is set up, the leaves are directly pointed to the
      array which the domain builder set up. But if the mapping is not on a
      boundary that fits into one p2m page, this will result in the last leaf
      being only partially valid. And as the invalid entries are not
      initialized in that case, things go badly wrong.
      
      I am trying to fix that by checking whether the current leaf is a
      complete map and if not, allocate a completely new page and copy only
      the valid pointers there. This may not be the most efficient or elegant
      solution, but at least it seems to allow me booting DomUs with memory
      assignments all over the range.
      
      BugLink: http://bugs.launchpad.net/bugs/686692
      [v2: Redid a bit of commit wording and fixed a compile warning]
      Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      8e1b4cf2
  6. 21 1月, 2011 20 次提交