linux-kernel - Re: [RFC 09/16] kgr: mark task

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]

Message-ID: <20140501210242.GA28948@mtj.dyndns.org>
Date:	Thu, 1 May 2014 17:02:42 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org,
	jirislaby@...il.com, Vojtech Pavlik <vojtech@...e.cz>,
	Michael Matz <matz@...e.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Theodore Ts'o <tytso@....edu>,
	Dipankar Sarma <dipankar@...ibm.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC 09/16] kgr: mark task_safe in some kthreads

Hello, Jiri.

On Thu, May 01, 2014 at 10:17:44PM +0200, Jiri Kosina wrote:
> I agree that this expectation might really somewhat implicit and is not 
> probably properly documented anywhere. The basic observation is "whenever 
> kthread_should_stop() is being called, all data structures are in a 
> consistent state and don't need any further updates in order to achieve 
> consistency, because we can exit the loop immediately here", as 
> kthread_should_stop() is the very last thing every freezable kernel thread 

But kthread_should_stop() doesn't necessarily imply that "we can exit
the loop *immediately*" at all.  It just indicates that it should
terminate in finite amount of time.  I don't think it'd be too
difficult to find cases where kthreads do some stuff before returning
after testing kthread_should_stop().  e.g. after pending changes,
workqueue rescuers do one final loop over pending work items after
kthread_should_stop() tests positive to ensure empty queue on exit.
Please note that there's no expectation of discontinuity over the
test.  The users may carry over any state across the test as they see
fit.

> is calling before starting a new iteration.
> 
> For the sake of collecting data points -- do you happen to have any 
> counter-example to the assumption?

Just grep for kthread_should_stop() and look for the ones which
doesn't immediately perform return?  I think there are more which
don't return *immediately*.  You'd have to audit each and everyone to
determine that they don't carry over states across the test.  Most
will hopefully be trivial but not all.  More importantly, sounds like
a maintenance nightmare to me without any means to guarantee, or even
reasonably increase, correctness.

Thanks.

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