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. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
