On Wed, 21 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 21:44:41, Hugh Dickins wrote:
> [...]
> > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> >
> > We have all assumed that it is essential to hold a page reference while
> > waiting on a page lock: partly to guarantee
On Wed, 21 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 21:44:41, Hugh Dickins wrote:
> [...]
> > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> >
> > We have all assumed that it is essential to hold a page reference while
> > waiting on a page lock: partly to guarantee
On 2018/11/21 21:11, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 21, 2018 at 07:45:28AM +, Song Liu escreveu:
>> Hi,
>>
>> I found perf-record --tail-synthesize without --overwrite breaks symbols
>> for perf-script, perf-report, etc. For example:
>>
>> [root@]# ~/perf record -ag
On 2018/11/21 21:11, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 21, 2018 at 07:45:28AM +, Song Liu escreveu:
>> Hi,
>>
>> I found perf-record --tail-synthesize without --overwrite breaks symbols
>> for perf-script, perf-report, etc. For example:
>>
>> [root@]# ~/perf record -ag
Gentle Ping...
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年11月6日 13:16
> To: daniel.lezc...@linaro.org; t...@linutronix.de;
> linux-kernel@vger.kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] clocksource/drivers/timer-imx-tpm: convert the driver to
>
Gentle Ping...
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年11月6日 13:16
> To: daniel.lezc...@linaro.org; t...@linutronix.de;
> linux-kernel@vger.kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] clocksource/drivers/timer-imx-tpm: convert the driver to
>
Hi Palmer,
On Thu, Nov 22, 2018 at 12:28 AM Palmer Dabbelt wrote:
>
> On Tue, 20 Nov 2018 21:06:18 PST (-0800), bmeng...@gmail.com wrote:
> > On Mon, Nov 12, 2018 at 1:55 PM Anup Patel wrote:
> >>
> >> This patch extends Linux RISC-V build system to build and install:
> >> Image - Flat
Hi Palmer,
On Thu, Nov 22, 2018 at 12:28 AM Palmer Dabbelt wrote:
>
> On Tue, 20 Nov 2018 21:06:18 PST (-0800), bmeng...@gmail.com wrote:
> > On Mon, Nov 12, 2018 at 1:55 PM Anup Patel wrote:
> >>
> >> This patch extends Linux RISC-V build system to build and install:
> >> Image - Flat
On 2018/11/21 17:53, Peter Zijlstra wrote:
> On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
Also; you were going to shop around with the other architectures to see
what they want/need for this interface. I
On 2018/11/21 17:53, Peter Zijlstra wrote:
> On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
Also; you were going to shop around with the other architectures to see
what they want/need for this interface. I
On 11/21/2018 12:14 PM, Thomas Gleixner wrote:
> + * is immediately scheduled back and the thread inbetween
s/inbetween/in between
Tim
On 11/21/2018 12:14 PM, Thomas Gleixner wrote:
> + * is immediately scheduled back and the thread inbetween
s/inbetween/in between
Tim
On Wed, 21 Nov 2018 17:09:50 -0800 Enke Chen wrote:
> Hi, Andrew:
>
> On 11/21/18 4:37 PM, Andrew Morton wrote:
> > On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
> >
> >> On 10/29, Enke Chen wrote:
> >>>
> >>> Reviewed-by: Oleg Nesterov
> >>
> >> Hmm. I didn't say this ;)
> >>
> >>
On Wed, 21 Nov 2018 17:09:50 -0800 Enke Chen wrote:
> Hi, Andrew:
>
> On 11/21/18 4:37 PM, Andrew Morton wrote:
> > On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
> >
> >> On 10/29, Enke Chen wrote:
> >>>
> >>> Reviewed-by: Oleg Nesterov
> >>
> >> Hmm. I didn't say this ;)
> >>
> >>
On 11/21/18 5:07 PM, Paul Walmsley wrote:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
Herring .
Cc: Rob Herring
Cc: Palmer Dabbelt
Cc: Megan Wachs
Cc:
On 11/21/18 5:07 PM, Paul Walmsley wrote:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
Herring .
Cc: Rob Herring
Cc: Palmer Dabbelt
Cc: Megan Wachs
Cc:
From: "Steven Rostedt (VMware)"
The curr_ret_stack is no longer set to -1 when not tracing a function. It is
now done differently, and the FTRACE_NOTRACE_DEPTH value is no longer used.
Remove the reference to it.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
From: "Steven Rostedt (VMware)"
The curr_ret_stack is no longer set to -1 when not tracing a function. It is
now done differently, and the FTRACE_NOTRACE_DEPTH value is no longer used.
Remove the reference to it.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
On Wed, 21 Nov 2018 17:08:08 -0800 Daniel Colascione wrote:
> Have you done much
> retrospective long trace analysis?
No. Have you?
Of course you have, which is why I and others are dependent upon you to
explain why this change is worth adding to Linux. If this thing solves
a problem which
From: "Steven Rostedt (VMware)"
Move the function function_graph_get_addr() to fgraph.c, as the management
of the curr_ret_stack is going to change, and all the accesses to ret_stack
needs to be done in fgraph.c.
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/fgraph.c
On Wed, 21 Nov 2018 17:08:08 -0800 Daniel Colascione wrote:
> Have you done much
> retrospective long trace analysis?
No. Have you?
Of course you have, which is why I and others are dependent upon you to
explain why this change is worth adding to Linux. If this thing solves
a problem which
From: "Steven Rostedt (VMware)"
Move the function function_graph_get_addr() to fgraph.c, as the management
of the curr_ret_stack is going to change, and all the accesses to ret_stack
needs to be done in fgraph.c.
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/fgraph.c
From: "Steven Rostedt (VMware)"
In order to move function graph infrastructure into its own file (fgraph.h)
it needs to access various functions and variables in ftrace.c that are
currently static. Create a new file called ftrace-internal.h that holds the
function prototypes and the extern
From: "Steven Rostedt (VMware)"
The ret_stack processing is going to change, and that is going
to break anything that is accessing the ret_stack directly. One user is the
function graph profiler. By using the ftrace_graph_get_ret_stack() helper
function, the profiler can access the ret_stack
From: "Steven Rostedt (VMware)"
In order to move function graph infrastructure into its own file (fgraph.h)
it needs to access various functions and variables in ftrace.c that are
currently static. Create a new file called ftrace-internal.h that holds the
function prototypes and the extern
From: "Steven Rostedt (VMware)"
The ret_stack processing is going to change, and that is going
to break anything that is accessing the ret_stack directly. One user is the
function graph profiler. By using the ftrace_graph_get_ret_stack() helper
function, the profiler can access the ret_stack
From: "Steven Rostedt (VMware)"
In order to make the function graph infrastructure more generic, there can
not be code specific for the function_graph tracer in the generic code. This
includes the set_graph_notrace logic, that stops all graph calls when a
function in the set_graph_notrace is
From: "Steven Rostedt (VMware)"
In order to make the function graph infrastructure more generic, there can
not be code specific for the function_graph tracer in the generic code. This
includes the set_graph_notrace logic, that stops all graph calls when a
function in the set_graph_notrace is
From: "Steven Rostedt (VMware)"
The curr_ret_stack is no longer set to a negative value when a function is
not to be traced by the function graph tracer. Remove the usage of
FTRACE_NOTRACE_DEPTH, as it is no longer needed.
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h
From: "Steven Rostedt (VMware)"
Allow for multiple users to attach to function graph tracer at the same
time. Only 16 simultaneous users can attach to the tracer. This is because
there's an array that stores the pointers to the attached fgraph_ops. When a
a function being traced is entered, each
From: "Steven Rostedt (VMware)"
The curr_ret_stack is no longer set to a negative value when a function is
not to be traced by the function graph tracer. Remove the usage of
FTRACE_NOTRACE_DEPTH, as it is no longer needed.
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h
From: "Steven Rostedt (VMware)"
Allow for multiple users to attach to function graph tracer at the same
time. Only 16 simultaneous users can attach to the tracer. This is because
there's an array that stores the pointers to the attached fgraph_ops. When a
a function being traced is entered, each
From: "Steven Rostedt (VMware)"
The static inline function task_curr_ret_stack() is unused, remove it.
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index
From: "Steven Rostedt (VMware)"
To make the function graph infrastructure more managable, the code needs to
be in its own file (fgraph.c). Move the code that is specific for managing
the function graph infrastructure out of ftrace.c and into fgraph.c
Signed-off-by: Steven Rostedt (VMware)
---
From: "Steven Rostedt (VMware)"
In order to make it possible to have multiple callbacks registered with the
function_graph tracer, the retstack needs to be converted from an array of
ftrace_ret_stack structures to an array of longs. This will allow to store
the list of callbacks on the stack for
From: "Steven Rostedt (VMware)"
As the function graph infrastructure can be used by thing other than
tracing, moving the code to its own file out of the trace_functions_graph.c
code makes more sense.
The fgraph.c file will only contain the infrastructure required to hook into
functions and
From: "Steven Rostedt (VMware)"
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/fgraph.c | 50 +++
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
index 6e5efe1663b9..8a99eaa46b43
From: "Steven Rostedt (VMware)"
In order to make it possible to have multiple callbacks registered with the
function_graph tracer, the retstack needs to be converted from an array of
ftrace_ret_stack structures to an array of longs. This will allow to store
the list of callbacks on the stack for
From: "Steven Rostedt (VMware)"
As the function graph infrastructure can be used by thing other than
tracing, moving the code to its own file out of the trace_functions_graph.c
code makes more sense.
The fgraph.c file will only contain the infrastructure required to hook into
functions and
From: "Steven Rostedt (VMware)"
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/fgraph.c | 50 +++
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
index 6e5efe1663b9..8a99eaa46b43
From: "Steven Rostedt (VMware)"
The static inline function task_curr_ret_stack() is unused, remove it.
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index
From: "Steven Rostedt (VMware)"
To make the function graph infrastructure more managable, the code needs to
be in its own file (fgraph.c). Move the code that is specific for managing
the function graph infrastructure out of ftrace.c and into fgraph.c
Signed-off-by: Steven Rostedt (VMware)
---
I talked with many of you at Plumbers about rewriting the function graph
tracer. Well, this is it. I was originally going to produce just a
proof of concept, but when I found that I had to fix a design flaw
and that covered all the arch code anyway, I decided to do more of a
RFC patch set.
I
I talked with many of you at Plumbers about rewriting the function graph
tracer. Well, this is it. I was originally going to produce just a
proof of concept, but when I found that I had to fix a design flaw
and that covered all the arch code anyway, I decided to do more of a
RFC patch set.
I
From: "Steven Rostedt (VMware)"
Currently the registering of function graph is to pass in a entry and return
function. We need to have a way to associate those functions together where
the entry can determine to run the return hook. Having a structure that
contains both functions will facilitate
From: "Steven Rostedt (VMware)"
Currently the registering of function graph is to pass in a entry and return
function. We need to have a way to associate those functions together where
the entry can determine to run the return hook. Having a structure that
contains both functions will facilitate
From: "Steven Rostedt (VMware)"
Add an array structure that will eventually allow the function graph tracer
to have up to 16 simultaneous callbacks attached. It's an array of 16
fgraph_ops pointers, that is assigned when one is registered. On entry of a
function the entry of the first item in
Hi AIsheng,
> -Original Message-
> From: Aisheng DONG
> Sent: 2018年11月21日 21:02
> To: Joakim Zhang ; linux-...@vger.kernel.org;
> m...@pengutronix.de
> Cc: w...@grandegger.com; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: RE: [PATCH V4 1/1] can: flexcan: add self wakeup
From: "Steven Rostedt (VMware)"
Add an array structure that will eventually allow the function graph tracer
to have up to 16 simultaneous callbacks attached. It's an array of 16
fgraph_ops pointers, that is assigned when one is registered. On entry of a
function the entry of the first item in
Hi AIsheng,
> -Original Message-
> From: Aisheng DONG
> Sent: 2018年11月21日 21:02
> To: Joakim Zhang ; linux-...@vger.kernel.org;
> m...@pengutronix.de
> Cc: w...@grandegger.com; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: RE: [PATCH V4 1/1] can: flexcan: add self wakeup
On 11/21/2018 12:14 PM, Thomas Gleixner wrote:
> + * Avoid __switch_to_xtra() invocation when conditional stpib is
s/stpib/stibp
Tim
On 11/21/2018 12:14 PM, Thomas Gleixner wrote:
> + * Avoid __switch_to_xtra() invocation when conditional stpib is
s/stpib/stibp
Tim
Hi Aisheng,
> -Original Message-
> From: Aisheng DONG
> Sent: 2018年11月21日 21:00
> To: Joakim Zhang ; linux-...@vger.kernel.org;
> m...@pengutronix.de
> Cc: w...@grandegger.com; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: RE: [PATCH V4 1/1] can: flexcan: add self wakeup
Hi Aisheng,
> -Original Message-
> From: Aisheng DONG
> Sent: 2018年11月21日 21:00
> To: Joakim Zhang ; linux-...@vger.kernel.org;
> m...@pengutronix.de
> Cc: w...@grandegger.com; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: RE: [PATCH V4 1/1] can: flexcan: add self wakeup
Hi, Andrew:
On 11/21/18 5:09 PM, Enke Chen wrote:
> Hi, Andrew:
>
> On 11/21/18 4:37 PM, Andrew Morton wrote:
>> Do we have other linux-specific signal extensions which could piggyback onto
>> that?
>
> No. There are enough existing signals that an application can choose for this
> purpose,
Hi, Andrew:
On 11/21/18 5:09 PM, Enke Chen wrote:
> Hi, Andrew:
>
> On 11/21/18 4:37 PM, Andrew Morton wrote:
>> Do we have other linux-specific signal extensions which could piggyback onto
>> that?
>
> No. There are enough existing signals that an application can choose for this
> purpose,
Hi, Andrew:
On 11/21/18 4:37 PM, Andrew Morton wrote:
> On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
>
>> On 10/29, Enke Chen wrote:
>>>
>>> Reviewed-by: Oleg Nesterov
>>
>> Hmm. I didn't say this ;)
>>
>> But OK, feel free to keep this tag.
>>
>> I do not like this feauture.
>
>
On Wed, Nov 21, 2018 at 05:08:11PM +0100, Christoph Hellwig wrote:
> On Wed, Nov 21, 2018 at 11:06:11PM +0800, Ming Lei wrote:
> > bvec_iter_* is used for single-page bvec in current linus tree, and there
> > are
> > lots of users now:
> >
> > [linux]$ git grep -n "bvec_iter_*" ./ | wc
> >
Hi, Andrew:
On 11/21/18 4:37 PM, Andrew Morton wrote:
> On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
>
>> On 10/29, Enke Chen wrote:
>>>
>>> Reviewed-by: Oleg Nesterov
>>
>> Hmm. I didn't say this ;)
>>
>> But OK, feel free to keep this tag.
>>
>> I do not like this feauture.
>
>
On Wed, Nov 21, 2018 at 05:08:11PM +0100, Christoph Hellwig wrote:
> On Wed, Nov 21, 2018 at 11:06:11PM +0800, Ming Lei wrote:
> > bvec_iter_* is used for single-page bvec in current linus tree, and there
> > are
> > lots of users now:
> >
> > [linux]$ git grep -n "bvec_iter_*" ./ | wc
> >
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
Herring .
Cc: Rob Herring
Cc: Palmer Dabbelt
Cc: Megan Wachs
Cc: Wesley Terpstra
Cc: Mark Rutland
Cc:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
Herring .
Cc: Rob Herring
Cc: Palmer Dabbelt
Cc: Megan Wachs
Cc: Wesley Terpstra
Cc: Mark Rutland
Cc:
Hi Gustavo,
Thanks a lot for your testing and ACK!
Regards,
Zhiqiang
> -Original Message-
> From: Gustavo Pimentel
> Sent: 2018年11月22日 1:37
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com;
> lorenzo.pieral...@arm.com;
Hi Gustavo,
Thanks a lot for your testing and ACK!
Regards,
Zhiqiang
> -Original Message-
> From: Gustavo Pimentel
> Sent: 2018年11月22日 1:37
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com;
> lorenzo.pieral...@arm.com;
On Thu, Nov 22, 2018 at 3:23 AM Florian Fainelli wrote:
>
>
>
> On 11/21/2018 4:43 AM, Yangtao Li wrote:
> > of_find_node_by_path() acquires a reference to the node returned
> > by it and that reference needs to be dropped by its caller.
> > bl_idle_init() doesn't do that, so fix it.
>
> You
On Thu, Nov 22, 2018 at 3:23 AM Florian Fainelli wrote:
>
>
>
> On 11/21/2018 4:43 AM, Yangtao Li wrote:
> > of_find_node_by_path() acquires a reference to the node returned
> > by it and that reference needs to be dropped by its caller.
> > bl_idle_init() doesn't do that, so fix it.
>
> You
The memory chunk allocated by hid_allocate_device() should be released
by hid_destroy_device(), not kfree().
Fixes: 0b28cb4bcb1("HID: intel-ish-hid: ISH HID client driver")
Signed-off-by: Pan Bian
---
drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The memory chunk allocated by hid_allocate_device() should be released
by hid_destroy_device(), not kfree().
Fixes: 0b28cb4bcb1("HID: intel-ish-hid: ISH HID client driver")
Signed-off-by: Pan Bian
---
drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
> On 10/29, Enke Chen wrote:
> >
> > Reviewed-by: Oleg Nesterov
>
> Hmm. I didn't say this ;)
>
> But OK, feel free to keep this tag.
>
> I do not like this feauture.
Why is that?
> But I see no technical problems in this version
>
On Wed, 21 Nov 2018, Yu Zhao wrote:
> We changed key of swap cache tree from swp_entry_t.val to
> swp_offset. Need to do so in shmem_replace_page() as well.
>
> Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap
> cache")
> Cc: sta...@vger.kernel.org # v4.9+
>
On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
> On 10/29, Enke Chen wrote:
> >
> > Reviewed-by: Oleg Nesterov
>
> Hmm. I didn't say this ;)
>
> But OK, feel free to keep this tag.
>
> I do not like this feauture.
Why is that?
> But I see no technical problems in this version
>
On Wed, 21 Nov 2018, Yu Zhao wrote:
> We changed key of swap cache tree from swp_entry_t.val to
> swp_offset. Need to do so in shmem_replace_page() as well.
>
> Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap
> cache")
> Cc: sta...@vger.kernel.org # v4.9+
>
On Tue, Nov 20, 2018 at 07:18:13PM -0800, Wengang Wang wrote:
>Hi Wei,
>
>I think you will receive my reply to Zhong, But I am copying my comments for
>that patch here (again):
>
>Copy starts ==>
>
>I am not sure if the patch you mentioned intended to fix the problem here.
>With that patch the
On Tue, Nov 20, 2018 at 07:18:13PM -0800, Wengang Wang wrote:
>Hi Wei,
>
>I think you will receive my reply to Zhong, But I am copying my comments for
>that patch here (again):
>
>Copy starts ==>
>
>I am not sure if the patch you mentioned intended to fix the problem here.
>With that patch the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have superh use the new code, and remove the
From: "Steven Rostedt (VMware)"
Currently all the architectures do basically the same thing in preparing the
function graph tracer on entry to a function. This code can be pulled into a
generic location and then this will allow the function graph tracer to be
fixed, as well as extended.
Create
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have x86 use the new code, and remove the shadow
From: "Steven Rostedt (VMware)"
As all architectures now call function_graph_enter() to do the entry work,
no architecture should ever call ftrace_push_return_trace(). Make it static.
This is needed to prepare for a fix of a design bug on how the curr_ret_stack
is used.
Cc: sta...@kernel.org
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have s390 use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have superh use the new code, and remove the
From: "Steven Rostedt (VMware)"
Currently all the architectures do basically the same thing in preparing the
function graph tracer on entry to a function. This code can be pulled into a
generic location and then this will allow the function graph tracer to be
fixed, as well as extended.
Create
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have x86 use the new code, and remove the shadow
From: "Steven Rostedt (VMware)"
As all architectures now call function_graph_enter() to do the entry work,
no architecture should ever call ftrace_push_return_trace(). Make it static.
This is needed to prepare for a fix of a design bug on how the curr_ret_stack
is used.
Cc: sta...@kernel.org
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have s390 use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have sparc use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have microblaze use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have sparc use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have microblaze use the new code, and remove the
From: "Steven Rostedt (VMware)"
The profiler uses trace->depth to find its entry on the ret_stack, but the
depth may not match the actual location of where its entry is (if an
interrupt were to preempt the processing of the profiler for another
function, the depth and the curr_ret_stack will be
From: "Steven Rostedt (VMware)"
The profiler uses trace->depth to find its entry on the ret_stack, but the
depth may not match the actual location of where its entry is (if an
interrupt were to preempt the processing of the profiler for another
function, the depth and the curr_ret_stack will be
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have MIPS use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have MIPS use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function graph profiler uses the ret_stack to store the "subtime" and
reuse it by nested functions and also on the return. But the current logic
has the profiler callback called before the ret_stack is updated, and it is
just modifying the ret_stack that will
From: "Steven Rostedt (VMware)"
Currently, the depth of the ret_stack is determined by curr_ret_stack index.
The issue is that there's a race between setting of the curr_ret_stack and
calling of the callback attached to the return of the function.
Commit 03274a3ffb44 ("tracing/fgraph: Adjust
From: "Steven Rostedt (VMware)"
The function graph profiler uses the ret_stack to store the "subtime" and
reuse it by nested functions and also on the return. But the current logic
has the profiler callback called before the ret_stack is updated, and it is
just modifying the ret_stack that will
From: "Steven Rostedt (VMware)"
Currently, the depth of the ret_stack is determined by curr_ret_stack index.
The issue is that there's a race between setting of the curr_ret_stack and
calling of the callback attached to the return of the function.
Commit 03274a3ffb44 ("tracing/fgraph: Adjust
From: "Steven Rostedt (VMware)"
In the past, curr_ret_stack had two functions. One was to denote the depth
of the call graph, the other is to keep track of where on the ret_stack the
data is used. Although they may be slightly related, there are two cases
where they need to be used differently.
From: "Steven Rostedt (VMware)"
In the past, curr_ret_stack had two functions. One was to denote the depth
of the call graph, the other is to keep track of where on the ret_stack the
data is used. Although they may be slightly related, there are two cases
where they need to be used differently.
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have parisc use the new code, and remove the
From: "Steven Rostedt (VMware)"
The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().
Have ARM use the new code, and remove the shadow
401 - 500 of 1818 matches
Mail list logo
