> > It is even more complicated and it is not connected only to atomic replace > > patch (I realized this while reading the first part of your email and > > then you confirmed it with this paragraph). The consistency model is > > broken with respect to immediate patches. > > Indeed. I came to the same conclusion. > > > > > func a > > patches 1i > > 2i > > 3 > > > > Now, when you're applying 3, only 2i function is checked. But there might > > be a task sleeping in 1i. Such task would be migrated to 3, because we do > > not check 1 in klp_check_stack_func() at all. > > > > I see three solutions. > > > > 1. Say it is an user's fault. Since it is not obvious and it is > > easy-to-make mistake, I would not go this way. > > > > 2. We can fix klp_check_stack_func() in an exact way you're proposing. > > We'd go back in func stack as long as there are immediate patches there. > > This adds complexity and I'm not sure if all the problems would be solved > > because scenarios how patches are stacked and applied to different > > functions may be quite complex. > > > > I think if its fixed in the current code (before atomic replace is > introduced), then it would allow the atomic replace to drop all > references to previous modules, since we would know they are no longer > in use.
That's correct. Although, I'll submit my force patch soon, we can remove immediate afterwards and atomic replace should be simpler with that. Miroslav
