Hi, On 12/11/2023 10:56 AM, Alexei Starovoitov wrote: > On Sun, Dec 10, 2023 at 6:07 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: >> Hi Alexei, >> >> On 12/10/2023 10:11 AM, Alexei Starovoitov wrote: >>> On Fri, Dec 8, 2023 at 2:22 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: >>>> + /* Wait for any running non-sleepable and sleepable BPF programs to >>>> + * complete, so that userspace, when we return to it, knows that all >>>> + * programs that could be running use the new map value. >>> which could be forever... and the user space task doing simple map update >>> will never know why it got stuck in syscall waiting... forever... >>> synchronous waiting for tasks_trace is never an option. >> Could you please elaborate the reason why there is dead-lock problem ? >> In my naive understanding, synchronize_rcu_tasks_trace() only waits for >> the end of rcu_read_lock_trace()/rcu_read_unlock_trace(), if there is no >> rcu_read_lock_trace being held, there will be no dead-lock. > I didn't say it's dead-lock. rcu_read_lock_trace() section can last > for a very long time. The user space shouldn't be exposed to such delays. I see. Thanks for the explanation. Will update the comments in maybe_wait_bpf_programs() in a new patch. > .
