[kpatch] can't set ftrace filter

[Somdeep Das]

Hi Josh,

First of all, a big thanks for your swift reply.

The issue got resolved :). I had been building the "complex" module
wrongly. I was building the third argument of create-diff-object (which is
the .ko file) with KCFLAGS="-ffunction-sections -fdata-sections" set. This
is not to be done apparently. I unset the KCFLAGS while building the .ko
file and everything went smoothly.

Thanks again :).

Regards,
Somdeep Das

On Thu, Jun 11, 2015 at 7:59 PM, Josh Poimboeuf <jpoimboe at redhat.com> wrote:

> On Thu, Jun 11, 2015 at 07:44:59PM +0530, Somdeep Das wrote:
> > Hi,
> >
> > I have been trying out kpatch for some time now. I was able to create,
> > install and load a patch successfully for my simple device driver. So far
> > so good. Next, I tried to patch a bit more complex kernel module having
> > multiple object files. I then created and installed the patch using the
> > kpatch tools but while loading the patch I am hitting an issue. Kpatch is
> > reporting the following error:
> > kpatch: can't set ftrace filter at address <some address>
> >
> > I did some investigation and reached to a conclusion that
> > ftrace_match_addr() is returning -22 (-EINVAL) as ftrace_location() is
> > failing to find the target function’s address in ftrace table.
> >
> > I would be really grateful if I can get any help on resolving this issue.
>
> Hi Somdeep,
>
> Most kernel and module functions have a "call mcount" instruction as the
> beginning, which is the ftrace hook which kpatch needs in order to patch
> a function.
>
> "objdump -d" should show something like the following:
>
> 0000000000000000 <drm_getmagic>:
>        0:       e8 00 00 00 00          callq  5 <drm_getmagic+0x5>
>
> (Ignore the <drm_getmagic+0x5> target.  objdump isn't smart enough to
> understand ELF relocations.  But it should always be a "e8 00 00 00 00"
> instruction.)
>
> It sounds like the function you're trying to patch doesn't have an
> ftrace hook at the beginning for some reason.  Did you do anything
> "different" when building the more complex module?  Or any chance the
> function was annotated with "notrace"?
>
> --
> Josh
>



-- 
50|V|[)33|>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kpatch/attachments/20150612/81a50283/attachment.htm>