linux-kernel - Re: [PATCH] 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:   Fri, 29 Jun 2018 06:27:22 +0000
From:   "Schenk, Gavin" <G.Schenk@...elmann.de>
To:     "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH] siox: don't create a thread without starting it

On Thu, 2018-06-28 at 09:57 +0200, Uwe Kleine-König wrote:
> When a siox master device is registered a kthread is created that is
> only started when triggered by userspace. So this thread might be in
> TASK_UNINTERRUPTIBLE state for long and trigger a warning
> 
> 	[  241.130465] INFO: task siox-0:626 blocked for more than 120 seconds.
> 
> with the respective debug settings enabled. It might be right to put an
> unstarted thread to TASK_IDLE (in kernel/kthread.c:kthread()) instead,
> but independant of this discussion it is cleaner for
> siox_master_register() to start the thread immediately. The effect is
> that it enters its own waiting state and then stays in state TASK_IDLE
> which doesn't trigger the above warning.
> 
> As siox_poll_thread() uses some variables of the device the
> initialisation of these is moved before thread creation.
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> ---
Acked-by: Gavin Schenk <g.schenk@...elmann.de

I tested that this warning is gone with this patch.

Regards
Gavin Schenk