> On Jul 15, 2022, at 2:29 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Fri, 15 Jul 2022 20:21:49 +0000
> Song Liu <songliubraving@xxxxxx> wrote:
>
>>>>> Wouldn't this need to be done anyway if BPF was first and live kernel
>>>>> patching needed the update? An -EAGAIN would not suffice.
>>>>
>>>> prepare_direct_functions_for_ipmodify handles BPF-first-livepatch-later
>>>> case. The benefit of prepare_direct_functions_for_ipmodify() is that it
>>>> holds direct_mutex before ftrace_lock, and keeps holding it if necessary.
>>>> This is enough to make sure we don't need the wash-rinse-repeat.
>>>>
>>>> OTOH, if we wait until __ftrace_hash_update_ipmodify(), we already hold
>>>> ftrace_lock, but not direct_mutex. To make changes to bpf trampoline, we
>>>> have to unlock ftrace_lock and lock direct_mutex to avoid deadlock.
>>>> However, this means we will need the wash-rinse-repeat.
>>
>> What do you think about the prepare_direct_functions_for_ipmodify()
>> approach? If this is not ideal, maybe we can simplify it so that it only
>> holds direct_mutex (when necessary). The benefit is that we are sure
>> direct_mutex is already held in __ftrace_hash_update_ipmodify(). However,
>> I think it is not safe to unlock ftrace_lock in __ftrace_hash_update_ipmodify().
>> We can get parallel do_for_each_ftrace_rec(), which is dangerous, no?
>
> I'm fine with it. But one nit on the logic:
>
>> int register_ftrace_function(struct ftrace_ops *ops)
>> + __releases(&direct_mutex)
>> {
>> + bool direct_mutex_locked;
>> int ret;
>>
>> ftrace_ops_init(ops);
>>
>> + ret = prepare_direct_functions_for_ipmodify(ops);
>> + if (ret < 0)
>> + return ret;
>> +
>> + direct_mutex_locked = ret == 1;
>> +
>
> Please make the above:
>
> if (ret < 0)
> return ret;
> else if (ret == 1)
> direct_mutex_locked = true;
>
> It's much easier to read that way.
Thanks for the clarification!
Song
