Messages in this thread | | | Date | Mon, 23 Mar 2015 17:38:06 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails |
| |
On Mon 2015-03-23 09:58:53, Steven Rostedt wrote: > On Mon, 23 Mar 2015 14:53:06 +0100 > Ingo Molnar <mingo@kernel.org> wrote: > > > > > I think it has to do with their RCU like patching functionality, > > > where some tasks are still executing the old function and others are > > > executing the new function. [...] > > > > That would be the 'function with pending patch' state in my > > description above. > > That could be considered a bit confusing too, because the patch isn't > pending, it's already applied. But this is getting off topic, as the > code for this isn't even in mainline yet, so I agree that the use of > terminology that has not been upstreamed yet should be avoided.
I am sorry for confusion. I will be more careful about the terminology in my mails.
Anyway, I did not use the word because I wanted to be special. I joined the team working on kGraft (SUSE live patch implementation) when the work was already in progress. This term was used there heavily. You know, I have used it for too long and somehow forgot that many other people were not familiar with it.
And yes, it is similar to RCU terminology. If we added support for patches that modify semantic of functions, there would be three states as well:
1. no patch
2. patch is added; ftrace handler is added but it does _not_ redirect the code; the old function is still used because there has not been a safe point for the switch yet
3. patch is added; ftrace handler is added and it redirects the call to the new implementation from the patch
The second state is similar to RCU intermediate state. A list has been modified but some thread might still see the old state.
Best Regards, Petr
| |