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:
>
>>
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
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
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
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
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
> >>>
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,
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,
>
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
>>
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
> >>>
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,
>
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
>>
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,
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
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
>
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
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
>
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
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
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
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)
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)
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
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
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
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
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,
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
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:
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:
30 matches
Mail list logo