linux-kernel - Re: [PATCH] cgroup: Show control files in cgroup2 root after mount

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:   Tue, 18 Jul 2017 16:50:10 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Waiman Long <longman@...hat.com>
Cc:     Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cgroup: Show control files in cgroup2 root after mount

Hello,

On Tue, Jul 18, 2017 at 04:29:40PM -0400, Waiman Long wrote:
> I think the kernfs_activate() call is for the cgroup1 mount of debug

kernfs_activate() there is for any files which are created while a
controller moves between hierarchies, so, yeah, during boot, this is
where the root files for cgroup1 hierarchies would be activated.

> cgroup which probably failed as I put debug in the cgroup_no_v1= option.

Yeah, they just get skipped over.

> The RHEL7 system that I ran the test on tried to do v1-mount of all the
> cgroup controllers available. I am also wondering how a v1-mount of
> debug controller will make the controller files appear on cgroup2 root.
> Maybe I miss something in the code.

When a controller gets mounted on v1, the controller is detached from
cgroup2 hierarchy, so the corresponding files are removed from v2 root
and then created on v1, which are activated by the kernfs_activate()
call at the end of rebind.

> My test kernel was built out of your latest cgroup git tree with the
> thread mode patches on (review-cgroup2-threads-v3 branch).

I see.  I'm testing with the same kernel.

> As I said above, I put in the kernel command line option
> "cgroup_no_v1=pids,debug,memory". Then I mounted the cgroup2 filesystem
> after boot.
> 
> # mount -t cgroup2 cgroup2 /cgroup2
> # ls /cgroup2/
> cgroup.controllers  cgroup.procs  cgroup.subtree_control  cgroup.threads
> # echo +memory > /cgroup2/cgroup.subtree_control
> # ls /cgroup2/
> cgroup.controllers    debug.current_css_set
> cgroup.procs        debug.current_css_set_cg_links
> cgroup.subtree_control    debug.current_css_set_refcount
> cgroup.threads        debug.masks
> debug.csses        debug.taskcount
> debug.css_links

Heh, I'm really confused.  If I do the same thing, I get the following
result which makes sense as the files would be activated in
cgroup_apply_cftypes() when the debug controller is registered during
boot.

 # mkdir /cgroup2
 # mount -t cgroup2 cgroup2 /cgroup2
 # ls /cgroup2/
 cgroup.controllers      debug.current_css_set
 cgroup.procs            debug.current_css_set_cg_links
 cgroup.subtree_control  debug.current_css_set_refcount
 cgroup.threads          debug.masks
 debug.csses             debug.taskcount
 debug.css_links

Thanks.

-- 
tejun