1. 24 6月, 2011 9 次提交
  2. 21 6月, 2011 1 次提交
  3. 17 6月, 2011 1 次提交
    • D
      ARM: 6963/1: Thumb-2: Relax relocation requirements for non-function symbols · 9a00318e
      Dave Martin 提交于
      The "Thumb bit" of a symbol is only really meaningful for function
      symbols (STT_FUNC).
      
      However, sometimes a branch is relocated against a non-function
      symbol; for example, PC-relative branches to anonymous assembler
      local symbols are typically fixed up against the start-of-section
      symbol, which is not a function symbol.  Some inline assembler
      generates references of this type, such as fixup code generated by
      macros in <asm/uaccess.h>.
      
      The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24
      interprets this case as an error, because the target symbol appears
      to be an ARM symbol; but this is really not the case, since the
      target symbol is just a base in these cases.  The addend defines
      the precise offset to the target location, but since the addend is
      encoded in a non-interworking Thumb branch instruction, there is no
      explicit Thumb bit in the addend.  Because these instructions never
      interwork, the implied Thumb bit in the addend is 1, and the
      destination is Thumb by definition.
      
      This patch removes the extraneous Thumb bit check for non-function
      symbols, enabling modules containing the affected relocation types
      to be loaded.  No modification to the actual relocation code is
      required, since this code does not take bit[0] of the
      location->destination offset into account in any case.
      
      Function symbols are always checked for interworking conflicts, as
      before.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9a00318e
  4. 10 6月, 2011 1 次提交
  5. 09 6月, 2011 2 次提交
  6. 06 6月, 2011 1 次提交
    • M
      ARM: 6952/1: fix lockdep warning of "unannotated irqs-off" · 9fc2552a
      Ming Lei 提交于
      This patch fixes the lockdep warning of "unannotated irqs-off"[1].
      
      After entering __irq_usr, arm core will disable interrupt automatically,
      but __irq_usr does not annotate the irq disable, so lockdep may complain
      the warning if it has chance to check this in irq handler.
      
      This patch adds trace_hardirqs_off in __irq_usr before entering irq_handler
      to handle the irq, also calls ret_to_user_from_irq to avoid calling
      disable_irq again.
      
      This is also a fix for irq off tracer.
      
      [1], lockdep warning log of "unannotated irqs-off"
      
      [   13.804687] ------------[ cut here ]------------
      [   13.809570] WARNING: at kernel/lockdep.c:3335 check_flags+0x78/0x1d0()
      [   13.816467] Modules linked in:
      [   13.819732] Backtrace:
      [   13.822357] [<c01cb42c>] (dump_backtrace+0x0/0x100) from [<c06abb14>] (dump_stack+0x20/0x24)
      [   13.831268]  r6:c07d8c2c r5:00000d07 r4:00000000 r3:00000000
      [   13.837280] [<c06abaf4>] (dump_stack+0x0/0x24) from [<c01ffc04>] (warn_slowpath_common+0x5c/0x74)
      [   13.846649] [<c01ffba8>] (warn_slowpath_common+0x0/0x74) from [<c01ffc48>] (warn_slowpath_null+0x2c/0x34)
      [   13.856781]  r8:00000000 r7:00000000 r6:c18b8194 r5:60000093 r4:ef182000
      [   13.863708] r3:00000009
      [   13.866485] [<c01ffc1c>] (warn_slowpath_null+0x0/0x34) from [<c0237d84>] (check_flags+0x78/0x1d0)
      [   13.875823] [<c0237d0c>] (check_flags+0x0/0x1d0) from [<c023afc8>] (lock_acquire+0x4c/0x150)
      [   13.884704] [<c023af7c>] (lock_acquire+0x0/0x150) from [<c06af638>] (_raw_spin_lock+0x4c/0x84)
      [   13.893798] [<c06af5ec>] (_raw_spin_lock+0x0/0x84) from [<c01f9a44>] (sched_ttwu_pending+0x58/0x8c)
      [   13.903320]  r6:ef92d040 r5:00000003 r4:c18b8180
      [   13.908233] [<c01f99ec>] (sched_ttwu_pending+0x0/0x8c) from [<c01f9a90>] (scheduler_ipi+0x18/0x1c)
      [   13.917663]  r6:ef183fb0 r5:00000003 r4:00000000 r3:00000001
      [   13.923645] [<c01f9a78>] (scheduler_ipi+0x0/0x1c) from [<c01bc458>] (do_IPI+0x9c/0xfc)
      [   13.932006] [<c01bc3bc>] (do_IPI+0x0/0xfc) from [<c06b0888>] (__irq_usr+0x48/0xe0)
      [   13.939971] Exception stack(0xef183fb0 to 0xef183ff8)
      [   13.945281] 3fa0:                                     ffffffc3 0001500c 00000001 0001500c
      [   13.953948] 3fc0: 00000050 400b45f0 400d9000 00000000 00000001 400d9600 6474e552 bea05b3c
      [   13.962585] 3fe0: 400d96c0 bea059c0 400b6574 400b65d8 20000010 ffffffff
      [   13.969573]  r6:00000403 r5:fa240100 r4:ffffffff r3:20000010
      [   13.975585] ---[ end trace efc4896ab0fb62cb ]---
      [   13.980468] possible reason: unannotated irqs-off.
      [   13.985534] irq event stamp: 1610
      [   13.989044] hardirqs last  enabled at (1610): [<c01c703c>] no_work_pending+0x8/0x2c
      [   13.997131] hardirqs last disabled at (1609): [<c01c7024>] ret_slow_syscall+0xc/0x1c
      [   14.005371] softirqs last  enabled at (0): [<c01fe5e4>] copy_process+0x2cc/0xa24
      [   14.013183] softirqs last disabled at (0): [<  (null)>]   (null)
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9fc2552a
  7. 29 5月, 2011 1 次提交
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  8. 26 5月, 2011 3 次提交
  9. 23 5月, 2011 3 次提交
    • R
      ARM: consolidate SMP cross call implementation · 0f7b332f
      Russell King 提交于
      Rather than having each platform class provide a mach/smp.h header for
      smp_cross_call(), arrange for them to register the function with the
      core ARM SMP code instead.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0f7b332f
    • G
      arm/dt: probe for platforms via the device tree · 93c02ab4
      Grant Likely 提交于
      If a dtb is passed to the kernel then the kernel needs to iterate
      through compiled-in mdescs looking for one that matches and move the
      dtb data to a safe location before it gets accidentally overwritten by
      the kernel.
      
      This patch creates a new function, setup_machine_fdt() which is
      analogous to the setup_machine_atags() created in the previous patch.
      It does all the early setup needed to use a device tree machine
      description.
      
      v5: - Print warning with neither dtb nor atags are passed to the kernel
          - Fix bug in setting of __machine_arch_type to the selected machine,
            not just the last machine in the list.
      Reported-by: NTixy <tixy@yxit.co.uk>
          - Copy command line directly into boot_command_line instead of cmd_line
      v4: - Dump some output when a matching machine_desc cannot be found
      v3: - Added processing of reserved list.
          - Backed out the v2 change that copied instead of reserved the
            dtb.  dtb is reserved again and the real problem was fixed by
            using alloc_bootmem_align() for early allocation of RAM for
            unflattening the tree.
          - Moved cmd_line and initrd changes to earlier patch to make series
            bisectable.
      v2: Changed to save the dtb by copying into an allocated buffer.
          - Since the dtb will very likely be passed in the first 16k of ram
            where the interrupt vectors live, memblock_reserve() is
            insufficient to protect the dtb data.
      
      [based on work originally written by Jeremy Kerr <jeremy.kerr@canonical.com>]
      Tested-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      93c02ab4
    • G
      arm/dt: consolidate atags setup into setup_machine_atags · 6291319d
      Grant Likely 提交于
      In preparation for adding device tree support, this patch consolidates
      all of the atag-specific setup into a single function.
      
      v5: - drop double printk("Machine; %s\n", ...); call.
          - leave copying boot_command_line in setup_arch() since it isn't
            atags specific.
      v4: - adapt to the removal of lookup_machine_type()
          - break out dump of machine_desc table into dump_machine_table()
            because the device tree probe code will use it.
          - Add for_each_machine_desc() macro
      Tested-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      6291319d
  10. 21 5月, 2011 1 次提交
  11. 15 5月, 2011 1 次提交
  12. 14 5月, 2011 1 次提交
  13. 12 5月, 2011 2 次提交
    • A
      ARM: 6892/1: handle ptrace requests to change PC during interrupted system calls · 2af68df0
      Arnd Bergmann 提交于
      GDB's interrupt.exp test cases currenly fail on ARM.  The problem is how do_signal
      handled restarting interrupted system calls:
      
      The entry.S assembler code determines that we come from a system call; and that
      information is passed as "syscall" parameter to do_signal.  That routine then
      calls get_signal_to_deliver [*] and if a signal is to be delivered, calls into
      handle_signal.  If a system call is to be restarted either after the signal
      handler returns, or if no handler is to be called in the first place, the PC
      is updated after the get_signal_to_deliver call, either in handle_signal (if
      we have a handler) or at the end of do_signal (otherwise).
      
      Now the problem is that during [*], the call to get_signal_to_deliver, a ptrace
      intercept may happen.  During this intercept, the debugger may change registers,
      including the PC.  This is done by GDB if it wants to execute an "inferior call",
      i.e. the execution of some code in the debugged program triggered by GDB.
      
      To this purpose, GDB will save all registers, allocate a stack frame, set up
      PC and arguments as appropriate for the call, and point the link register to
      a dummy breakpoint instruction.  Once the process is restarted, it will execute
      the call and then trap back to the debugger, at which point GDB will restore
      all registers and continue original execution.
      
      This generally works fine.  However, now consider what happens when GDB attempts
      to do exactly that while the process was interrupted during execution of a to-be-
      restarted system call:  do_signal is called with the syscall flag set; it calls
      get_signal_to_deliver, at which point the debugger takes over and changes the PC
      to point to a completely different place.  Now get_signal_to_deliver returns
      without a signal to deliver; but now do_signal decides it should be restarting
      a system call, and decrements the PC by 2 or 4 -- so it now points to 2 or 4
      bytes before the function GDB wants to call -- which leads to a subsequent crash.
      
      To fix this problem, two things need to be supported:
      - do_signal must be able to recognize that get_signal_to_deliver changed the PC
        to a different location, and skip the restart-syscall sequence
      - once the debugger has restored all registers at the end of the inferior call
        sequence, do_signal must recognize that *now* it needs to restart the pending
        system call, even though it was now entered from a breakpoint instead of an
        actual svc instruction
      
      This set of issues is solved on other platforms, usually by one of two
      mechanisms:
      
      - The status information "do_signal is handling a system call that may need
        restarting" is itself carried in some register that can be accessed via
        ptrace.  This is e.g. on Intel the "orig_eax" register; on Sparc the kernel
        defines a magic extra bit in the flags register for this purpose.
        This allows GDB to manage that state: reset it when doing an inferior call,
        and restore it after the call is finished.
      
      - On s390, do_signal transparently handles this problem without requiring
        GDB interaction, by performing system call restarting in the following
        way: first, adjust the PC as necessary for restarting the call.  Then,
        call get_signal_to_deliver; and finally just continue execution at the
        PC.  This way, if GDB does not change the PC, everything is as before.
        If GDB *does* change the PC, execution will simply continue there --
        and once GDB restores the PC it saved at that point, it will automatically
        point to the *restarted* system call.  (There is the minor twist how to
        handle system calls that do *not* need restarting -- do_signal will undo
        the PC change in this case, after get_signal_to_deliver has returned, and
        only if ptrace did not change the PC during that call.)
      
      Because there does not appear to be any obvious register to carry the
      syscall-restart information on ARM, we'd either have to introduce a new
      artificial ptrace register just for that purpose, or else handle the issue
      transparently like on s390.  The patch below implements the second option;
      using this patch makes the interrupt.exp test cases pass on ARM, with no
      regression in the GDB test suite otherwise.
      
      Cc: patches@linaro.org
      Signed-off-by: NUlrich Weigand <ulrich.weigand@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd.bergmann@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2af68df0
    • V
      ARM: 6893/1: Allow for kernel command line concatenation · 4394c124
      Victor Boivie 提交于
      This patch allows the provided CONFIG_CMDLINE to be concatenated
      with the one provided by the boot loader. This is useful to
      merge the static values defined in CONFIG_CMDLINE with the
      boot loader's (possibly) more dynamic values, such as startup
      reasons and more.
      Signed-off-by: NVictor Boivie <victor.boivie@sonyericsson.com>
      Reviewed-by: NBjorn Andersson <bjorn.andersson@sonyericsson.com>
      Signed-off-by: NOskar Andero <oskar.andero@sonyericsson.com>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4394c124
  14. 11 5月, 2011 2 次提交
  15. 29 4月, 2011 11 次提交