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

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

Date:	Thu, 1 May 2014 17:09:43 -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

On Thu, May 01, 2014 at 05:02:42PM -0400, Tejun Heo wrote:
> 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

Just a bit of addition.  Please note that kthread_should_stop(), along
with the freezer test, is actually trickier than it seems.  It's very
easy to write code which works most of the time but misses wake up
from kill when the timing is just right (or wrong).  It should be
interlocked with set_current_state() and other related queueing data
structure accesses.  This was several years ago but when I audited
most kthread users in kernel, especially in combination with the
freezer test which also has similar requirement, surprising percentage
of users (at least several tens of pct) were getting it slightly
wrong, so kthread_should_stop() really isn't used as "we can exit
*immediately*".  It just isn't that simple.

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/