linux-kernel - __refrigerator() && saved task->state

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:	Wed, 13 Nov 2013 20:11:43 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	David Laight <David.Laight@...LAB.COM>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Ingo Molnar <mingo@...nel.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: __refrigerator() && saved task->state

Sorry for noise, but I am totally confused.

Could you please remind why __refrigerator() saves/restores
task->state?

I can see only one reason: set_freezable() kernel threads which
check kthread_should_stop() and do try_to_freeze() by hand.

But does this save/restore actually help?

For example kauditd_thread() looks obviously racy exactly because
try_to_freeze() can return in TASK_INTERRUPTIBLE state after
wake_up(kauditd_wait) was already called, we can miss an event.

At first glance it would be better to simply kill this logic? If
it was called with ->state != 0, the caller is going to schedule()
and it probably executes the wait_event-like code, in this case
it would me more safe to pretend the task got a spurious wakeup?

(as for kauditd_thread() in particular, it looks wrong in any
 case, even kthread_should_stop() check doesn't look right, it
 needs kthread_freezable_should_stop() afaics).

But I guess I missed something else...

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/