lkml.org 
[lkml]   [2014]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv4 0/3] Kernel Live Patching
(2014/11/26 18:18), Jiri Kosina wrote:
> On Wed, 26 Nov 2014, Masami Hiramatsu wrote:
>
>>> Note to Steve:
>>> Masami's IPMODIFY patch is heading for -next via your tree. Once it arrives,
>>> I'll rebase and make the change to set IPMODIFY. Do not pull this for -next
>>> yet. This version (v4) is for review and gathering acks.
>>
>> BTW, as we discussed IPMODIFY is an exclusive flag. So if we allocate
>> ftrace_ops for each function in each patch, it could be conflict each
>> other.
>
> Yup, this corresponds to what Petr brought up yesterday. There are cases
> where all solutions (kpatch, kgraft, klp) would allocate multiple
> ftrace_ops for a single function entry (think of patching one function
> multiple times in a row).
>
> So it's not as easy as just setting the flag.
>
>> Maybe we need to have another ops hashtable to find such conflict and
>> new handler to handle it.
>
> If I understand your proposal correctly, that would sound like a hackish
> workaround, trying to basically trick the IPMODIFY flag semantics you just
> implemented :)
>
> What I'd propose instead is to make sure that we always have
> just a ftrace_ops per function entry, and only update the pointers there
> as necessary. Fortunately we can do the switch atomically, by making use
> of ->private.

Would you mean per existing function entry, not per klp-func entry?
If so, it sounds good to me too :)

Thank you,


--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com




\
 
 \ /
  Last update: 2014-11-27 07:41    [W:0.100 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site