linux-kernel - Re: [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking

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, 18 Oct 2012 15:35:17 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Matt Helsley <matthltc@...ux.vnet.ibm.com>
Cc:	rjw@...k.pl, oleg@...hat.com, cgroups@...r.kernel.org,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration
 regardless of freezer state and update locking

Hello, Matt.

On Thu, Oct 18, 2012 at 03:21:55PM -0700, Matt Helsley wrote:
> > Hmmm?  Nothing prevents kthreads from being moved around.  We only
> > recently added the restriction to prevent migration of the kthreadd
> > (the one which creates other kthreads).  You can reproduce it with
> > khungtask or any other !freezable kthreads.
> 
> Ok. I don't immmediately see why that'd be a good idea but it's
> possible..

Beats me too.  There were talks about restricting all kthreads from
being moved out of the root cgroup.  Dunno.  Maybe.

> <off_topic>
> "Whoever" did the freeze needs a way to "lock" access to the freezer state,
> change the freezer state itself, do something (e.g. CRIU) which relies on
> the state not changing, and then release the lock. Plus the lock has to be
> released by the kernel if "Whoever" dies without the chance to release it.
> So I was thinking who holds the lock and its lifetime could be represented
> in userspace by file descriptor(s).
> </off_topic>

Long term, I don't think it's feasible to continue to use cgroup
kernel interface as the multiplexing layer among different users.
cgroup core simply doesn't have enough context or infrastructure to
support such usages.  It's somewhere between being a pure interface to
the provided kernel feature and fully multiplexed interface which
userland applications can depend on for arbitration.  It tries to have
the appearance of the latter but fails.

I think the only sane way would be having a userland arbitrator which
owns the kernel interface to itself and makes policy decisions from
userland clients and configures cgroup accordingly.

> > As for CRIU, it isn't using cgroup freezer at the moment because
> > frozen tasks can't be ptraced currently.  Something I'm hoping to
> > change but not sure when it can be done.
> 
> OK, but that doesn't mean the frozen nature of the task list itself
> won't be useful in the future.

I think that should be solved via userland policies rather than
depending on this accidental cgroup_freezer feature.

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/