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]

Date:	Thu, 15 May 2014 06:46:18 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Vojtech Pavlik <vojtech@...e.cz>, Jiri Slaby <jslaby@...e.cz>,
	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org,
	jirislaby@...il.com, 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, 2014-05-15 at 00:06 -0400, Tejun Heo wrote: 
> Hey, Mike.
> 
> On Thu, May 15, 2014 at 05:53:57AM +0200, Mike Galbraith wrote:
> > Hm.  The user would need to be able to identify and prioritize the
> 
> I suppose you mean userland by "the user"?

Yeah.

> > things, and have his settings stick.  Any dynamic pool business doing
> > allocations and/or munging priorities would be highly annoying.
> 
> There are some use cases where control over worker priority or other
> attributes are necessary.  I'm not sure using kthread for that reason
> is a good engineering choice tho.  Many of those cases end up being
> accidental.

It's currently the only option.  For perfection, you'd have to have fine
grained deterministic yada yada throughout all paths, which is kinda out
for generic proxies, but it's a hell of a lot better than no control.

> I think it'd be healthier to identify the use cases and then provide
> proper interface for it.  Note that workqueue can now expose interface
> to modify concurrency, priority and cpumask to userland which
> writeback workers are already using.

You can't identify a specific thing, any/all of it can land on the
user's diner plate, so he should be able to make the decisions.  Power
to the user and all that, if he does something stupid, tuff titty.  User
getting to call the shots, and getting to keep the pieces when he fscks
it all up is wonderful stuff, lets kernel people off the hook :)

-Mike

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