この記事はLinuxカーネルもくもく会 #24 - connpassで書いてます。今日は前に追加されたcgroupsのpid管理のコードを読んでみます。
ファイルはcgroup_pids.cです。Linux 4.7のコードを対象にします。
最初にデータ構造です。pidの場合はpids_cgroup構造体が使われます。この構造体はcgroup_pids.cで定義されています。
43 struct pids_cgroup { 44 struct cgroup_subsys_state css; 45 46 /* 47 * Use 64-bit types so that we can safely represent "max" as 48 * %PIDS_MAX = (%PID_MAX_LIMIT + 1). 49 */ 50 atomic64_t counter; 51 int64_t limit; 52 };
構造も結構スッキリしていて、今のPID数と上限、それにcgroup_subsys_state構造体です。cgroup_subsys_state構造体から親階層のpids_cgroupを取得したりします。
pid cgroupsで定義されている操作はcgroup_subsys構造体で定義します。css_alloc/css_free, can_attach/cancel_attach, can_fork/cancel_forkはペアですね。
306 struct cgroup_subsys pids_cgrp_subsys = { 307 .css_alloc = pids_css_alloc, 308 .css_free = pids_css_free, 309 .can_attach = pids_can_attach, 310 .cancel_attach = pids_cancel_attach, 311 .can_fork = pids_can_fork, 312 .cancel_fork = pids_cancel_fork, 313 .free = pids_free, 314 .legacy_cftypes = pids_files, 315 .dfl_cftypes = pids_files, 316 }; 317
pid cgroupsのファイルとしてはこれらのファイルがあります。
291 static struct cftype pids_files[] = {
292 {
293 .name = "max",
294 .write = pids_max_write,
295 .seq_show = pids_max_show,
296 .flags = CFTYPE_NOT_ON_ROOT,
297 },
298 {
299 .name = "current",
300 .read_s64 = pids_current_read,
301 .flags = CFTYPE_NOT_ON_ROOT,
302 },
303 { } /* terminate */
304 };
maxのほうは最大値を設定するファイルで読み(pids_max_show)書き(pids_max_write)可能です。currentの方は現在の値を表示するだけなので読み込み(pids_current_read)しか設定されていません。
これらのファイルはflagsにCFTYPE_NOT_ON_ROOTが設定されているので、pid cgroupのトップディレクトリには表示されません。
[root@miko user.slice]# ls -la /sys/fs/cgroup/pids total 0 dr-xr-xr-x 5 root root 0 Sep 16 02:36 ./ drwxr-xr-x 11 root root 260 Sep 16 02:35 ../ -rw-r--r-- 1 root root 0 Sep 16 02:36 cgroup.clone_children -rw-r--r-- 1 root root 0 Sep 16 02:36 cgroup.procs -r--r--r-- 1 root root 0 Sep 16 02:36 cgroup.sane_behavior drwxr-xr-x 2 root root 0 Sep 16 02:35 init.scope/ -rw-r--r-- 1 root root 0 Sep 16 02:36 notify_on_release -rw-r--r-- 1 root root 0 Sep 16 02:36 release_agent drwxr-xr-x 31 root root 0 Sep 16 02:35 system.slice/ -rw-r--r-- 1 root root 0 Sep 16 02:36 tasks drwxr-xr-x 3 root root 0 Sep 16 02:36 user.slice/
pid cgroupsの下の階層には存在します。pids.maxとpids.currentがそのファイルです。
[root@miko user.slice]# ls -la /sys/fs/cgroup/pids/user.slice total 0 drwxr-xr-x 3 root root 0 Sep 16 02:36 ./ dr-xr-xr-x 5 root root 0 Sep 16 02:36 ../ -rw-r--r-- 1 root root 0 Sep 16 02:36 cgroup.clone_children -rw-r--r-- 1 root root 0 Sep 16 02:36 cgroup.procs -rw-r--r-- 1 root root 0 Sep 16 02:36 notify_on_release -r--r--r-- 1 root root 0 Sep 16 02:36 pids.current -rw-r--r-- 1 root root 0 Sep 16 02:36 pids.max -rw-r--r-- 1 root root 0 Sep 16 02:36 tasks drwxr-xr-x 4 root root 0 Sep 16 02:36 user-1000.slice/
ファイルの内容はこんな感じです。
[root@miko user.slice]# cat pids.max max [root@miko user.slice]# cat pids.current 9
では、コードを適当に読んでいきます。まずはpids_css_alloc()。新しくサブシステムが作られる時に呼ばれます。個々で作成するのはcgroup_subsys_state構造体です。実際にはpids_cgroup構造体を作って、その中のcss変数を返しています。この辺はカーネル定番のcontainer_ofマクロの出番ですね。
64 static struct cgroup_subsys_state * 65 pids_css_alloc(struct cgroup_subsys_state *parent) 66 { 67 struct pids_cgroup *pids; 68 69 pids = kzalloc(sizeof(struct pids_cgroup), GFP_KERNEL); 70 if (!pids) 71 return ERR_PTR(-ENOMEM); 72 73 pids->limit = PIDS_MAX; 74 atomic64_set(&pids->counter, 0); 75 return &pids->css; 76 }
PIDS_MAXは↓のように定義されています。
40 #define PIDS_MAX (PID_MAX_LIMIT + 1ULL)
PID_MAX_LIMITはinclude/linux/threads.hにて↓のように決まります。
33 #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \ 34 (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
limit以外は初期値0って感じになります。
pids_css_free()はpids_css_allocで作ったpids_cgroup構造体のメモリをkfree()で解放するだけです。
次はpids_can_attach()です。この関数はプロセスがあるcgroupから別のcgroupに移動する時に呼ばれます。処理内容としては移動元のpid cgroupからPIDの使用数（counter）を減らして、新しいほうのPIDの使用数を増やします。
165 static int pids_can_attach(struct cgroup_taskset *tset) 166 { 167 struct task_struct *task; 168 struct cgroup_subsys_state *dst_css; 169 170 cgroup_taskset_for_each(task, dst_css, tset) { 171 struct pids_cgroup *pids = css_pids(dst_css); 172 struct cgroup_subsys_state *old_css; 173 struct pids_cgroup *old_pids; 174 175 /* 176 * No need to pin @old_css between here and cancel_attach() 177 * because cgroup core protects it from being freed before 178 * the migration completes or fails. 179 */ 180 old_css = task_css(task, pids_cgrp_id); 181 old_pids = css_pids(old_css); 182 183 pids_charge(pids, 1); 184 pids_uncharge(old_pids, 1); 185 } 186 187 return 0; 188 }
countを増やしたり減らしたりするのがpids_charge()とpids_uncharge()です。
pids_charge()はこのような処理で、階層を上位に移動しながら、pidのcounterを増やします。
122 static void pids_charge(struct pids_cgroup *pids, int num) 123 { 124 struct pids_cgroup *p; 125 126 for (p = pids; parent_pids(p); p = parent_pids(p)) 127 atomic64_add(num, &p->counter); 128 }
pids_uncharge()のほうは単純にいうとpids_charge()と逆の処理をします。実際にcounterの値を更新するのはpids_cancel()ですが。
pids_cancel_attach()はアタッチをキャンセルする処理で、やることは移動先のcounterを減らして移動元のcounterの値を増やします。
pids_can_fork()はfork/clone/vfork時にcopy_process()の途中で呼ばれます。cgroup_can_fork()がサブシステムのcan_fork()を呼び出す形です。
1567 retval = cgroup_can_fork(p); 1568 if (retval) 1569 goto bad_fork_free_pid;
そして、pids_can_fork()の処理ですが、これはpids_try_charge()を呼んでpid数の上限に達していないか確認し、問題なければ0を返します。上限に達している場合はEAGAINが返ります。なので、fork爆弾とかはここで上限値チェックに引っかかるんじゃないでしょうか。試してませんが。。。
pids_cancel_fork()はキャンセル処理なので増やしたcounterの値を減らします。
次に、pids.maxファイルへの書き込み時のpids_max_write()ですが、これは大方の予想通りなことしかしてません。 読み込みのときにmaxって文字列を出してましたが、これは条件があります。pids_max_show()で、pid cgroupに設定されているlimitがPIDS_MAX以上の場合はmaxという文字列が表示されます。
269 static int pids_max_show(struct seq_file *sf, void *v) 270 { 271 struct cgroup_subsys_state *css = seq_css(sf); 272 struct pids_cgroup *pids = css_pids(css); 273 int64_t limit = pids->limit; 274 275 if (limit >= PIDS_MAX) 276 seq_printf(sf, "%s\n", PIDS_MAX_STR); 277 else 278 seq_printf(sf, "%lld\n", limit); 279 280 return 0; 281 }
limitの初期値はPIDS_MAXなので、pids.maxを弄ってなければデフォルトはmaxになります。
pid cgroupはだいたいこれくらいですね。結構短くて読みやすいですね。
改訂3版 Linuxエンジニア養成読本 (Software Design plus)
- 作者: 養成読本編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2016/08/23
- メディア: 大型本
- この商品を含むブログ (1件) を見る
