On Wed, Oct 09, 2019 at 10:26:35AM -0400, Mathieu Desnoyers wrote:
> Yes, I think you are right on both counts. synchronize_rcu() is not enough
> to guarantee that other cores have observed the required core serializing
> instructions.
*phew*, not crazy then ;-)
> I would also be more comfortabl
+ hpa, paulmck
- On Oct 9, 2019, at 9:07 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Fri, Oct 04, 2019 at 10:45:40PM +0900, Masami Hiramatsu wrote:
>
>> > > > > text_poke_bp(op->kp.addr, insn_buff, RELATIVEJUMP_SIZE,
>> > > > > - op->optinsn.insn);
>> > > > > +
On Wed, Oct 09, 2019 at 03:26:39PM +0200, Peter Zijlstra wrote:
> So I suppose I'm suggesting we do something like the below on top of
> what I already have here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/ftrace
>
> All it needs are a few comments ;-) Also note how
On Wed, Oct 09, 2019 at 03:07:54PM +0200, Peter Zijlstra wrote:
> So from what I can tell of kernel/kprobes.c, what it does is something like:
>
> ARM: (__arm_kprobe)
> text_poke(INT3)
> /* guarantees nothing, INT3 will become visible at some point, maybe */
>
> (kprobe_optimizer
On Fri, Oct 04, 2019 at 10:45:40PM +0900, Masami Hiramatsu wrote:
> > > > > text_poke_bp(op->kp.addr, insn_buff, RELATIVEJUMP_SIZE,
> > > > > - op->optinsn.insn);
> > > > > + emulate_buff);
> > > > > }
> > >
> > > As argued in a previous thread, text_poke_
On Fri, Oct 04, 2019 at 10:45:40PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
>
> On Thu, 3 Oct 2019 13:01:06 +0200
> Peter Zijlstra wrote:
> > > I'm halfway through a patch introducing:
> > >
> > > union text_poke_insn {
> > > u8 code[POKE_MAX_OPCODE_SUZE];
> > > struct {
> > >
Hi Peter,
On Thu, 3 Oct 2019 13:01:06 +0200
Peter Zijlstra wrote:
> On Thu, Oct 03, 2019 at 10:27:51AM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 03, 2019 at 02:00:50PM +0900, Masami Hiramatsu wrote:
> >
> > > > This fits almost all text_poke_bp() users, except
> > > > arch_unoptimize_kprobe(
On Thu, Oct 03, 2019 at 10:27:51AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 03, 2019 at 02:00:50PM +0900, Masami Hiramatsu wrote:
>
> > > This fits almost all text_poke_bp() users, except
> > > arch_unoptimize_kprobe() which restores random text, and for that site
> > > we have to build an expli
On Thu, Oct 03, 2019 at 01:01:06PM +0200, Peter Zijlstra wrote:
> Also, I think text_poke_bp(INT3) is broken, although I don't think
> anybody actually does that. Still, let me fix that.
Something like so should allow text_poke_bp(INT3) to work as expected.
---
--- a/arch/x86/kernel/alternative.c
On Thu, Oct 03, 2019 at 10:27:51AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 03, 2019 at 02:00:50PM +0900, Masami Hiramatsu wrote:
>
> > > This fits almost all text_poke_bp() users, except
> > > arch_unoptimize_kprobe() which restores random text, and for that site
> > > we have to build an expli
On Thu, Oct 03, 2019 at 02:00:50PM +0900, Masami Hiramatsu wrote:
> > This fits almost all text_poke_bp() users, except
> > arch_unoptimize_kprobe() which restores random text, and for that site
> > we have to build an explicit emulate instruction.
>
> OK, and in this case, I would like to change
Hi Peter,
On Tue, 27 Aug 2019 20:06:23 +0200
Peter Zijlstra wrote:
> In preparation for static_call and variable size jump_label support,
> teach text_poke_bp() to emulate instructions, namely:
>
> JMP32, JMP8, CALL, NOP2, NOP_ATOMIC5
>
> The current text_poke_bp() takes a @handler argument
In preparation for static_call and variable size jump_label support,
teach text_poke_bp() to emulate instructions, namely:
JMP32, JMP8, CALL, NOP2, NOP_ATOMIC5
The current text_poke_bp() takes a @handler argument which is used as
a jump target when the temporary INT3 is hit by a different CPU.
In preparation for static_call and variable size jump_label support,
teach text_poke_bp() to emulate instructions, namely:
JMP32, JMP8, CALL, NOP2, NOP_ATOMIC5
The current text_poke_bp() takes a @handler argument which is used as
a jump target when the temporary INT3 is hit by a different CPU.
14 matches
Mail list logo
