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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Jun 2018 21:21:21 +0200
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Gavin Schenk <g.schenk@...elmann.de>, kernel@...gutronix.de
Subject: Re: [PATCH] RFC: siox: don't create a thread without starting it

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/  |