Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread libin
Thanks very much to Will and Steve for the wonderful comments, I will modify the commit message, and remove the misleading comments about module text disappearing case. Thanks again, Li Bin on 2015/12/3 23:31, Steven Rostedt wrote: > On Thu, 3 Dec 2015 15:09:26 + > Will Deacon wrote: > >>

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Steven Rostedt
On Thu, 3 Dec 2015 15:09:26 + Will Deacon wrote: > Yeah, I think the comments on x86 and arm64 are out of date. They also > mention the freeing of __init sections -- is that still a concern? No we black list them, any section that we are not sure will be there when we expect it to has

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Will Deacon
On Thu, Dec 03, 2015 at 10:05:25AM -0500, Steven Rostedt wrote: > On Thu, 3 Dec 2015 09:38:21 + > Will Deacon wrote: > > I think you're missing the case where the instruction changes under our > > feet after we've read it but before we've replaced it (e.g. due to module > > unloading). I

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Steven Rostedt
On Thu, 3 Dec 2015 11:48:24 + Will Deacon wrote: > Hmm, so this should all be fine if we exclusively use the probe_kernel_* > functions and handle the -EFAULT gracefully. Now, that leaves an > interesting scenario with the flush_icache_range call in > aarch64_insn_patch_text_nosync, since

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Steven Rostedt
On Thu, 3 Dec 2015 09:38:21 + Will Deacon wrote: > I think you're missing the case where the instruction changes under our > feet after we've read it but before we've replaced it (e.g. due to module > unloading). I think that's why ftrace_modify_code has the comment about > lack of locking

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Will Deacon
On Thu, Dec 03, 2015 at 05:39:56PM +0800, libin wrote: > on 2015/12/2 21:16, Will Deacon wrote: > > On Wed, Dec 02, 2015 at 12:36:54PM +, Will Deacon wrote: > >> On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > >>> On arm64, kstop_machine which is hugely disruptive to a running > >>>

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread libin
on 2015/12/2 21:16, Will Deacon wrote: > On Wed, Dec 02, 2015 at 12:36:54PM +, Will Deacon wrote: >> On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: >>> On arm64, kstop_machine which is hugely disruptive to a running >>> system is not needed to convert nops to ftrace calls or back,

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Will Deacon
On Thu, Dec 03, 2015 at 05:21:22PM +0800, libin wrote: > > on 2015/12/2 20:36, Will Deacon wrote: > > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > >> On arm64, kstop_machine which is hugely disruptive to a running > >> system is not needed to convert nops to ftrace calls or back, >

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread libin
on 2015/12/2 20:36, Will Deacon wrote: > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: >> On arm64, kstop_machine which is hugely disruptive to a running >> system is not needed to convert nops to ftrace calls or back, >> because that modifed code is a single 32bit instructions which >>

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Will Deacon
On Thu, Dec 03, 2015 at 05:39:56PM +0800, libin wrote: > on 2015/12/2 21:16, Will Deacon wrote: > > On Wed, Dec 02, 2015 at 12:36:54PM +, Will Deacon wrote: > >> On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > >>> On arm64, kstop_machine which is hugely disruptive to a running > >>>

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Will Deacon
On Thu, Dec 03, 2015 at 05:21:22PM +0800, libin wrote: > > on 2015/12/2 20:36, Will Deacon wrote: > > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > >> On arm64, kstop_machine which is hugely disruptive to a running > >> system is not needed to convert nops to ftrace calls or back, >

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread libin
on 2015/12/2 20:36, Will Deacon wrote: > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: >> On arm64, kstop_machine which is hugely disruptive to a running >> system is not needed to convert nops to ftrace calls or back, >> because that modifed code is a single 32bit instructions which >>

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread libin
on 2015/12/2 21:16, Will Deacon wrote: > On Wed, Dec 02, 2015 at 12:36:54PM +, Will Deacon wrote: >> On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: >>> On arm64, kstop_machine which is hugely disruptive to a running >>> system is not needed to convert nops to ftrace calls or back,

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Steven Rostedt
On Thu, 3 Dec 2015 15:09:26 + Will Deacon wrote: > Yeah, I think the comments on x86 and arm64 are out of date. They also > mention the freeing of __init sections -- is that still a concern? No we black list them, any section that we are not sure will be there when we

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Will Deacon
On Thu, Dec 03, 2015 at 10:05:25AM -0500, Steven Rostedt wrote: > On Thu, 3 Dec 2015 09:38:21 + > Will Deacon wrote: > > I think you're missing the case where the instruction changes under our > > feet after we've read it but before we've replaced it (e.g. due to module >

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Steven Rostedt
On Thu, 3 Dec 2015 09:38:21 + Will Deacon wrote: > I think you're missing the case where the instruction changes under our > feet after we've read it but before we've replaced it (e.g. due to module > unloading). I think that's why ftrace_modify_code has the comment

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread Steven Rostedt
On Thu, 3 Dec 2015 11:48:24 + Will Deacon wrote: > Hmm, so this should all be fine if we exclusively use the probe_kernel_* > functions and handle the -EFAULT gracefully. Now, that leaves an > interesting scenario with the flush_icache_range call in >

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-03 Thread libin
Thanks very much to Will and Steve for the wonderful comments, I will modify the commit message, and remove the misleading comments about module text disappearing case. Thanks again, Li Bin on 2015/12/3 23:31, Steven Rostedt wrote: > On Thu, 3 Dec 2015 15:09:26 + > Will Deacon

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-02 Thread Steven Rostedt
On Wed, 2 Dec 2015 12:36:55 + Will Deacon wrote: > > Cc: # 3.18+ > > I don't think this is stable material. > No, it definitely isn't. This is a new feature not a fix. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-02 Thread Will Deacon
On Wed, Dec 02, 2015 at 12:36:54PM +, Will Deacon wrote: > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > > On arm64, kstop_machine which is hugely disruptive to a running > > system is not needed to convert nops to ftrace calls or back, > > because that modifed code is a single

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-02 Thread Will Deacon
On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > On arm64, kstop_machine which is hugely disruptive to a running > system is not needed to convert nops to ftrace calls or back, > because that modifed code is a single 32bit instructions which > is impossible to cross cache (or page)

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-02 Thread Will Deacon
On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > On arm64, kstop_machine which is hugely disruptive to a running > system is not needed to convert nops to ftrace calls or back, > because that modifed code is a single 32bit instructions which > is impossible to cross cache (or page)

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-02 Thread Will Deacon
On Wed, Dec 02, 2015 at 12:36:54PM +, Will Deacon wrote: > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: > > On arm64, kstop_machine which is hugely disruptive to a running > > system is not needed to convert nops to ftrace calls or back, > > because that modifed code is a single

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-12-02 Thread Steven Rostedt
On Wed, 2 Dec 2015 12:36:55 + Will Deacon wrote: > > Cc: # 3.18+ > > I don't think this is stable material. > No, it definitely isn't. This is a new feature not a fix. -- Steve -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-11-29 Thread libin
on 2015/11/28 23:58, Steven Rostedt wrote: > On Sat, 28 Nov 2015 15:50:09 +0800 > Li Bin wrote: > >> On arm64, kstop_machine which is hugely disruptive to a running >> system is not needed to convert nops to ftrace calls or back, >> because that modifed code is a single 32bit instructions which

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-11-29 Thread libin
on 2015/11/28 23:58, Steven Rostedt wrote: > On Sat, 28 Nov 2015 15:50:09 +0800 > Li Bin wrote: > >> On arm64, kstop_machine which is hugely disruptive to a running >> system is not needed to convert nops to ftrace calls or back, >> because that modifed code is a single

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-11-28 Thread Steven Rostedt
On Sat, 28 Nov 2015 15:50:09 +0800 Li Bin wrote: > On arm64, kstop_machine which is hugely disruptive to a running > system is not needed to convert nops to ftrace calls or back, > because that modifed code is a single 32bit instructions which > is impossible to cross cache (or page) boundaries,

Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-11-28 Thread Steven Rostedt
On Sat, 28 Nov 2015 15:50:09 +0800 Li Bin wrote: > On arm64, kstop_machine which is hugely disruptive to a running > system is not needed to convert nops to ftrace calls or back, > because that modifed code is a single 32bit instructions which > is impossible to cross

[PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-11-27 Thread Li Bin
On arm64, kstop_machine which is hugely disruptive to a running system is not needed to convert nops to ftrace calls or back, because that modifed code is a single 32bit instructions which is impossible to cross cache (or page) boundaries, and the used str instruction is single-copy atomic. Cc:

[PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing

2015-11-27 Thread Li Bin
On arm64, kstop_machine which is hugely disruptive to a running system is not needed to convert nops to ftrace calls or back, because that modifed code is a single 32bit instructions which is impossible to cross cache (or page) boundaries, and the used str instruction is single-copy atomic. Cc: