Re: [PATCH v3 4/8] x86: speed up int3-based patching using direct write

2013-11-14 Thread Masami Hiramatsu
(2013/11/14 21:46), Petr Mladek wrote: > Masami Hiramatsu píše v Čt 14. 11. 2013 v 20:36 +0900: >> (2013/11/14 19:41), Petr Mladek wrote: >>> @@ -837,7 +882,7 @@ static void recover_iter(struct text_poke_bp_iter >>> *iterator, >>> } >>> >>> /* Finally, put back the first byte from the ol

Re: [PATCH v3 4/8] x86: speed up int3-based patching using direct write

2013-11-14 Thread Petr Mladek
Masami Hiramatsu píše v Čt 14. 11. 2013 v 20:36 +0900: > (2013/11/14 19:41), Petr Mladek wrote: > > @@ -837,7 +882,7 @@ static void recover_iter(struct text_poke_bp_iter > > *iterator, > > } > > > > /* Finally, put back the first byte from the old code */ > > - err = text_poke(addr, ol

Re: [PATCH v3 4/8] x86: speed up int3-based patching using direct write

2013-11-14 Thread Masami Hiramatsu
(2013/11/14 19:41), Petr Mladek wrote: > @@ -837,7 +882,7 @@ static void recover_iter(struct text_poke_bp_iter > *iterator, > } > > /* Finally, put back the first byte from the old code */ > - err = text_poke(addr, old_opcode, sizeof(bp_int3)); > + err = text_poke_part(addr,

[PATCH v3 4/8] x86: speed up int3-based patching using direct write

2013-11-14 Thread Petr Mladek
When trying to use text_poke_bp_iter in ftrace, the result was slower than the original implementation. It turned out that one difference was in text_poke vs. ftrace_write. text_poke did many extra operations to make sure that code was read-write and the change was atomic. In fact, we do not need