On 2015/3/5 9:53, Wang Nan wrote:
>> ...
>> >
>>> >> /* kprobe is available. */
>>> >> KP_STG_AVAIL,
>> >
>> > KP_STG_EARLY is better, isn't it? :)
> Sure. I will change it.
>
Sorry, I remembered the reason why I call it KP_STG_AVAIL. What about .config
turns off
Thanks to your reply. I have some inline comment. Please see below.
By the way, as you suggested me to fold my patches up, will you review my v4
series? Or do you want to start looking at early kprobe after I merge small
patch pieces
together? Then I can decide whether to post a v5 series with
Hi Wang,
(2015/03/04 20:22), Wang Nan wrote:
> Hi Masami,
>
> Following your advise, I adjusted early kprobe patches, added a
> kprobes_init_stage var to indicate the initiaization progress of
> kprobes. It has following avaliable values:
>
> typedef enum {
> /* kprobe initialization is
Hi Masami,
Following your advise, I adjusted early kprobe patches, added a
kprobes_init_stage var to indicate the initiaization progress of
kprobes. It has following avaliable values:
typedef enum {
/* kprobe initialization is error. */
KP_STG_ERR = -1,
/* kprobe is not
Hi Wang,
(2015/03/04 20:22), Wang Nan wrote:
Hi Masami,
Following your advise, I adjusted early kprobe patches, added a
kprobes_init_stage var to indicate the initiaization progress of
kprobes. It has following avaliable values:
typedef enum {
/* kprobe initialization is error.
On 2015/3/5 9:53, Wang Nan wrote:
...
/* kprobe is available. */
KP_STG_AVAIL,
KP_STG_EARLY is better, isn't it? :)
Sure. I will change it.
Sorry, I remembered the reason why I call it KP_STG_AVAIL. What about .config
turns off CONFIG_EARLY_KPROBES? In
Thanks to your reply. I have some inline comment. Please see below.
By the way, as you suggested me to fold my patches up, will you review my v4
series? Or do you want to start looking at early kprobe after I merge small
patch pieces
together? Then I can decide whether to post a v5 series with
Hi Masami,
Following your advise, I adjusted early kprobe patches, added a
kprobes_init_stage var to indicate the initiaization progress of
kprobes. It has following avaliable values:
typedef enum {
/* kprobe initialization is error. */
KP_STG_ERR = -1,
/* kprobe is not
(2015/03/04 13:39), Wang Nan wrote:
> On 2015/3/4 11:36, Masami Hiramatsu wrote:
>> (2015/03/04 11:24), Wang Nan wrote:
>>> On 2015/3/4 1:06, Petr Mladek wrote:
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
> Before ftrace convertin instruction to nop, if an early kprobe is
> registered
On 2015/3/4 11:36, Masami Hiramatsu wrote:
> (2015/03/04 11:24), Wang Nan wrote:
>> On 2015/3/4 1:06, Petr Mladek wrote:
>>> On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its
(2015/03/04 11:24), Wang Nan wrote:
> On 2015/3/4 1:06, Petr Mladek wrote:
>> On Tue 2015-03-03 13:09:05, Wang Nan wrote:
>>> Before ftrace convertin instruction to nop, if an early kprobe is
>>> registered then unregistered, without this patch its first bytes will
>>> be replaced by head of NOP,
On 2015/3/4 1:06, Petr Mladek wrote:
> On Tue 2015-03-03 13:09:05, Wang Nan wrote:
>> Before ftrace convertin instruction to nop, if an early kprobe is
>> registered then unregistered, without this patch its first bytes will
>> be replaced by head of NOP, which may confuse ftrace.
>>
>> Actually,
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
> Before ftrace convertin instruction to nop, if an early kprobe is
> registered then unregistered, without this patch its first bytes will
> be replaced by head of NOP, which may confuse ftrace.
>
> Actually, since we have a patch which convert ftrace
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes will
be replaced by head of NOP, which may confuse ftrace.
Actually, since we have a patch which convert ftrace entry
(2015/03/04 13:39), Wang Nan wrote:
On 2015/3/4 11:36, Masami Hiramatsu wrote:
(2015/03/04 11:24), Wang Nan wrote:
On 2015/3/4 1:06, Petr Mladek wrote:
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered,
(2015/03/04 11:24), Wang Nan wrote:
On 2015/3/4 1:06, Petr Mladek wrote:
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes will
be replaced by head of NOP, which may
On 2015/3/4 1:06, Petr Mladek wrote:
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes will
be replaced by head of NOP, which may confuse ftrace.
Actually, since we
On 2015/3/4 11:36, Masami Hiramatsu wrote:
(2015/03/04 11:24), Wang Nan wrote:
On 2015/3/4 1:06, Petr Mladek wrote:
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes will
be replaced by head of NOP, which may confuse ftrace.
Actually, since we have a patch which convert ftrace entry to nop
when probing, this problem should never
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes will
be replaced by head of NOP, which may confuse ftrace.
Actually, since we have a patch which convert ftrace entry to nop
when probing, this problem should never
20 matches
Mail list logo
