linux-kernel - [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 for Android: free password hash cracker in your pocket

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

Message-Id: <20180628075742.8991-1-u.kleine-koenig@pengutronix.de>
Date:   Thu, 28 Jun 2018 09:57:42 +0200
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Greg Kroah-Hartman <gregkh@...e.de>
Cc:     linux-kernel@...r.kernel.org, Gavin Schenk <g.schenk@...elmann.de>,
        kernel@...gutronix.de, Peter Zijlstra <peterz@...radead.org>
Subject: [PATCH] siox: don't create a thread without starting it

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>
---
Hello,

this is the same patch as before with an updated commit log. I added
Peter's ack anyhow assuming my text isn't too bad to make him withdraw
it.

I think this issue isn't critical as the machine works fine otherwise,
so applying it for 4.18-rc isn't necessary.
(OTOH it's an SMP machine so the tests might not have noticed one blocked
CPU, didn't test this.)

Greg, you applied the initial patches creating drivers/siox. I assume
you will continue to apply siox patches and tell if I should search a
different path for these.

Best regards
Uwe

 drivers/siox/siox-core.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index 16590dfaafa4..cef307c0399c 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -715,17 +715,17 @@ int siox_master_register(struct siox_master *smaster)

 	dev_set_name(&smaster->dev, "siox-%d", smaster->busno);

+	mutex_init(&smaster->lock);
+	INIT_LIST_HEAD(&smaster->devices);
+
 	smaster->last_poll = jiffies;
-	smaster->poll_thread = kthread_create(siox_poll_thread, smaster,
-					      "siox-%d", smaster->busno);
+	smaster->poll_thread = kthread_run(siox_poll_thread, smaster,
+					   "siox-%d", smaster->busno);
 	if (IS_ERR(smaster->poll_thread)) {
 		smaster->active = 0;
 		return PTR_ERR(smaster->poll_thread);
 	}

-	mutex_init(&smaster->lock);
-	INIT_LIST_HEAD(&smaster->devices);
-
 	ret = device_add(&smaster->dev);
 	if (ret)
 		kthread_stop(smaster->poll_thread);
-- 
2.18.0