(2014/11/26 4:29), Jiri Kosina wrote: > On Tue, 25 Nov 2014, Steven Rostedt wrote: > >> It is not guaranteed from ftrace's stand point. What happens if we have >> a kprobe handler that modifies it for someplace else? Changing the ip >> address may not be a kpatch/kGraft privilege only. > > This brings me back to the RFC patch I sent back then in october ... what > we really want to do is to at least warn about situations when we are > going to redirect code flow (through IPMODIFY) for function that has a > kprobe installed anywhere inside it. Actually in my plan, normal kprobes/kretprobes don't set IPMODIFY flag because it don't change the IP. Instead, you can even use debugfs/kprobes/list to check whether the function is probed or not. Or, I think we can provide atomic-conflict checking interface which will iterate probes under locking kprobe list. > Otherwise the probe will silently > vanish (there is no way how to migrate it to the new function > automatically), which might be very confusing for uses (cosider systemtap, > for example). Yeah, I think we can add --force option(or sysctl) to patch functions just ignoring probed or not. (for emergency vulnerability fixes) Thank you, > > I'll resurect my patch if noone beats me doing it. It should go in > together with the live patching framework I believe. > > Thanks, > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@xxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
