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.