1. 02 12月, 2008 1 次提交
    • F
      tracing/function-graph-tracer: support for x86-64 · 48d68b20
      Frederic Weisbecker 提交于
      Impact: extend and enable the function graph tracer to 64-bit x86
      
      This patch implements the support for function graph tracer under x86-64.
      Both static and dynamic tracing are supported.
      
      This causes some small CPP conditional asm on arch/x86/kernel/ftrace.c I
      wanted to use probe_kernel_read/write to make the return address
      saving/patching code more generic but it causes tracing recursion.
      
      That would be perhaps useful to implement a notrace version of these
      function for other archs ports.
      
      Note that arch/x86/process_64.c is not traced, as in X86-32. I first
      thought __switch_to() was responsible of crashes during tracing because I
      believed current task were changed inside but that's actually not the
      case (actually yes, but not the "current" pointer).
      
      So I will have to investigate to find the functions that harm here, to
      enable tracing of the other functions inside (but there is no issue at
      this time, while process_64.c stays out of -pg flags).
      
      A little possible race condition is fixed inside this patch too. When the
      tracer allocate a return stack dynamically, the current depth is not
      initialized before but after. An interrupt could occur at this time and,
      after seeing that the return stack is allocated, the tracer could try to
      trace it with a random uninitialized depth. It's a prevention, even if I
      hadn't problems with it.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tim Bird <tim.bird@am.sony.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      48d68b20
  2. 26 11月, 2008 12 次提交
  3. 25 11月, 2008 2 次提交
  4. 23 11月, 2008 6 次提交
    • I
      xen: pin correct PGD on suspend · 86bbc2c2
      Ian Campbell 提交于
      Impact: fix Xen guest boot failure
      
      commit eefb47f6 ("xen: use
      spin_lock_nest_lock when pinning a pagetable") changed xen_pgd_walk to
      walk over mm->pgd rather than taking pgd as an argument.
      
      This breaks xen_mm_(un)pin_all() because it makes init_mm.pgd readonly
      instead of the pgd we are interested in and therefore the pin subsequently
      fails.
      
      (XEN) mm.c:2280:d15 Bad type (saw 00000000e8000001 != exp 0000000060000000) for mfn bc464 (pfn 21ca7)
      (XEN) mm.c:2665:d15 Error while pinning mfn bc464
      
      [   14.586913] 1 multicall(s) failed: cpu 0
      [   14.586926] Pid: 14, comm: kstop/0 Not tainted 2.6.28-rc5-x86_32p-xenU-00172-gee2f6cc7 #200
      [   14.586940] Call Trace:
      [   14.586955]  [<c030c17a>] ? printk+0x18/0x1e
      [   14.586972]  [<c0103df3>] xen_mc_flush+0x163/0x1d0
      [   14.586986]  [<c0104bc1>] __xen_pgd_pin+0xa1/0x110
      [   14.587000]  [<c015a330>] ? stop_cpu+0x0/0xf0
      [   14.587015]  [<c0104d7b>] xen_mm_pin_all+0x4b/0x70
      [   14.587029]  [<c022bcb9>] xen_suspend+0x39/0xe0
      [   14.587042]  [<c015a330>] ? stop_cpu+0x0/0xf0
      [   14.587054]  [<c015a3cd>] stop_cpu+0x9d/0xf0
      [   14.587067]  [<c01417cd>] run_workqueue+0x8d/0x150
      [   14.587080]  [<c030e4b3>] ? _spin_unlock_irqrestore+0x23/0x40
      [   14.587094]  [<c014558a>] ? prepare_to_wait+0x3a/0x70
      [   14.587107]  [<c0141918>] worker_thread+0x88/0xf0
      [   14.587120]  [<c01453c0>] ? autoremove_wake_function+0x0/0x50
      [   14.587133]  [<c0141890>] ? worker_thread+0x0/0xf0
      [   14.587146]  [<c014509c>] kthread+0x3c/0x70
      [   14.587157]  [<c0145060>] ? kthread+0x0/0x70
      [   14.587170]  [<c0109d1b>] kernel_thread_helper+0x7/0x10
      [   14.587181]   call  1/3: op=14 arg=[c0415000] result=0
      [   14.587192]   call  2/3: op=14 arg=[e1ca2000] result=0
      [   14.587204]   call  3/3: op=26 arg=[c1808860] result=-22
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      86bbc2c2
    • T
      x86: revert irq number limitation · a1967d64
      Thomas Gleixner 提交于
      Impact: fix MSIx not enough irq numbers available regression
      
      The manual revert of the sparse_irq patches missed to bring the number
      of possible irqs back to the .27 status. This resulted in a regression
      when two multichannel network cards were placed in a system with only
      one IO_APIC - causing the networking driver to not have the right
      IRQ and the device not coming up.
      
      Remove the dynamic allocation logic leftovers and simply return
      NR_IRQS in probe_nr_irqs() for now.
      
         Fixes: http://lkml.org/lkml/2008/11/19/354Reported-by: NJesper Dangaard Brouer <hawk@diku.dk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJesper Dangaard Brouer <hawk@diku.dk>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a1967d64
    • T
      tracing/stack-tracer: introduce CONFIG_USER_STACKTRACE_SUPPORT · 8d26487f
      Török Edwin 提交于
      Impact: cleanup
      
      User stack tracing is just implemented for x86, but it is not x86 specific.
      
      Introduce a generic config flag, that is currently enabled only for x86.
      When other arches implement it, they will have to
      SELECT USER_STACKTRACE_SUPPORT.
      Signed-off-by: NTörök Edwin <edwintorok@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d26487f
    • T
      tracing/stack-tracer: fix style issues · 8d7c6a96
      Török Edwin 提交于
      Impact: cleanup
      Signed-off-by: NTörök Edwin <edwintorok@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d7c6a96
    • T
      tracing: add support for userspace stacktraces in tracing/iter_ctrl · 02b67518
      Török Edwin 提交于
      Impact: add new (default-off) tracing visualization feature
      
      Usage example:
      
       mount -t debugfs nodev /sys/kernel/debug
       cd /sys/kernel/debug/tracing
       echo userstacktrace >iter_ctrl
       echo sched_switch >current_tracer
       echo 1 >tracing_enabled
       .... run application ...
       echo 0 >tracing_enabled
      
      Then read one of 'trace','latency_trace','trace_pipe'.
      
      To get the best output you can compile your userspace programs with
      frame pointers (at least glibc + the app you are tracing).
      Signed-off-by: NTörök Edwin <edwintorok@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      02b67518
    • F
      tracing/function-return-tracer: store return stack into task_struct and allocate it dynamically · f201ae23
      Frederic Weisbecker 提交于
      Impact: use deeper function tracing depth safely
      
      Some tests showed that function return tracing needed a more deeper depth
      of function calls. But it could be unsafe to store these return addresses
      to the stack.
      
      So these arrays will now be allocated dynamically into task_struct of current
      only when the tracer is activated.
      
      Typical scheme when tracer is activated:
      - allocate a return stack for each task in global list.
      - fork: allocate the return stack for the newly created task
      - exit: free return stack of current
      - idle init: same as fork
      
      I chose a default depth of 50. I don't have overruns anymore.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f201ae23
  5. 21 11月, 2008 1 次提交
    • M
      x86: Fix interrupt leak due to migration · 0ca4b6b0
      Matthew Wilcox 提交于
      When we migrate an interrupt from one CPU to another, we set the
      move_in_progress flag and clean up the vectors later once they're not
      being used.  If you're unlucky and call destroy_irq() before the vectors
      become un-used, the move_in_progress flag is never cleared, which causes
      the interrupt to become unusable.
      
      This was discovered by Jesse Brandeburg for whom it manifested as an
      MSI-X device refusing to use MSI-X mode when the driver was unloaded
      and reloaded repeatedly.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ca4b6b0
  6. 20 11月, 2008 3 次提交
    • R
      x86: fixing __cpuinit/__init tangle, xsave_cntxt_init() · bfe085f6
      Rakib Mullick 提交于
      Annotate xsave_cntxt_init() as "can be called outside of __init".
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bfe085f6
    • R
      x86: fix __cpuinit/__init tangle in init_thread_xstate() · 9bc646f1
      Rakib Mullick 提交于
      Impact:	fix incorrect __init annotation
      
      This patch removes the following section mismatch warning. A patch set
      was send previously (http://lkml.org/lkml/2008/11/10/407). But
      introduce some other problem, reported by Rufus
      (http://lkml.org/lkml/2008/11/11/46). Then Ingo Molnar suggest that,
      it's best to remove __init from xsave_cntxt_init(void). Which is the
      second patch in this series. Now, this one removes the following
      warning.
      
      WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x2237): Section
      mismatch in reference from the function cpu_init() to the function
      .init.text:init_thread_xstate()
      The function __cpuinit cpu_init() references
      a function __init init_thread_xstate().
      If init_thread_xstate is only used by cpu_init then
      annotate init_thread_xstate with a matching annotation.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9bc646f1
    • U
      reintroduce accept4 · de11defe
      Ulrich Drepper 提交于
      Introduce a new accept4() system call.  The addition of this system call
      matches analogous changes in 2.6.27 (dup3(), evenfd2(), signalfd4(),
      inotify_init1(), epoll_create1(), pipe2()) which added new system calls
      that differed from analogous traditional system calls in adding a flags
      argument that can be used to access additional functionality.
      
      The accept4() system call is exactly the same as accept(), except that
      it adds a flags bit-mask argument.  Two flags are initially implemented.
      (Most of the new system calls in 2.6.27 also had both of these flags.)
      
      SOCK_CLOEXEC causes the close-on-exec (FD_CLOEXEC) flag to be enabled
      for the new file descriptor returned by accept4().  This is a useful
      security feature to avoid leaking information in a multithreaded
      program where one thread is doing an accept() at the same time as
      another thread is doing a fork() plus exec().  More details here:
      http://udrepper.livejournal.com/20407.html "Secure File Descriptor Handling",
      Ulrich Drepper).
      
      The other flag is SOCK_NONBLOCK, which causes the O_NONBLOCK flag
      to be enabled on the new open file description created by accept4().
      (This flag is merely a convenience, saving the use of additional calls
      fcntl(F_GETFL) and fcntl (F_SETFL) to achieve the same result.
      
      Here's a test program.  Works on x86-32.  Should work on x86-64, but
      I (mtk) don't have a system to hand to test with.
      
      It tests accept4() with each of the four possible combinations of
      SOCK_CLOEXEC and SOCK_NONBLOCK set/clear in 'flags', and verifies
      that the appropriate flags are set on the file descriptor/open file
      description returned by accept4().
      
      I tested Ulrich's patch in this thread by applying against 2.6.28-rc2,
      and it passes according to my test program.
      
      /* test_accept4.c
      
        Copyright (C) 2008, Linux Foundation, written by Michael Kerrisk
             <mtk.manpages@gmail.com>
      
        Licensed under the GNU GPLv2 or later.
      */
      #define _GNU_SOURCE
      #include <unistd.h>
      #include <sys/syscall.h>
      #include <sys/socket.h>
      #include <netinet/in.h>
      #include <stdlib.h>
      #include <fcntl.h>
      #include <stdio.h>
      #include <string.h>
      
      #define PORT_NUM 33333
      
      #define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
      
      /**********************************************************************/
      
      /* The following is what we need until glibc gets a wrapper for
        accept4() */
      
      /* Flags for socket(), socketpair(), accept4() */
      #ifndef SOCK_CLOEXEC
      #define SOCK_CLOEXEC    O_CLOEXEC
      #endif
      #ifndef SOCK_NONBLOCK
      #define SOCK_NONBLOCK   O_NONBLOCK
      #endif
      
      #ifdef __x86_64__
      #define SYS_accept4 288
      #elif __i386__
      #define USE_SOCKETCALL 1
      #define SYS_ACCEPT4 18
      #else
      #error "Sorry -- don't know the syscall # on this architecture"
      #endif
      
      static int
      accept4(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags)
      {
         printf("Calling accept4(): flags = %x", flags);
         if (flags != 0) {
             printf(" (");
             if (flags & SOCK_CLOEXEC)
                 printf("SOCK_CLOEXEC");
             if ((flags & SOCK_CLOEXEC) && (flags & SOCK_NONBLOCK))
                 printf(" ");
             if (flags & SOCK_NONBLOCK)
                 printf("SOCK_NONBLOCK");
             printf(")");
         }
         printf("\n");
      
      #if USE_SOCKETCALL
         long args[6];
      
         args[0] = fd;
         args[1] = (long) sockaddr;
         args[2] = (long) addrlen;
         args[3] = flags;
      
         return syscall(SYS_socketcall, SYS_ACCEPT4, args);
      #else
         return syscall(SYS_accept4, fd, sockaddr, addrlen, flags);
      #endif
      }
      
      /**********************************************************************/
      
      static int
      do_test(int lfd, struct sockaddr_in *conn_addr,
             int closeonexec_flag, int nonblock_flag)
      {
         int connfd, acceptfd;
         int fdf, flf, fdf_pass, flf_pass;
         struct sockaddr_in claddr;
         socklen_t addrlen;
      
         printf("=======================================\n");
      
         connfd = socket(AF_INET, SOCK_STREAM, 0);
         if (connfd == -1)
             die("socket");
         if (connect(connfd, (struct sockaddr *) conn_addr,
                     sizeof(struct sockaddr_in)) == -1)
             die("connect");
      
         addrlen = sizeof(struct sockaddr_in);
         acceptfd = accept4(lfd, (struct sockaddr *) &claddr, &addrlen,
                            closeonexec_flag | nonblock_flag);
         if (acceptfd == -1) {
             perror("accept4()");
             close(connfd);
             return 0;
         }
      
         fdf = fcntl(acceptfd, F_GETFD);
         if (fdf == -1)
             die("fcntl:F_GETFD");
         fdf_pass = ((fdf & FD_CLOEXEC) != 0) ==
                    ((closeonexec_flag & SOCK_CLOEXEC) != 0);
         printf("Close-on-exec flag is %sset (%s); ",
                 (fdf & FD_CLOEXEC) ? "" : "not ",
                 fdf_pass ? "OK" : "failed");
      
         flf = fcntl(acceptfd, F_GETFL);
         if (flf == -1)
             die("fcntl:F_GETFD");
         flf_pass = ((flf & O_NONBLOCK) != 0) ==
                    ((nonblock_flag & SOCK_NONBLOCK) !=0);
         printf("nonblock flag is %sset (%s)\n",
                 (flf & O_NONBLOCK) ? "" : "not ",
                 flf_pass ? "OK" : "failed");
      
         close(acceptfd);
         close(connfd);
      
         printf("Test result: %s\n", (fdf_pass && flf_pass) ? "PASS" : "FAIL");
         return fdf_pass && flf_pass;
      }
      
      static int
      create_listening_socket(int port_num)
      {
         struct sockaddr_in svaddr;
         int lfd;
         int optval;
      
         memset(&svaddr, 0, sizeof(struct sockaddr_in));
         svaddr.sin_family = AF_INET;
         svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
         svaddr.sin_port = htons(port_num);
      
         lfd = socket(AF_INET, SOCK_STREAM, 0);
         if (lfd == -1)
             die("socket");
      
         optval = 1;
         if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &optval,
                        sizeof(optval)) == -1)
             die("setsockopt");
      
         if (bind(lfd, (struct sockaddr *) &svaddr,
                  sizeof(struct sockaddr_in)) == -1)
             die("bind");
      
         if (listen(lfd, 5) == -1)
             die("listen");
      
         return lfd;
      }
      
      int
      main(int argc, char *argv[])
      {
         struct sockaddr_in conn_addr;
         int lfd;
         int port_num;
         int passed;
      
         passed = 1;
      
         port_num = (argc > 1) ? atoi(argv[1]) : PORT_NUM;
      
         memset(&conn_addr, 0, sizeof(struct sockaddr_in));
         conn_addr.sin_family = AF_INET;
         conn_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
         conn_addr.sin_port = htons(port_num);
      
         lfd = create_listening_socket(port_num);
      
         if (!do_test(lfd, &conn_addr, 0, 0))
             passed = 0;
         if (!do_test(lfd, &conn_addr, SOCK_CLOEXEC, 0))
             passed = 0;
         if (!do_test(lfd, &conn_addr, 0, SOCK_NONBLOCK))
             passed = 0;
         if (!do_test(lfd, &conn_addr, SOCK_CLOEXEC, SOCK_NONBLOCK))
             passed = 0;
      
         close(lfd);
      
         exit(passed ? EXIT_SUCCESS : EXIT_FAILURE);
      }
      
      [mtk.manpages@gmail.com: rewrote changelog, updated test program]
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Tested-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Cc: <linux-api@vger.kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      de11defe
  7. 19 11月, 2008 2 次提交
  8. 18 11月, 2008 9 次提交
    • P
      x86: more general identifier for Phoenix BIOS · 0af40a4b
      Philipp Kohlbecher 提交于
      Impact: widen the reach of the low-memory-protect DMI quirk
      
      Phoenix BIOSes variously identify their vendor as "Phoenix Technologies,
      LTD" or "Phoenix Technologies LTD" (without the comma.)
      
      This patch makes the identification string in the bad_bios_dmi_table
      more general (following a suggestion by Ingo Molnar), so that both
      versions are handled.
      
      Again, the patched file compiles cleanly and the patch has been tested
      successfully on my machine.
      Signed-off-by: NPhilipp Kohlbecher <xt28@gmx.de>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0af40a4b
    • J
      AMD IOMMU: check for next_bit also in unmapped area · 8501c45c
      Joerg Roedel 提交于
      Impact: fix possible use of stale IO/TLB entries
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      8501c45c
    • J
      AMD IOMMU: fix fullflush comparison length · 695b5676
      Joerg Roedel 提交于
      Impact: fix comparison length for 'fullflush'
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      695b5676
    • J
      AMD IOMMU: enable device isolation per default · 3ce1f93c
      Joerg Roedel 提交于
      Impact: makes device isolation the default for AMD IOMMU
      
      Some device drivers showed double-free bugs of DMA memory while testing
      them with AMD IOMMU. If all devices share the same protection domain
      this can lead to data corruption and data loss. Prevent this by putting
      each device into its own protection domain per default.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      3ce1f93c
    • J
      AMD IOMMU: add parameter to disable device isolation · e5e1f606
      Joerg Roedel 提交于
      Impact: add a new AMD IOMMU kernel command line parameter
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      e5e1f606
    • I
      x86, PEBS/DS: fix code flow in ds_request() · 10db4ef7
      Ingo Molnar 提交于
      this compiler warning:
      
        arch/x86/kernel/ds.c: In function 'ds_request':
        arch/x86/kernel/ds.c:368: warning: 'context' may be used uninitialized in this function
      
      Shows that the code flow in ds_request() is buggy - it goes into
      the unlock+release-context path even when the context is not allocated
      yet.
      
      First allocate the context, then do the other checks.
      
      Also, take care with GFP allocations under the ds_lock spinlock.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      10db4ef7
    • F
      tracing/function-return-tracer: add the overrun field · 0231022c
      Frederic Weisbecker 提交于
      Impact: help to find the better depth of trace
      
      We decided to arbitrary define the depth of function return trace as
      "20". Perhaps this is not enough. To help finding an optimal depth, we
      measure now the overrun: the number of functions that have been missed
      for the current thread. By default this is not displayed, we have to
      do set a particular flag on the return tracer: echo overrun >
      /debug/tracing/trace_options And the overrun will be printed on the
      right.
      
      As the trace shows below, the current 20 depth is not enough.
      
      update_wall_time+0x37f/0x8c0 -> update_xtime_cache (345 ns) (Overruns: 2838)
      update_wall_time+0x384/0x8c0 -> clocksource_get_next (1141 ns) (Overruns: 2838)
      do_timer+0x23/0x100 -> update_wall_time (3882 ns) (Overruns: 2838)
      tick_do_update_jiffies64+0xbf/0x160 -> do_timer (5339 ns) (Overruns: 2838)
      tick_sched_timer+0x6a/0xf0 -> tick_do_update_jiffies64 (7209 ns) (Overruns: 2838)
      vgacon_set_cursor_size+0x98/0x120 -> native_io_delay (2613 ns) (Overruns: 274)
      vgacon_cursor+0x16e/0x1d0 -> vgacon_set_cursor_size (33151 ns) (Overruns: 274)
      set_cursor+0x5f/0x80 -> vgacon_cursor (36432 ns) (Overruns: 274)
      con_flush_chars+0x34/0x40 -> set_cursor (38790 ns) (Overruns: 274)
      release_console_sem+0x1ec/0x230 -> up (721 ns) (Overruns: 274)
      release_console_sem+0x225/0x230 -> wake_up_klogd (316 ns) (Overruns: 274)
      con_flush_chars+0x39/0x40 -> release_console_sem (2996 ns) (Overruns: 274)
      con_write+0x22/0x30 -> con_flush_chars (46067 ns) (Overruns: 274)
      n_tty_write+0x1cc/0x360 -> con_write (292670 ns) (Overruns: 274)
      smp_apic_timer_interrupt+0x2a/0x90 -> native_apic_mem_write (330 ns) (Overruns: 274)
      irq_enter+0x17/0x70 -> idle_cpu (413 ns) (Overruns: 274)
      smp_apic_timer_interrupt+0x2f/0x90 -> irq_enter (1525 ns) (Overruns: 274)
      ktime_get_ts+0x40/0x70 -> getnstimeofday (465 ns) (Overruns: 274)
      ktime_get_ts+0x60/0x70 -> set_normalized_timespec (436 ns) (Overruns: 274)
      ktime_get+0x16/0x30 -> ktime_get_ts (2501 ns) (Overruns: 274)
      hrtimer_interrupt+0x77/0x1a0 -> ktime_get (3439 ns) (Overruns: 274)
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0231022c
    • V
      x86: add rdtsc barrier to TSC sync check · 93ce99e8
      Venki Pallipadi 提交于
      Impact: fix incorrectly marked unstable TSC clock
      
      Patch (commit 0d12cdd5 "sched: improve sched_clock() performance") has
      a regression on one of the test systems here.
      
      With the patch, I see:
      
       checking TSC synchronization [CPU#0 -> CPU#1]:
       Measured 28 cycles TSC warp between CPUs, turning off TSC clock.
       Marking TSC unstable due to check_tsc_sync_source failed
      
      Whereas, without the patch syncs pass fine on all CPUs:
      
       checking TSC synchronization [CPU#0 -> CPU#1]: passed.
      
      Due to this, TSC is marked unstable, when it is not actually unstable.
      This is because syncs in check_tsc_wrap() goes away due to this commit.
      
      As per the discussion on this thread, correct way to fix this is to add
      explicit syncs as below?
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      93ce99e8
    • E
      oprofile: fix an overflow in ppro code · a4a16bea
      Eric Dumazet 提交于
      reset_value was changed from long to u64 in commit
      b9917028 (oprofile: Implement Intel
      architectural perfmon support)
      
      But dynamic allocation of this array use a wrong type (long instead of
      u64)
      
      Cc: Andi Kleen <ak@linux.intel.com>
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      a4a16bea
  9. 16 11月, 2008 4 次提交
    • Y
      x86: fix es7000 compiling · d3c6aa1e
      Yinghai Lu 提交于
      Impact: fix es7000 build
      
        CC      arch/x86/kernel/es7000_32.o
      arch/x86/kernel/es7000_32.c: In function find_unisys_acpi_oem_table:
      arch/x86/kernel/es7000_32.c:255: error: implicit declaration of function acpi_get_table_with_size
      arch/x86/kernel/es7000_32.c:261: error: implicit declaration of function early_acpi_os_unmap_memory
      arch/x86/kernel/es7000_32.c: In function unmap_unisys_acpi_oem_table:
      arch/x86/kernel/es7000_32.c:277: error: implicit declaration of function __acpi_unmap_table
      make[1]: *** [arch/x86/kernel/es7000_32.o] Error 1
      
      we applied one patch out of order...
      
      | commit a73aaedd
      | Author: Yinghai Lu <yhlu.kernel@gmail.com>
      | Date:   Sun Sep 14 02:33:14 2008 -0700
      |
      |    x86: check dsdt before find oem table for es7000, v2
      |
      |    v2: use __acpi_unmap_table()
      
      that patch need:
      
      	x86: use early_ioremap in __acpi_map_table
      	x86: always explicitly map acpi memory
      	acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap
      	acpi/x86: introduce __apci_map_table, v4
      
      submitted to the ACPI tree but not upstream yet.
      
      fix it until those patches applied, need to revert this one
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3c6aa1e
    • M
      x86, bts: fix unlock problem in ds.c · d1f1e9c0
      Markus Metzger 提交于
      Fix a problem where ds_request() returned an error without releasing the
      ds lock.
      Reported-by: NStephane Eranian <eranian@gmail.com>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d1f1e9c0
    • F
      tracing/function-return-tracer: support for dynamic ftrace on function return tracer · e7d3737e
      Frederic Weisbecker 提交于
      This patch adds the support for dynamic tracing on the function return tracer.
      The whole difference with normal dynamic function tracing is that we don't need
      to hook on a particular callback. The only pro that we want is to nop or set
      dynamically the calls to ftrace_caller (which is ftrace_return_caller here).
      
      Some security checks ensure that we are not trying to launch dynamic tracing for
      return tracing while normal function tracing is already running.
      
      An example of trace with getnstimeofday set as a filter:
      
      ktime_get_ts+0x22/0x50 -> getnstimeofday (2283 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1396 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1382 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1825 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1426 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1464 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1524 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1382 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1382 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1434 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1464 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1502 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1404 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1397 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1051 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1314 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1344 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1163 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1390 ns)
      ktime_get_ts+0x22/0x50 -> getnstimeofday (1374 ns)
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e7d3737e
    • F
      tracing/function-return-tracer: add a barrier to ensure return stack index is incremented in memory · b01c7466
      Frederic Weisbecker 提交于
      Impact: fix possible race condition in ftrace function return tracer
      
      This fixes a possible race condition if index incrementation
      is not immediately flushed in memory.
      
      Thanks for Andi Kleen and Steven Rostedt for pointing out this issue
      and give me this solution.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b01c7466