[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191007080527.GA2311@hirez.programming.kicks-ass.net>
Date: Mon, 7 Oct 2019 10:05:27 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Nadav Amit <nadav.amit@...il.com>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Song Liu <songliubraving@...com>,
Steven Rostedt <rostedt@...dmis.org>,
Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [PATCH 1/3] x86/alternatives: Teach text_poke_bp() to emulate
instructions
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 <peterz@...radead.org> wrote:
> > > I'm halfway through a patch introducing:
> > >
> > > union text_poke_insn {
> > > u8 code[POKE_MAX_OPCODE_SUZE];
> > > struct {
> > > u8 opcode;
> > > s32 disp;
> > > } __attribute__((packed));
> > > };
> > >
> > > to text-patching.h to unify all such custom unions we have all over the
> > > place. I'll mob up the above in that.
>
> I think it is good to unify such unions, but I meant above was, it was
> also important to unify the opcode macro. Since poke_int3_handler()
> clasifies the opcode by your *_INSN_OPCODE macro, it is natual to use
> those opcode for text_poke_bp() interface.
Right, but I think we should do that as another patch, there's a lot of
instances in that file and just changing one or two over is 'weird'.
I can put it on the todo to fix that all up.
Powered by blists - more mailing lists