On Thu, 15 Jan 2015, Masami Hiramatsu wrote:
> Hmm, if this binary doesn't support IPMODIFY, it should return -ENOTSUPP.
Good poing, will send v3.
> And also, IMHO, we'd better reject registering ftrace_ops with IPMODIFY
> in this situation before updating hash table.
That would happen
On Thu, 15 Jan 2015, Masami Hiramatsu wrote:
Hmm, if this binary doesn't support IPMODIFY, it should return -ENOTSUPP.
Good poing, will send v3.
And also, IMHO, we'd better reject registering ftrace_ops with IPMODIFY
in this situation before updating hash table.
That would happen
(2015/01/14 17:47), Jiri Kosina wrote:
> Using IPMODIFY needs to be allowed only with compilers which are
> guaranteed to generate function prologues compatible with function
> redirection through changing instruction pointer in saved regs.
>
> For example changing regs->ip on x86_64 in cases
Using IPMODIFY needs to be allowed only with compilers which are
guaranteed to generate function prologues compatible with function
redirection through changing instruction pointer in saved regs.
For example changing regs->ip on x86_64 in cases when gcc is using mcount
(and not fentry) is not
(2015/01/14 17:47), Jiri Kosina wrote:
Using IPMODIFY needs to be allowed only with compilers which are
guaranteed to generate function prologues compatible with function
redirection through changing instruction pointer in saved regs.
For example changing regs-ip on x86_64 in cases when
Using IPMODIFY needs to be allowed only with compilers which are
guaranteed to generate function prologues compatible with function
redirection through changing instruction pointer in saved regs.
For example changing regs-ip on x86_64 in cases when gcc is using mcount
(and not fentry) is not
6 matches
Mail list logo
