From: Maciej Slodczyk <m.slodczyk2@partner.samsung.com>
To: Julien Thierry <julien.thierry@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: linux@armlinux.org.uk, oleg@redhat.com, catalin.marinas@arm.com,
will.deacon@arm.com, peterz@infradead.org, mingo@redhat.com,
acme@kernel.org, alexander.shishkin@linux.intel.com,
jolsa@redhat.com, namhyung@kernel.org, b.zolnierkie@samsung.com,
m.szyprowski@samsung.com, k.lewandowsk@samsung.com
Subject: Re: [PATCH v2 5/7] arm64: make arm uprobes code reusable by arm64
Date: Mon, 1 Oct 2018 15:28:51 +0200 [thread overview]
Message-ID: <20181001132852eucas1p25ab2ddf39296e2c78b188234d168f814~ZfyJK4W4N0481804818eucas1p2j@eucas1p2.samsung.com> (raw)
In-Reply-To: <9abe9091-f305-a446-c93f-6418d35a7dee@arm.com>
Hi,
Thank you for the review.
> I think that it would be good to move the renaming changes out of this
> patch.
>
So, as I understand, you suggest separating renaming from moving and
putting it in separate patches, right?
>> })
>> +#define ARM_COMPAT_LR_OFFSET 0
>
> Not sure this should be defined here. What's the meaning of compat for
> arch/arm ?
>
Sure, I agree that the name is not very fortunate. I'll change it to
something like ARM_UPROBES_BRANCH_LR_OFFSET.
>> @@ -39,7 +39,7 @@ struct arch_uprobe {
>> void (*posthandler)(struct arch_uprobe *auprobe,
>> struct arch_uprobe_task *autask,
>> struct pt_regs *regs);
>> - struct arch_probes_insn asi;
>> + struct arch_probes_insn api;
>
> It would be easier to follow thing by making this change in its own
> patch. (Probably before you move arm32 code to lib/probes)
>
Yup.
>> +enum probes_insn {
>> + INSN_REJECTED,
>> + INSN_GOOD_NO_SLOT,
>> + INSN_GOOD,
>> +};
>
> Why have two definitions of this enum rather than a common one in
> lib/probes?
>
Will fix in v3.
>> -typedef void (probes_handler_t) (u32 opcode,
>> - struct arch_probe_insn *api,
>> +typedef void (probes_insn_handler_t) (u32 opcode,
>> + struct arch_probes_insn *api,
>
> In the previous patch you were already aligning this handler the ARM32's
> equivalent. Why not fix the name (for the handler and struct
> arch_probes_insn) in the previous patch?
>
OK.
>> +
>> +#define link_register(regs) ((regs)->compat_lr)
>> +
>> +static inline void link_register_set(struct pt_regs *regs,
>> + unsigned long val)
>> +{
>> + link_register(regs) = val;
>> +}
>
> pstate.h isn't really related to compat mode and whichever compat
> definition it contains the relations are made explicit through their names.
>
> I don't think a macro "link_register" defined in arch/arm64 and visible
> to any file including ptrace.h (which is a lot) should return
> "compat_lr" instead of the actual link register.
>
> I'd say have the link_register macro check whether "regs" refers to a
> compat mode context or not and provide the adequate link register.
>
> Otherwise maybe you can get away with naming the macro
> "arm_link_register" and the macro "arm_link_register_set". But I would
> prefer the previous approach.
>
OK.
>> +#ifdef CONFIG_ARM64
>> +#include <../../../arm/include/asm/opcodes.h>
>
> Hmmm not sure this is something that is accepted.
>
OK, I'll fix it.
>> +/*
>> + * based on arm kprobes implementation
>> + */
>> +static void __kprobes simulate_ldm1stm1(probes_opcode_t insn,
>> + struct arch_probes_insn *asi,
>
> The whole asi/api mix become a bit confusing IMO.
> Should we have api when the argument is of type "arch_probes_insn" and
> asi when the type is "arch_specific_insn"?
> Should we have more coherent definitions of those structures between arm
> and arm64 if we are going to share functions between them?
>
OK, I'll try to figure something out that's less confusing.
>
> #ifdef CONFIG_ARM64
>
>> +enum probes_insn
>> +uprobe_decode_ldmstm_aarch64(probes_opcode_t insn,
>> + struct arch_probes_insn *asi,
>> + const struct decode_header *d)
>
> Should be static.
>
OK.
Thanks again for the review. I'll rework the whole patchset to include
your remarks.
Thank you,
Maciej
next prev parent reply other threads:[~2018-10-01 13:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180926121213eucas1p1e85f71d1187eb6b50c320377e5ea907f@eucas1p1.samsung.com>
2018-09-26 12:11 ` [PATCH v2 0/7] arm64: uprobes - ARM32 instruction probing Maciej Slodczyk
[not found] ` <CGME20180926121214eucas1p2b262936ddd96980b7b4369f16b52c6ce@eucas1p2.samsung.com>
2018-09-26 12:11 ` [PATCH v2 1/7] arm64: move arm uprobes code to be reused by arm64 Maciej Slodczyk
2018-09-29 9:37 ` Suzuki K Poulose
2018-10-01 13:12 ` Maciej Slodczyk
[not found] ` <CGME20180926121214eucas1p1660542d20425551038da8d3feaf7e1b7@eucas1p1.samsung.com>
2018-09-26 12:12 ` [PATCH v2 2/7] arm64: uprobes - fix checkpatch issues Maciej Slodczyk
2018-09-29 9:39 ` Suzuki K Poulose
[not found] ` <CGME20180926121215eucas1p10437d5bd9db81bedbcc363d24d196ded@eucas1p1.samsung.com>
2018-09-26 12:12 ` [PATCH v2 3/7] arm64: introduce get_swbp_insn() instead of static assignment Maciej Slodczyk
[not found] ` <CGME20180926121216eucas1p28c13ab1a21ac5ef5058206b92954604f@eucas1p2.samsung.com>
2018-09-26 12:12 ` [PATCH v2 4/7] arm64: change arm64 probes handler prototype Maciej Slodczyk
[not found] ` <CGME20180926121216eucas1p2b896ce19f49214d497721db9d6e59bfb@eucas1p2.samsung.com>
2018-09-26 12:12 ` [PATCH v2 5/7] arm64: make arm uprobes code reusable by arm64 Maciej Slodczyk
2018-09-27 15:52 ` Julien Thierry
2018-10-01 13:28 ` Maciej Slodczyk [this message]
2018-10-02 8:08 ` Julien Thierry
[not found] ` <CGME20180926121217eucas1p198d96ed637d1aa8a98c1b90466dde745@eucas1p1.samsung.com>
2018-09-26 12:12 ` [PATCH v2 6/7] arm64: change arm_probe_decode_insn() function name Maciej Slodczyk
[not found] ` <CGME20180926121218eucas1p1b20a88cfec17c6403a35e4f23de96ade@eucas1p1.samsung.com>
2018-09-26 12:12 ` [PATCH v2 7/7] arm64: uprobes - ARM32 instruction probing Maciej Slodczyk
2018-09-27 16:18 ` Julien Thierry
2018-09-27 17:01 ` Robin Murphy
2018-10-01 13:40 ` Maciej Slodczyk
2018-10-02 11:04 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='20181001132852eucas1p25ab2ddf39296e2c78b188234d168f814~ZfyJK4W4N0481804818eucas1p2j@eucas1p2.samsung.com' \
--to=m.slodczyk2@partner.samsung.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=b.zolnierkie@samsung.com \
--cc=catalin.marinas@arm.com \
--cc=jolsa@redhat.com \
--cc=julien.thierry@arm.com \
--cc=k.lewandowsk@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).