On Tue, Apr 30, 2024 at 06:12:37PM +0200, Joel Colledge wrote: > On Tue, 30 Apr 2024 at 17:27, Christian Loehle <christian.loehle@xxxxxxx> wrote: > > On 30/04/2024 15:44, Joel Colledge wrote: > > > On Tue, 30 Apr 2024 at 16:28, Christian Loehle <christian.loehle@xxxxxxx> wrote: > > >> Is this an issue for delay > 0 too somehow? > > > > > > I believe it is. If there is simply no IO to the delay device, then > > > nothing will wake the new thread and the same issue will occur. > > > > Yes, but might be better to just set_current_state(TASK_INTERRUPTIBLE); > > instead of the wakeup. > > I'm afraid I don't follow what you mean. > set_current_state(TASK_INTERRUPTIBLE) would need to be called from the > worker, but the worker isn't running yet, so it can't do that. > > When preparing this patch, I checked how common kthread_create() > followed by wake_up_process() is. It is fairly common according to > this very approximate metric: > $ grep -r -I -A10 kthread_create | grep -c wake_up_process > 49 > > I just looked through those matches in more detail and noticed that > there is a kthread_run() macro which does exactly what we need. I will > change my suggestion to use that instead. > > I will wait for more comments before sending a new version of the patch. kthread_run() looks like the right solution here. There's no need to wait for more initialization and the kthread will put itself to sleep momentarily. Please send an updated patch. -Ben > > Best regards, > Joel
