1. 08 4月, 2013 9 次提交
  2. 07 4月, 2013 1 次提交
  3. 06 4月, 2013 1 次提交
    • J
      x86: Fix rebuild with EFI_STUB enabled · 91870824
      Jan Beulich 提交于
      eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence
      their .cmd files don't get included by the build machinery, leading to
      the files always getting rebuilt.
      
      Rather than adding the two files individually, take the opportunity and
      add $(VMLINUX_OBJS) to "targets" instead, thus allowing the assignment
      at the top of the file to be shrunk quite a bit.
      
      At the same time, remove a pointless flags override line - the variable
      assigned to was misspelled anyway, and the options added are
      meaningless for assembly sources.
      
      [ hpa: the patch is not minimal, but I am taking it for -urgent anyway
        since the excess impact of the patch seems to be small enough. ]
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Link: http://lkml.kernel.org/r/515C5D2502000078000CA6AD@nat28.tlf.novell.com
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      91870824
  4. 05 4月, 2013 6 次提交
  5. 03 4月, 2013 7 次提交
    • P
      ARM: 7690/1: mm: fix CONFIG_LPAE typos · 4e1db26a
      Paul Bolle 提交于
      CONFIG_LPAE doesn't exist: the correct option is CONFIG_ARM_LPAE, so fix
      up the two typos under arch/arm/.
      
      The fix to head.S is slightly scary, but this is just for setting up
      an early io-mapping for the serial port when running on a big-endian,
      LPAE system. Since these systems don't exist in the wild (at least, I
      have no access to one outside of kvmtool, which doesn't provide a serial
      port suitable for earlyprintk), then we can revisit the code later if it
      causes any problems.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4e1db26a
    • R
      ARM: 7689/1: add unwind annotations to ftrace asm · b21e023b
      Rabin Vincent 提交于
      Add unwind annotations to the ftrace assembly code so that the function
      tracer's stacktracing options (func_stack_trace, etc.) work when
      CONFIG_ARM_UNWIND is enabled.
      Signed-off-by: NRabin Vincent <rabin@rab.in>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b21e023b
    • W
      ARM: 7685/1: delay: use private ticks_per_jiffy field for timer-based delay ops · 6f3d90e5
      Will Deacon 提交于
      Commit 70264367 ("ARM: 7653/2: do not scale loops_per_jiffy when
      using a constant delay clock") fixed a problem with our timer-based
      delay loop, where loops_per_jiffy is scaled by cpufreq yet used directly
      by the timer delay ops.
      
      This patch fixes the problem in a more elegant way by keeping a private
      ticks_per_jiffy field in the delay ops, independent of loops_per_jiffy
      and therefore not subject to scaling. The loop-based delay continues to
      use loops_per_jiffy directly, as it should.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6f3d90e5
    • C
      ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations) · 93dc6887
      Catalin Marinas 提交于
      On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
      all use of the old entries. This patch implements the erratum workaround
      which consists of:
      
      1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
      2. Send IPI to the CPUs that are running the same mm (and ASID) as the
         one being invalidated (or all the online CPUs for global pages).
      3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
         return code already).
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      93dc6887
    • R
      ARM: 7682/1: cache-l2x0: fix masking of RTL revision numbering and set_debug init · 6e7aceeb
      Rob Herring 提交于
      Commit b8db6b88 (ARM: 7547/4: cache-l2x0: add support for Aurora L2 cache
      ctrl) moved the masking of the part ID which caused the RTL version to be
      lost. Commit 6248d060 (ARM: 7545/1: cache-l2x0: make outer_cache_fns a
      field of l2x0_of_data) changed how .set_debug is initialized. Both commits
      break commit 74ddcdb8 (ARM: 7608/1: l2x0: Only set .set_debug
      on PL310 r3p0 and earlier) which uses the RTL version to conditionally set
      .set_debug function pointer. Commit b8db6b88 also caused the printed cache
      ID to be missing the version information.
      
      Fix this by reverting how the part number is masked so the RTL version
      info is maintained. The cache-id-part DT property does not set the RTL
      bits so masking them should have no effect. Also, re-arrange the order
      of the function pointer init so the .set_debug function can be overridden.
      Reported-by: NPaolo Pisati <paolo.pisati@canonical.com>
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Yehuda Yitschak <yehuday@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6e7aceeb
    • R
      ARM: iWMMXt: always enable iWMMXt support with PJ4 CPUs · 698613b6
      Russell King 提交于
      Jason Cooper reports these build errors:
      arch/arm/kernel/built-in.o: In function `iwmmxt_do':
      /.../arch/arm/kernel/pj4-cp0.c:36: undefined reference to `iwmmxt_task_release'
      /.../arch/arm/kernel/pj4-cp0.c:40: undefined reference to `iwmmxt_task_switch'
      make: *** [vmlinux] Error 1
      
      This is caused because the PJ4 code explicitly references the iWMMXt
      code, but doesn't require it to be built.  Fix this by ensuring that
      iWMMXt is always enabled with PJ4.
      Reported-by: NJason Cooper <jason@lakedaemon.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      698613b6
    • P
      x86: remove the x32 syscall bitmask from syscall_get_nr() · 8b4b9f27
      Paul Moore 提交于
      Commit fca460f9 simplified the x32
      implementation by creating a syscall bitmask, equal to 0x40000000, that
      could be applied to x32 syscalls such that the masked syscall number
      would be the same as a x86_64 syscall.  While that patch was a nice
      way to simplify the code, it went a bit too far by adding the mask to
      syscall_get_nr(); returning the masked syscall numbers can cause
      confusion with callers that expect syscall numbers matching the x32
      ABI, e.g. unmasked syscall numbers.
      
      This patch fixes this by simply removing the mask from syscall_get_nr()
      while preserving the other changes from the original commit.  While
      there are several syscall_get_nr() callers in the kernel, most simply
      check that the syscall number is greater than zero, in this case this
      patch will have no effect.  Of those remaining callers, they appear
      to be few, seccomp and ftrace, and from my testing of seccomp without
      this patch the original commit definitely breaks things; the seccomp
      filter does not correctly filter the syscalls due to the difference in
      syscall numbers in the BPF filter and the value from syscall_get_nr().
      Applying this patch restores the seccomp BPF filter functionality on
      x32.
      
      I've tested this patch with the seccomp BPF filters as well as ftrace
      and everything looks reasonable to me; needless to say general usage
      seemed fine as well.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Link: http://lkml.kernel.org/r/20130215172143.12549.10292.stgit@localhost
      Cc: <stable@vger.kernel.org>
      Cc: Will Drewry <wad@chromium.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      8b4b9f27
  6. 02 4月, 2013 2 次提交
    • H
      s390/mm: provide emtpy check_pgt_cache() function · 765a0cac
      Heiko Carstens 提交于
      All architectures need to provide a check_pgt_cache() function. The s390 one
      got lost somewhere.
      So reintroduce it to prevent future compile errors e.g. if Thomas Gleixner's
      idle loop rework patches get merged.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      765a0cac
    • H
      s390/uaccess: fix page table walk · ea81531d
      Heiko Carstens 提交于
      When translating user space addresses to kernel addresses the follow_table()
      function had two bugs:
      
      - PROT_NONE mappings could be read accessed via the kernel mapping. That is
        e.g. putting a filename into a user page, then protecting the page with
        PROT_NONE and afterwards issuing the "open" syscall with a pointer to
        the filename would incorrectly succeed.
      
      - when walking the page tables it used the pgd/pud/pmd/pte primitives which
        with dynamic page tables give no indication which real level of page tables
        is being walked (region2, region3, segment or page table). So in case of an
        exception the translation exception code passed to __handle_fault() is not
        necessarily correct.
        This is not really an issue since __handle_fault() doesn't evaluate the code.
        Only in case of e.g. a SIGBUS this code gets passed to user space. If user
        space can do something sane with the value is a different question though.
      
      To fix these issues don't use any Linux primitives. Only walk the page tables
      like the hardware would do it, however we leave quite some checks away since
      we know that we only have full size page tables and each index is within bounds.
      
      In theory this should fix all issues...
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      ea81531d
  7. 31 3月, 2013 1 次提交
  8. 30 3月, 2013 2 次提交
  9. 29 3月, 2013 6 次提交
  10. 28 3月, 2013 4 次提交
  11. 27 3月, 2013 1 次提交
    • R
      ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized · ff931c82
      Rajendra Nayak 提交于
      clk inits on OMAP happen quite early, even before slab is available.
      The dependency comes from the fact that the timer init code starts to
      use clocks and hwmod and we need clocks to be initialized by then.
      
      There are various problems doing clk inits this early, one is,
      not being able to do dynamic clk registrations and hence the
      dependency on clk-private.h. The other is, inability to debug
      early kernel crashes without enabling DEBUG_LL and earlyprintk.
      
      Doing early clk init also exposed another instance of a kernel
      panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled.
      
      [    0.000000] Kernel BUG at c01174f8 [verbose debug info unavailable]
      [    0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Not tainted  (3.9.0-rc1-12179-g72d48f9 #6)
      [    0.000000] PC is at __kmalloc+0x1d4/0x248
      [    0.000000] LR is at __clk_init+0x2e0/0x364
      [    0.000000] pc : [<c01174f8>]    lr : [<c0441f54>]    psr: 600001d3
      [    0.000000] sp : c076ff28  ip : c065cefc  fp : c0441f54
      [    0.000000] r10: 0000001c  r9 : 000080d0  r8 : c076ffd4
      [    0.000000] r7 : c074b578  r6 : c0794d88  r5 : 00000040  r4 : 00000000
      [    0.000000] r3 : 00000000  r2 : c07cac70  r1 : 000080d0  r0 : 0000001c
      [    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    0.000000] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
      [    0.000000] Process swapper (pid: 0, stack limit = 0xc076e240)
      [    0.000000] Stack: (0xc076ff28 to 0xc0770000)
      [    0.000000] ff20:                   22222222 c0794ec8 c06546e8 00000000 00000040 c0794d88
      [    0.000000] ff40: c074b578 c076ffd4 c07951c8 c076e000 00000000 c0441f54 c074b578 c076ffd4
      [    0.000000] ff60: c0793828 00000040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac
      [    0.000000] ff80: 2f800000 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 00000000 00000000
      [    0.000000] ffa0: 00000000 00000000 00000000 00000001 c074cd6c c077b1ec 8000406a c0715724
      [    0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c074c968 10c53c7d c0776974
      [    0.000000] ffe0: c074cd6c c077b1ec 8000406a 411fc092 00000000 80008074 00000000 00000000
      [    0.000000] [<c01174f8>] (__kmalloc+0x1d4/0x248) from [<c0441f54>] (__clk_init+0x2e0/0x364)
      [    0.000000] [<c0441f54>] (__clk_init+0x2e0/0x364) from [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140)
      [    0.000000] [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140) from [<c0719780>] (setup_arch+0x15c/0x284)
      [    0.000000] [<c0719780>] (setup_arch+0x15c/0x284) from [<c0715724>] (start_kernel+0x7c/0x334)
      [    0.000000] [<c0715724>] (start_kernel+0x7c/0x334) from [<80008074>] (0x80008074)
      [    0.000000] Code: e5883004 e1a00006 e28dd00c e8bd8ff0 (e7f001f2)
      [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
      [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
      
      It was a know issue, that slab allocations would fail when common
      clock core tries to cache parent pointers for mux clocks on OMAP,
      and hence a patch 'clk: Allow late cache allocation for clk->parents,
      commit 7975059d' was added to work this problem around.
      A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely
      overlooked causing this regression.
      
      More details on the issue reported can be found here,
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html
      
      With all these issues around clk inits happening way too early, it
      makes sense to at least move them to a point where dynamic memory
      allocations are possible. So move them to a point just before the
      timer code starts using clocks and hwmod.
      
      This should at least pave way for clk inits on OMAP moving to dynamic
      clock registrations instead of using the static macros defined in
      clk-private.h.
      
      The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled
      was reported by Piotr Haber and Tony Lindgren and this patch
      fixes the reported issue as well.
      Reported-by: NPiotr Haber <phaber@broadcom.com>
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NMike Turquette <mturquette@linaro.org>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Cc: stable@vger.kernel.org  # v3.8
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ff931c82