[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140403163304.GB4882@linux.vnet.ibm.com>
Date: Thu, 3 Apr 2014 22:03:04 +0530
From: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
David Long <dave.long@...aro.org>,
Denys Vlasenko <dvlasenk@...hat.com>,
"Frank Ch. Eigler" <fche@...hat.com>,
Jim Keniston <jkenisto@...ibm.com>,
Jonathan Lebon <jlebon@...hat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] uprobes/x86: Fold prepare_fixups() into
arch_uprobe_analyze_insn()
* Oleg Nesterov <oleg@...hat.com> [2014-03-31 21:43:59]:
> No functional changes, preparation.
>
> Shift the code from prepare_fixups() to arch_uprobe_analyze_insn()
> with the following modifications:
>
> - Do not call insn_get_opcode() again, it was already called
> by validate_insn_bits().
>
> - Move "case 0xea" up. This way "case 0xff" can fall through
> to default case.
>
> - change "case 0xff" to use the nested "switch (MODRM_REG)",
> this way the code looks a bit simpler.
>
> - Make the comments look consistent.
>
> While at it, kill the initialization of rip_rela_target_address and
> ->fixups, we can rely on kzalloc(). We will add the new members into
> arch_uprobe, it would be better to assume that everything is zero by
> default.
>
> TODO: cleanup/fix the mess in validate_insn_bits() paths:
>
> - validate_insn_64bits() and validate_insn_32bits() should be
> unified.
>
> - "ifdef" is not used consistently; if good_insns_64 depends
> on CONFIG_X86_64, then probably good_insns_32 should depend
> on CONFIG_X86_32/EMULATION
>
> - the usage of mm->context.ia32_compat looks wrong if the task
> is TIF_X32.
>
> Signed-off-by: Oleg Nesterov <oleg@...hat.com>
Acked-by: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists