1. 22 10月, 2008 1 次提交
  2. 16 10月, 2008 1 次提交
    • Y
      x86: make 32bit support per_cpu vector · 497c9a19
      Yinghai Lu 提交于
      so we can merge io_apic_32.c and io_apic_64.c
      
      v2: Use cpu_online_map as target cpus for bigsmp, just like 64-bit is doing.
      
      Also remove some unused TARGET_CPUS macro.
      
      v3: need to check if desc is null in smp_irq_move_cleanup
      
      also migration needs to reset vector too, so copy __target_IO_APIC_irq
      from 64bit.
      
      (the duplication will go away once the two files are unified.)
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      497c9a19
  3. 14 10月, 2008 1 次提交
    • S
      ftrace: x86 mcount stub · 0a37605c
      Steven Rostedt 提交于
      x86 now sets up the mcount locations through the build and no longer
      needs to record the ip when the function is executed. This patch changes
      the initial mcount to simply return. There's no need to do any other work.
      If the ftrace start up test fails, the original mcount will be what everything
      will use, so having this as fast as possible is a good thing.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0a37605c
  4. 13 10月, 2008 6 次提交
  5. 24 7月, 2008 1 次提交
    • R
      i386 syscall audit fast-path · af0575bb
      Roland McGrath 提交于
      This adds fast paths for 32-bit syscall entry and exit when
      TIF_SYSCALL_AUDIT is set, but no other kind of syscall tracing.
      These paths does not need to save and restore all registers as
      the general case of tracing does.  Avoiding the iret return path
      when syscall audit is enabled helps performance a lot.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      af0575bb
  6. 19 7月, 2008 1 次提交
  7. 17 7月, 2008 2 次提交
    • R
      x86 ptrace: unify syscall tracing · d4d67150
      Roland McGrath 提交于
      This unifies and cleans up the syscall tracing code on i386 and x86_64.
      
      Using a single function for entry and exit tracing on 32-bit made the
      do_syscall_trace() into some terrible spaghetti.  The logic is clear and
      simple using separate syscall_trace_enter() and syscall_trace_leave()
      functions as on 64-bit.
      
      The unification adds PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP support
      on x86_64, for 32-bit ptrace() callers and for 64-bit ptrace() callers
      tracing either 32-bit or 64-bit tasks.  It behaves just like 32-bit.
      
      Changing syscall_trace_enter() to return the syscall number shortens
      all the assembly paths, while adding the SYSEMU feature in a simple way.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      d4d67150
    • R
      x86 ptrace: unify TIF_SINGLESTEP · 64f09733
      Roland McGrath 提交于
      This unifies the treatment of TIF_SINGLESTEP on i386 and x86_64.
      The bit is now excluded from _TIF_WORK_MASK on i386 as it has been
      on x86_64.  This means the do_notify_resume() path using it is never
      used, so TIF_SINGLESTEP is not cleared on returning to user mode.
      
      Both now leave TIF_SINGLESTEP set when returning to user, so that
      it's already set on an int $0x80 system call entry.  This removes
      the need for testing TF on the system_call path.  Doing it this way
      fixes the regression for PTRACE_SINGLESTEP into a sigreturn syscall,
      introduced by commit 1e2e99f0.
      
      The clear_TF_reenable case that sets TIF_SINGLESTEP can only happen
      on a non-exception kernel entry, i.e. sysenter/syscall instruction.
      That will always get to the syscall exit tracing path.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      64f09733
  8. 12 7月, 2008 1 次提交
  9. 08 7月, 2008 1 次提交
    • J
      x86/paravirt: split sysret and sysexit · d75cd22f
      Jeremy Fitzhardinge 提交于
      Don't conflate sysret and sysexit; they're different instructions with
      different semantics, and may be in use at the same time (at least
      within the same kernel, depending on whether its an Intel or AMD
      system).
      
      sysexit - just return to userspace, does no register restoration of
          any kind; must explicitly atomically enable interrupts.
      
      sysret - reloads flags from r11, so no need to explicitly enable
          interrupts on 64-bit, responsible for restoring usermode %gs
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citirx.com>
      Cc: xen-devel <xen-devel@lists.xensource.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d75cd22f
  10. 24 6月, 2008 1 次提交
  11. 13 6月, 2008 1 次提交
    • P
      x86: fix lockdep warning during suspend-to-ram · e32e58a9
      Peter Zijlstra 提交于
      Andrew Morton wrote:
      
      > I've been seeing the below for a long time during suspend-to-ram on the Vaio.
      >
      >
      > PM: Syncing filesystems ... done.
      > PM: Preparing system for mem sleep
      > Freezing user space processes ... <4>------------[ cut here ]------------
      > WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x127()
      > Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy sr_mod snd_seq_oss cdrom snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ieee80211 pcspkr ieee80211_crypt snd_pcm i2c_i801 snd_timer i2c_core ide_pci_generic piix snd soundcore snd_page_alloc button ext3 jbd ide_disk ide_core [last unloaded: ipw2200]
      > Pid: 3250, comm: zsh Not tainted 2.6.26-rc5 #1
      >  [<c011c5f5>] warn_on_slowpath+0x41/0x6d
      >  [<c01080e6>] ? native_sched_clock+0x82/0x96
      >  [<c013789c>] ? mark_held_locks+0x41/0x5c
      >  [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58
      >  [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d
      >  [<c0138637>] ? __lock_acquire+0xae3/0xb2b
      >  [<c0313413>] ? schedule+0x39b/0x3b4
      >  [<c0135596>] check_flags+0x4c/0x127
      >  [<c01386b9>] lock_acquire+0x3a/0x86
      >  [<c0315075>] _spin_lock+0x26/0x53
      >  [<c0140660>] ? refrigerator+0x13/0xc3
      >  [<c0140660>] refrigerator+0x13/0xc3
      >  [<c012684a>] get_signal_to_deliver+0x3c/0x31e
      >  [<c0102fe7>] do_notify_resume+0x91/0x6ee
      >  [<c01359fd>] ? lock_release_holdtime+0x50/0x56
      >  [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58
      >  [<c0235d24>] ? read_chan+0x0/0x58c
      >  [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d
      >  [<c0315694>] ? _spin_unlock_irqrestore+0x42/0x58
      >  [<c0230afa>] ? tty_ldisc_deref+0x5c/0x63
      >  [<c0233104>] ? tty_read+0x66/0x98
      >  [<c014b3f0>] ? audit_syscall_exit+0x2aa/0x2c5
      >  [<c0109430>] ? do_syscall_trace+0x6b/0x16f
      >  [<c0103a9c>] work_notifysig+0x13/0x1b
      >  =======================
      > ---[ end trace 25b49fe59a25afa5 ]---
      > possible reason: unannotated irqs-off.
      > irq event stamp: 58919
      > hardirqs last  enabled at (58919): [<c0103afd>] syscall_exit_work+0x11/0x26
      
      Joy - I so love entry.S
      
      Best I can make of it:
      
      syscall_exit_work
        resume_userspace
          DISABLE_INTERRUPTS
          (no TRACE_IRQS_OFF)
            work_pending
              work_notifysig
                do_notify_resume()
                  do_signal()
                    get_signal_to_deliver()
                      try_to_freeze()
                        refrigerator()
                          task_lock() -> check_flags() -> BANG
      
      The normal path is:
      
      syscall_exit_work
        resume_userspace
          DISABLE_INTERRUPTS
          restore_all
            TRACE_IRQS_IRET
            iret
      
      No idea why that would not warn..
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e32e58a9
  12. 24 5月, 2008 2 次提交
    • S
      ftrace: use dynamic patching for updating mcount calls · d61f82d0
      Steven Rostedt 提交于
      This patch replaces the indirect call to the mcount function
      pointer with a direct call that will be patched by the
      dynamic ftrace routines.
      
      On boot up, the mcount function calls the ftace_stub function.
      When the dynamic ftrace code is initialized, the ftrace_stub
      is replaced with a call to the ftrace_record_ip, which records
      the instruction pointers of the locations that call it.
      
      Later, the ftraced daemon will call kstop_machine and patch all
      the locations to nops.
      
      When a ftrace is enabled, the original calls to mcount will now
      be set top call ftrace_caller, which will do a direct call
      to the registered ftrace function. This direct call is also patched
      when the function that should be called is updated.
      
      All patching is performed by a kstop_machine routine to prevent any
      type of race conditions that is associated with modifying code
      on the fly.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d61f82d0
    • A
      ftrace: add basic support for gcc profiler instrumentation · 16444a8a
      Arnaldo Carvalho de Melo 提交于
      If CONFIG_FTRACE is selected and /proc/sys/kernel/ftrace_enabled is
      set to a non-zero value the ftrace routine will be called everytime
      we enter a kernel function that is not marked with the "notrace"
      attribute.
      
      The ftrace routine will then call a registered function if a function
      happens to be registered.
      
      [ This code has been highly hacked by Steven Rostedt and Ingo Molnar,
        so don't blame Arnaldo for all of this ;-) ]
      
      Update:
        It is now possible to register more than one ftrace function.
        If only one ftrace function is registered, that will be the
        function that ftrace calls directly. If more than one function
        is registered, then ftrace will call a function that will loop
        through the functions to call.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      16444a8a
  13. 13 5月, 2008 1 次提交
  14. 25 4月, 2008 4 次提交
  15. 20 4月, 2008 1 次提交
  16. 17 4月, 2008 2 次提交
  17. 19 2月, 2008 1 次提交
  18. 10 2月, 2008 1 次提交
  19. 30 1月, 2008 4 次提交
  20. 17 10月, 2007 1 次提交
    • J
      paravirt: refactor struct paravirt_ops into smaller pv_*_ops · 93b1eab3
      Jeremy Fitzhardinge 提交于
      This patch refactors the paravirt_ops structure into groups of
      functionally related ops:
      
      pv_info - random info, rather than function entrypoints
      pv_init_ops - functions used at boot time (some for module_init too)
      pv_misc_ops - lazy mode, which didn't fit well anywhere else
      pv_time_ops - time-related functions
      pv_cpu_ops - various privileged instruction ops
      pv_irq_ops - operations for managing interrupt state
      pv_apic_ops - APIC operations
      pv_mmu_ops - operations for managing pagetables
      
      There are several motivations for this:
      
      1. Some of these ops will be general to all x86, and some will be
         i386/x86-64 specific.  This makes it easier to share common stuff
         while allowing separate implementations where needed.
      
      2. At the moment we must export all of paravirt_ops, but modules only
         need selected parts of it.  This allows us to export on a case by case
         basis (and also choose which export license we want to apply).
      
      3. Functional groupings make things a bit more readable.
      
      Struct paravirt_ops is now only used as a template to generate
      patch-site identifiers, and to extract function pointers for inserting
      into jmp/calls when patching.  It is only instantiated when needed.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Zach Amsden <zach@vmware.com>
      Cc: Avi Kivity <avi@qumranet.com>
      Cc: Anthony Liguory <aliguori@us.ibm.com>
      Cc: "Glauber de Oliveira Costa" <glommer@gmail.com>
      Cc: Jun Nakajima <jun.nakajima@intel.com>
      93b1eab3
  21. 12 10月, 2007 1 次提交
  22. 11 10月, 2007 3 次提交
  23. 19 7月, 2007 1 次提交
  24. 18 7月, 2007 1 次提交
    • J
      xen: use iret directly when possible · 9ec2b804
      Jeremy Fitzhardinge 提交于
      Most of the time we can simply use the iret instruction to exit the
      kernel, rather than having to use the iret hypercall - the only
      exception is if we're returning into vm86 mode, or from delivering an
      NMI (which we don't support yet).
      
      When running native, iret has the behaviour of testing for a pending
      interrupt atomically with re-enabling interrupts.  Unfortunately
      there's no way to do this with Xen, so there's a window in which we
      could get a recursive exception after enabling events but before
      actually returning to userspace.
      
      This causes a problem: if the nested interrupt causes one of the
      task's TIF_WORK_MASK flags to be set, they will not be checked again
      before returning to userspace.  This means that pending work may be
      left pending indefinitely, until the process enters and leaves the
      kernel again.  The net effect is that a pending signal or reschedule
      event could be delayed for an unbounded amount of time.
      
      To deal with this, the xen event upcall handler checks to see if the
      EIP is within the critical section of the iret code, after events
      are (potentially) enabled up to the iret itself.  If its within this
      range, it calls the iret critical section fixup, which adjusts the
      stack to deal with any unrestored registers, and then shifts the
      stack frame up to replace the previous invocation.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      9ec2b804