Re: [Xen-devel] [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

2017-10-05 Thread Steven Rostedt 
On Thu, 5 Oct 2017 09:01:14 -0700
Thomas Garnier <thgar...@google.com> wrote:

> On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rost...@goodmis.org> wrote:
> > On Wed,  4 Oct 2017 14:19:56 -0700
> > Thomas Garnier <thgar...@google.com> wrote:
> >  
> >> When using -fPIE/PIC with function tracing, the compiler generates a
> >> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> >> takes 6 bytes instead of 5 on the usual relative call.
> >>
> >> With this change, function tracing supports 6 bytes on traceable
> >> function and can still replace relative calls on the ftrace assembly
> >> functions.
> >>
> >> Position Independent Executable (PIE) support will allow to extended the
> >> KASLR randomization range below the -2G memory limit.  
> >
> > Question: This 6 bytes is only the initial call that gcc creates. When
> > function tracing is enabled, the calls are back to the normal call to
> > the ftrace trampoline?  
> 
> That is correct.
> 

Then I think a better idea is to simply nop them out at compile time,
and have the code that updates them to nops to know about it.

See scripts/recordmcount.c

Could we simply add a 5 byte nop followed by a 1 byte nop, and treat it
the same as if it didn't exist? This code can be a little complex, and
can cause really nasty side effects if things go wrong. I would like to
keep from adding more variables to the changes here.

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

2017-10-05 Thread Steven Rostedt 
On Wed,  4 Oct 2017 14:19:56 -0700
Thomas Garnier  wrote:

> When using -fPIE/PIC with function tracing, the compiler generates a
> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> takes 6 bytes instead of 5 on the usual relative call.
> 
> With this change, function tracing supports 6 bytes on traceable
> function and can still replace relative calls on the ftrace assembly
> functions.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.

Question: This 6 bytes is only the initial call that gcc creates. When
function tracing is enabled, the calls are back to the normal call to
the ftrace trampoline?

-- Steve


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

2017-08-24 Thread Steven Rostedt 
On Thu, 24 Aug 2017 14:13:38 -0700
Thomas Garnier  wrote:

> With the fix for function tracing, the hackbench results have an
> average of +0.8 to +1.4% (from +8% to +10% before). With a default
> configuration, the numbers are closer to 0.8%.

Wow, an empty fentry function not "nop"ed out only added 8% to 10%
overhead. I never did the benchmarks of that since I did it before
fentry was introduced, which was with the old "mcount". That gave an
average of 13% overhead in hackbench.

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

2017-08-15 Thread Steven Rostedt 
On Fri, 11 Aug 2017 14:07:14 +0200
Peter Zijlstra  wrote:

> It goes like:
> 
>   CPU0CPU1
> 
>   unhook page
>   cli
>   traverse page tables
>   TLB invalidate ---> 
>   sti
>   
>TLB invalidate
>   <--  complete

I guess the important part here is the above "complete". CPU0 doesn't
proceed until its receives it. Thus it does act like
cli~rcu_read_lock(), sti~rcu_read_unlock(), and "TLB invalidate" is
equivalent to synchronize_rcu().

[ this response is for clarification for the casual observer of this
  thread ;-) ]

-- Steve

>   
>   free page
> 
> So the CPU1 page-table walker gets an existence guarantee of the
> page-tables by clearing IF.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen: remove not used trace functions

2017-08-14 Thread Steven Rostedt 
On Fri, 4 Aug 2017 15:35:06 -0400
Boris Ostrovsky <boris.ostrov...@oracle.com> wrote:

> On 08/04/2017 07:36 AM, Juergen Gross wrote:
> > There are some Xen specific trace functions defined in
> > include/trace/events/xen.h. Remove them.
> >
> > Signed-off-by: Juergen Gross <jgr...@suse.com>  
> 
> (Again, adding Ingo and Steven)

Feel free to add:

Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org>

to both.

-- Steve

> 
> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
> 
> although I think "s/some Xen/some unused Xen/" in the commit message
> would make it clearer.
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] xen: remove unused function xen_set_domain_pte()

2017-08-14 Thread Steven Rostedt 
On Fri, 4 Aug 2017 15:20:30 -0400
Boris Ostrovsky  wrote:

> On 08/04/2017 07:36 AM, Juergen Gross wrote:
> > The function xen_set_domain_pte() is used nowhere in the kernel.
> > Remove it.
> >
> > Signed-off-by: Juergen Gross   
> 
> Reviewed-by: Boris Ostrovsky 
> 
> (+ Ingo and Steven who are maintainers of include/trace/events/xen.h)

But the maintainers of where the tracepoints are located have final
say (in this case, the Xen maintainers). I like to be Cc'd to make sure
that the events are efficient and don't waste cpu unnecessary CPU
cycles or memory.

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 09/35] x86: Convert remaining uses of pr_warning to pr_warn

2017-02-17 Thread Steven Rostedt 
On Thu, 16 Feb 2017 23:11:22 -0800
Joe Perches <j...@perches.com> wrote:

> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index 38868adf07ea..4a55e453296d 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -121,9 +121,8 @@ static int __init init(void)
>   return -ENXIO;
>   }
>  
> - pr_warning("WARNING: mapping %lu kB @ 0x%08lx in PCI address space, "
> -"and writing 16 kB of rubbish in there.\n",
> -size >> 10, mmio_address);
> + pr_warn("WARNING: mapping %lu kB @ 0x%08lx in PCI address space, and 
> writing 16 kB of rubbish in there\n",
> + size >> 10, mmio_address);
>   do_test(size);
>   do_test_bulk_ioremapping();
>   pr_info("All done.\n");

Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org>

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

2016-08-15 Thread Steven Rostedt 
On Mon, 15 Aug 2016 21:15:06 +0100
Alan Cox  wrote:

> > This is the module tag ... it says what licence the module is under,
> > not the licence for the module combined with the kernel, which is
> > always GPLv2 because the stricter licence rules.  
> 
> Because if I build a BSD licensed module against the kernel, give you
> the binaries and refuse to give you the source I am conforming to the
> BSD licence in letter. So to use it with the kernel it needs to be GPL
> with additional rights (eg BSD including the source...)
> 

But that only pertains to the code that was modified to be used with
the Linux kernel, right? That is, if there's a BSD licensed module for
device FOO, and I port it to the Linux kernel, that will need to have a
GPL added to it to be included in Linux. But the original BSD code is
not affected. If a fix is made to the GPL Linux version, I'm assuming
(because I've been asked when doing something like this), that the
author of that fix will have to give it a dual license to be used back
in the original BSD only code. Correct?

I'm just trying to understand this. From what would make sense to me
(but may or may not to a court of law, where it counts), is that the
code added to Linux must be under GPL. But using that code depends on
where you get it from. If you use BSD source, it stays under BSD. But
any fixes to the GPL version will require permission to be put back to
the BSD version. A change to the GPL version doesn't automatically get
allowed back to the BSD only version?

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v3 05/13] sections.h: add sections header to collect all section info

2016-07-29 Thread Steven Rostedt 
On Fri, 22 Jul 2016 22:37:16 +0100
James Hogan  wrote:


> > --- /dev/null
> > +++ b/arch/alpha/include/asm/sections.h
> > @@ -0,0 +1,6 @@
> > +#ifndef _ASM_ALPHA_SECTIONS_H
> > +#define _ASM_ALPHA_SECTIONS_H
> > +
> > +#include 
> > +
> > +#endif /* _ASM_ALPHA_SECTIONS_H */  
> 
> Any particular reason not to use generic-y in the Kbuild files for
> sections.h, ranges.h, and tables.h?

One of my TODOs is to simplify that process. That is, to get rid of the
having to add it to all archs and get rid of the Kbuild file altogether.

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to be preempted

2015-01-22 Thread Steven Rostedt 
On Thu, 22 Jan 2015 17:40:27 -0800
Andy Lutomirski l...@amacapital.net wrote:

 
  +/*
  + * CONFIG_PREEMPT=n kernels can end up triggering the softlock
  + * TASK_UNINTERRUPTIBLE hanger check (default 120 seconds)
  + * when certain multicalls are used [0] on large systems, in
  + * that case we need a way to voluntarily preempt. This is
  + * only an issue on CONFIG_PREEMPT=n kernels.
  + *
  + * [0] https://bugzilla.novell.com/show_bug.cgi?id=861093
  + */
  +void xen_end_upcall(struct pt_regs *regs)
  +{
  +   if (xen_is_preemptible_hypercall(regs)) {
  +   int cpuid = smp_processor_id();
  +   if (_cond_resched())
  +   trace_xen_hypercall_preemption(cpuid);
 
 If you want to speed this up a bit, I think you could move the
 smp_processor_id() into the TP_fast_assign.  But don't tracepoints
 report the cpu number even without any action?

Yes, but if you scheduled here, the tracepoint could happen on a
different CPU. Thus, cpuid will not equal smp_processor_id().

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

2015-01-22 Thread Steven Rostedt 

[ Added Paul McKenney ]

On Thu, 22 Jan 2015 19:39:13 +0100
Luis R. Rodriguez mcg...@suse.com wrote:

  Why not make this a tracepoint? Then you can enable it only when you
  want to. As tracepoints are also hooks, you could add you own code that
  hooks to it and does a printk as well. The advantage of doing it via a
  tracepoint is that you can turn it on and off regardless of what the
  loglevel is set at.
 
 This uses NOKPROBE_SYMBOL and notrace since based on Andy's advice
 we are not confident that tracing and kprobes are safe to use in what
 might be an extended RCU quiescent state (i.e. where we're outside
 irq_enter and irq_exit).

We have trace_*_rcuidle() for such cases.

That is, you create the tracepoint just the same, and instead of having
trace_foo(), if you are in a known area that is outside of rcu viewing,
you use trace_foo_rcuidle() and it will tell RCU hey, there's something
here that may need RCU, so look at me!

Also, please remove the notrace, because function tracing goes an
extra step to not require RCU being visible. The only thing you get
with notrace is not being able to trace an otherwise traceable function.

-- Steve

 
  That is, if there is any practical use for that message. Tracing just
  sched_switch will give you the same info.
 
 IMHO it may be more useful if we knew exactly what hypercalls were
 being preempted but perhaps all that can be left as a secondary
 exercise and for now I'll just nuke the print.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

2015-01-22 Thread Steven Rostedt 
On Thu, 22 Jan 2015 12:58:00 -0800
Andy Lutomirski l...@amacapital.net wrote:

 On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt rost...@goodmis.org wrote:
  On Thu, 22 Jan 2015 12:24:47 -0800
  Andy Lutomirski l...@amacapital.net wrote:
 
   Also, please remove the notrace, because function tracing goes an
   extra step to not require RCU being visible. The only thing you get
   with notrace is not being able to trace an otherwise traceable function.
  
 
  Is this also true for kprobes?  And can kprobes nest inside function
  tracing hooks?
 
  No, kprobes are a bit more fragile than function tracing or tracepoints.
 
  And nothing should nest inside a function hook (except for interrupts,
  they are fine).
 
 
 But kprobes do nest inside interrupts, right?

A kprobe being called while a function trace is happening is fine, but
you should not have the kprobe set directly inside the function trace
callback code. Because that means a kprobe could happen anywhere
function tracing is happening (for instance, in NMI context).

 
 
  The other issue, above and beyond RCU, is that we can't let kprobes
  run on the int3 stack.  If Xen upcalls can happen when interrupts are
  off, then we may need this protection to prevent that type of
  recursion.  (This will be much less scary in 3.20, because userspace
  int3 instructions will no longer execute on the int3 stack.)
 
  Does this execute between the start of the int3 interrupt handler and
  the call of do_int3()?
 
 I doubt it.
 
 The thing I worry about is that, if do_int3 nests inside itself by any
 means (e.g. int3 sends a signal, scheduling for whatever reason
 (really shouldn't happen, but I haven't looked that hard)), then we're
 completely hosed -- the inner int3 will overwrite the outer int3's
 stack frame.  Since I have no idea what Xen upcalls do, I don't know
 whether they can fire inside do_int3.

I thought there's logic in the do_int3 handler (in the assembly code)
that can handle nested int3s.

I'm not sure what xen does though.

-- Steve

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel