linux-kernel - Re: [RFC] cgroups: freezer -- Allow to attach a task to a frozen cgroup

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: <20111129231922.GA20313@google.com>
Date:	Tue, 29 Nov 2011 15:19:22 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	Cyrill Gorcunov <gorcunov@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Andrey Vagin <avagin@...nvz.org>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [RFC] cgroups: freezer -- Allow to attach a task to a frozen
 cgroup

Hello, Matt.

On Tue, Nov 29, 2011 at 02:58:53PM -0800, Matt Helsley wrote:
> >   transition notification too, at the very least, clarification of
> 
> Notification is a fine idea. However, not everything that's already
> written expects them so correct usage of the cgroup freezer should not
> require them -- IOW allowing the FROZEN -> FREEZING transition
> isn't made OK just by adding notifications.

The transition model doesn't have to be modified.  ie. we can try to
freeze the task/process on migration request and actually moves it
only when it actually reaches the target state.  Not entirely sure how
well that can be implemented with the current cgroup callbacks tho.
We can also make the new behavior selectable per-cgroup if all else
fail.

> > * There are some unclear corner cases and bugs the current cgroup
> >   freezer has.  e.g. behavior w.r.t. kthreads is outright buggy.  It
> >   would be great to figure out how to deal with them with or before
> >   this change (ie. what happens when you transfer unfreezable
> >   kthreads).
> 
> Huh? Shouldn't we just disable moving kthreads between cgroups? Allowing
> userspace to freeze kthreads via cgroups seems like a *very* bad idea
> (perhaps it's a thread critical for IO, or some driver, etc.).

That probably is the easiest solution.  Different cgroups can be
grouped together so we need to be a bit careful but if none of the
cgroups makes sense with kthread, we may just ban kthreads from any
cgroup.

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/