Re: [PATCH] RFC: siox: don't create a thread without starting it

[Uwe Kleine-König]

Hello Peter,

On Mon, Jun 25, 2018 at 02:51:05PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 12:20:56PM +0200, Uwe Kleine-König wrote:
> > when I just boot without any other siox-related action. So the kthread (created
> > in drivers/siox/siox-core.c:siox_master_register()) is never started.
> > 
> > While you could argue that there is little reason to not start the
> > thread there also is little reason to actually do it.
> 
> Well, you really _should_ wake up the thread. That first wakeup really
> is part of the whole 'create/setup' kthread pattern.

ok

> > peterz in #kernelnewbies said "[...] kernel/kthread.c:kthread() should
> > really be using __set_current_state(TASK_IDLE), I suppose". This however
> > seems to interfere with problems fixed in a076e4bca2fd ("freezer: fix
> > kthread_create vs freezer theoretical race").
> 
> I don't think so, that patch has an issue with INTERRUPTIBLE, but IDLE
> very much doesn't allow signals like INTERRUPTIBLE does.

I don't think I can provide a good commit log for
s/TASK_UNINTERRUPTIBLE/TASK_IDLE/ in kernel/kthread.c:kthread(). But I
can confirm that this patch makes the warning go away, so if you want to
address this, you can add my Tested-by:.
 
> > So I wonder where the real problem is and how it can be fixed.
> 
> Without the first wakeup, the kthread will not run the provided function
> and we can therefore argue the creation is incomplete. I really feel you
> should just wake the thing up to land in your own wait-condition-loop.
> 
> That said, irrespective of the whole UNINTERRUPTIBLE/IDLE thing, I find
> this construct fairly fragile. We rely on not getting any spurious
> wakeups without a 'special' state.

Well, if the thread is woken up unintentionally nothing happens (apart
from the lock and the list that I moved in my patch that might not be
initialized yet; this should be fixed for sure). It just enters the
thread's own wait-condition-loop. So you could argue that the wakeup
call is just overhead that isn't necessary until the thread is really
needed. (I won't argue, I can accept your opinion and do the wakeup.)

> The only reason this doesn't normally happen is because it's a new
> task, but since it is already hashed, it might well be possible to
> trick someone into sending a wakeup.

Is this an ack for the RFC patch you replied to?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |