similar to: Patch "x86/cpu/vmware: Do not trace vmware_sched_clock()" has been added to the 4.14-stable tree

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt (VMware) <rostedt at goodmis.org> commit 15035388439f892017d38b05214d3cda6578af64 upstream. When running function tracing on a Linux guest running on VMware Workstation, the guest would crash. This is due to tracing of the sched_clock internal call of the VMware

This is a note to let you know that I've just added the patch titled x86/cpu/vmware: Do not trace vmware_sched_clock() to the 4.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-cpu-vmware-do-not-trace-vmware_sched_clock.patch and it can be found in the queue-4.18 subdirectory.

This is a note to let you know that I've just added the patch titled x86/cpu/vmware: Do not trace vmware_sched_clock() to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-cpu-vmware-do-not-trace-vmware_sched_clock.patch and it can be found in the queue-4.19 subdirectory.

4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt (VMware) <rostedt at goodmis.org> commit 15035388439f892017d38b05214d3cda6578af64 upstream. When running function tracing on a Linux guest running on VMware Workstation, the guest would crash. This is due to tracing of the sched_clock internal call of the VMware

4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt (VMware) <rostedt at goodmis.org> commit 15035388439f892017d38b05214d3cda6578af64 upstream. When running function tracing on a Linux guest running on VMware Workstation, the guest would crash. This is due to tracing of the sched_clock internal call of the VMware

From: Steven Rostedt (VMware) <rostedt at goodmis.org> When running function tracing on a Linux guest running on VMware Workstation, the guest would crash. This is due to tracing of the sched_clock internal call of the VMware vmware_sched_clock(), which causes an infinite recursion within the tracing code (clock calls must not be traced). Make vmware_sched_clock() not traced by ftrace.

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified version of native_sched_clock() without ring buffer of mult/shift/offset triplets and preempt toggling. Since VMware hypervisor provides constant tsc we can use constant mult/shift/offset triplet calculated at boot time. no-vmw-sched-clock kernel parameter is added to switch back to the native_sched_clock() implementation.

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified version of native_sched_clock() without ring buffer of mult/shift/offset triplets and preempt toggling. Since VMware hypervisor provides constant tsc we can use constant mult/shift/offset triplet calculated at boot time. no-vmw-sched-clock kernel parameter is added to disable the paravirt sched clock. Signed-off-by: Alexey

On Tue, 25 Oct 2016, Alexey Makhalov wrote: > no-vmw-sched-clock kernel parameter is added to switch back to the > native_sched_clock() implementation. You are not switching back. The parameter is used to disable the paravirt sched clock. > #ifdef CONFIG_PARAVIRT > +static struct cyc2ns_data vmware_cyc2ns __ro_after_init; > + > +static int vmw_sched_clock __initdata = 1; >

I just spent half a day bisecting function tracing because I tripped over this again. I thought this was merged, but I guess it was missed again. Can someone please pull this in. And mark it for stable, it goes probably as far back as 2.6.32. Thanks! -- Steve On Wed, 25 May 2016 13:47:26 -0400 Steven Rostedt <rostedt at goodmis.org> wrote: > ?ukasz Daniluk reported that on a RHEL

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but

?ukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means

?ukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: H. Peter Anvin <hpa at linux.intel.com> commit 0e2e160033283e20f688d8bad5b89460cc5bfcc4 upstream. i386 and x86-64 uses different registers for arguments; make them available so we don't have to #ifdef in the actual code. Native size and specified size (q, l, w, b) versions are

This is a note to let you know that I've just added the patch titled x86/asm: Add _ASM_ARG* constants for argument registers to <asm/asm.h> to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-asm-add-_asm_arg-constants-for-argument-registers-to-asm-asm.h.patch and

This is a note to let you know that I've just added the patch titled compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: compiler-gcc.h-add-__attribute__-gnu_inline-to-all-inline-declarations.patch

This is a note to let you know that I've just added the patch titled x86/paravirt: Make native_save_fl() extern inline to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-paravirt-make-native_save_fl-extern-inline.patch and it can be found in the queue-4.14 subdirectory.