From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Subject: Re: [PATCH 1/2] MIPS: tracing: move insn_has_delay_slot to a shared header
Date: Wed, 5 Oct 2016 08:10:09 +0200 [thread overview]
Message-ID: <205d3e96-0dc2-ba59-43da-dff1cde17a7a@imgtec.com> (raw)
In-Reply-To: <20161004231809.GC14676@linux-mips.org>
On 05.10.2016 01:18, Ralf Baechle wrote:
> On Fri, Sep 30, 2016 at 11:33:45AM +0200, Marcin Nowakowski wrote:
>
>> Currently both kprobes and uprobes code have definitions of the
>> insn_has_delay_slot method. Move it to a separate header as an inline
>> method that each probe-specific method can later use.
>> No functional change intended, although the methods slightly varied in
>> the constraints they set for the methods - the uprobes one was chosen as
>> it is slightly more specific when filtering opcode fields.
>
> Applied - but this is way to big for an inline function and will end up
> getting expanded two times in uprobes.c for no good reason. I think this
> function should become go to something like arch/mips/kernel/branch.c -
> or maybe a helper library like arch/mips/lib/bdelay.c.
>
> Ralf
>
Well - that's the behaviour my change hasn't modified.
But I agree that it may be better to simply make it a library function
that could be used everywhere. The main reason I didn't do it in the
first place was to keep the implementation in kprobes in __kprobes
section like the original code did, but I guess it won't do any harm for
the code that is used in the uprobes path to exist in the kprobe section
as well?
It's probably not the last change in this area yet so I'll keep this in
mind and will update later.
Marcin
WARNING: multiple messages have this Message-ID (diff)
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 1/2] MIPS: tracing: move insn_has_delay_slot to a shared header
Date: Wed, 5 Oct 2016 08:10:09 +0200 [thread overview]
Message-ID: <205d3e96-0dc2-ba59-43da-dff1cde17a7a@imgtec.com> (raw)
Message-ID: <20161005061009.wJYn6nDllcuKE_5GLgPFtmKSlqyMHGFd8rxSqKtvH6Q@z> (raw)
In-Reply-To: <20161004231809.GC14676@linux-mips.org>
On 05.10.2016 01:18, Ralf Baechle wrote:
> On Fri, Sep 30, 2016 at 11:33:45AM +0200, Marcin Nowakowski wrote:
>
>> Currently both kprobes and uprobes code have definitions of the
>> insn_has_delay_slot method. Move it to a separate header as an inline
>> method that each probe-specific method can later use.
>> No functional change intended, although the methods slightly varied in
>> the constraints they set for the methods - the uprobes one was chosen as
>> it is slightly more specific when filtering opcode fields.
>
> Applied - but this is way to big for an inline function and will end up
> getting expanded two times in uprobes.c for no good reason. I think this
> function should become go to something like arch/mips/kernel/branch.c -
> or maybe a helper library like arch/mips/lib/bdelay.c.
>
> Ralf
>
Well - that's the behaviour my change hasn't modified.
But I agree that it may be better to simply make it a library function
that could be used everywhere. The main reason I didn't do it in the
first place was to keep the implementation in kprobes in __kprobes
section like the original code did, but I guess it won't do any harm for
the code that is used in the uprobes path to exist in the kprobe section
as well?
It's probably not the last change in this area yet so I'll keep this in
mind and will update later.
Marcin
next prev parent reply other threads:[~2016-10-05 6:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-30 9:33 [PATCH 1/2] MIPS: tracing: move insn_has_delay_slot to a shared header Marcin Nowakowski
2016-09-30 9:33 ` Marcin Nowakowski
2016-09-30 9:33 ` [PATCH 2/2] MIPS: tracing: disable uprobe/kprobe on compact branch instructions Marcin Nowakowski
2016-09-30 9:33 ` Marcin Nowakowski
2016-10-04 23:18 ` [PATCH 1/2] MIPS: tracing: move insn_has_delay_slot to a shared header Ralf Baechle
2016-10-05 6:10 ` Marcin Nowakowski [this message]
2016-10-05 6:10 ` Marcin Nowakowski
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=205d3e96-0dc2-ba59-43da-dff1cde17a7a@imgtec.com \
--to=marcin.nowakowski@imgtec.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
/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