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: <20140515040608.GA3825@htj.dyndns.org>
Date:	Thu, 15 May 2014 00:06:08 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
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

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"?

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

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.

In general, being restricted to using kthread internally for this
reason seems wrong to me.  It's too direct influence on the
implementation mechanism.

> I saw a case where dynamic workers inflicted a realtime regression on a
> user (but what they were getting away with previously was.. horrid).

Yeah, exactly.  It'd be far better to identify the use case properly
and provide the appropriate interface for it.  That said, even if it
really requires diddling with kthread directly from userland,
kthread_worker can still be used.  It's still one dedicated kthread
but with structured usage from kernel side so that infrastructure
features like freezer and possibly kgr can be implemented in a single
place rather than scattered around all over the place.

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/