瀬谷の海軍道路〜湘南〜みなとみらい 🚲

4/2 (日) 瀬谷の海軍道路〜湘南〜みなとみらいを走ってきた。ぴったり 100km

f:id:hiboma:20170403105549p:plain

多摩川

瀬谷の海軍道路

桜 がみたかったのだが …

nothing ! 花もねぇ つぼみもねぇ なんにもねぇ〜 来週が見頃かね

江ノ島 〜 鎌倉

18号線を南下して江ノ島に着。18号は路肩も広いし交通量もそこまで多くないので非常に走りやすい 🚲

みなとみらい

鎌倉からこぶりな峠をこえて金沢文庫に抜けて、みなとみらいまで向かってゴール

湾岸をうろつきながらクールダウン。途中、何かの映画かドラマかの撮影をやっていたのか 渡部篤郎を見かけた。車の中でじっと座っているだけなのに滲み出るイケメンオーラ。

町中華街駅から輪行で帰宅

グッド・チャリズム宣言プロジェクト

輪行でベテラン風のライダーさんと居合わせたので、声をかけてお話をしたのだが「グッド・チャリズム宣言プロジェクト」を運営されているとのことでプロジェクトのあれこれを教えてもらった。

good-charism.com

🚲 のマナーや交通ルールの啓蒙につとめているとのことで、ロードに乗り始めてまもない自分でもあれこれ思うところがあるので興味深く お話を拝聴した

山伏峠・正丸峠ライド

12/29 山伏峠と正丸峠をのぼってきた

2016年最後の自転車

名栗湖

謎の壁画前でぱちり

山伏峠

平均 6-7% ほどで距離も短く20-30分もあればのぼりきれる 小ぶりな峠 (早い人は十分台で登れるぽい)

小ぶりだけども、道路の状態が良く、大きく蛇行するカーブが連続していて、暗い杉林を越えたり急坂に建つ民家がみえたり、景色が常に変化するので飽きない

最後に 11-12% のカーブがあるので そこを踏ん張れたらゴール

峠に達しても景色がイマイチなのが惜しい(景色を求めるなら正丸峠に行こう)

正丸峠

山伏峠に来たら消化試合的に正丸峠ものぼる

さすがにお茶屋は閉店している

遠くに新宿の高層ビル群が見える。iPhone のカメラでは捉えられない ?

芦ヶ久保

帰りは電車。秩父まで降りたかったけど、時間が無いので芦ヶ久保から輪行。寒くて指がかじかんで袋詰めが大変

1時間半ほどで最寄り駅に到着。お疲れ様でした

ミドルウェア: abrtd (2)

前回の続き 。abrtd で カーネルパニック時の vmcore を採取する

まとめ

検証作業をしてみた結果、正確には、

  • kdump が起動していて、
  • カーネルパニック後に kdump で vmcore を採取できた場合、
  • 再起動後に vmcore + 予備情報を /var/crash 以下にまとめてくれる

と理解した。abrtd が全部よしなにやってくれると思ってしまったが、vmcore を採取するのは kdump の仕事だった。

kdump の設定

kdump.service の準備が必要。 Red Hat のドキュメントを読もう

Red Hat Enterprise Linux - カーネルクラッシュダンプガイド - 2.2. コマンドラインで KDUMP を設定する

tips: Vagrant + CentOS7 で試す場合

crashkernel=auto でハマないように!

repl.info

設定変更

検証作業なので grub2 設定をシェルで書き換えていく

$ sudo systemctl enable kdump.service
$ sudo perl -i'.bak' -nlpe 's/crashkernel=auto/crashkernel=128M/' /etc/default/grub 
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sync
$ sudo reboot

reboot 後に kdump の status を確認しよう

$ sudo systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since 日 2016-12-25 07:32:46 EST; 14h ago
  Process: 1758 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 1758 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/kdump.service

1225 07:32:30 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming...
1225 07:32:46 localhost.localdomain kdumpctl[1758]: kexec: loaded kdump kernel
1225 07:32:46 localhost.localdomain kdumpctl[1758]: Starting kdump: [OK]
1225 07:32:46 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.

カーネルパニックを起こす

kdump の用意ができたら echo c > /proc/sysrq-trigger秘孔を突いて カーネルパニックを起こす

$ echo c | sudo tee  /proc/sysrq-trigger

VM が再起動した後に、ログインして abrt-cli でレポートを一覧する

不備が無ければ BUG: unable to handle kernel NULL pointer dereference at (null) がキャッチされているはず

$ sudo abrt-cli ls
id 5f8ee8234bfdd61810b08d481291fa5d07ef4a6d
reason:         BUG: unable to handle kernel NULL pointer dereference at           (null)
time:           Sun Dec 25 21:50:39 2016
uid:            0 (root)
count:          1
Directory:      /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42
Reported:       cannot be reported

/var/spool/abrt 以下には下記のようなデータが採取されている

$ sudo ls -hal /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42
total 33M
drwx------. 2 root root 4.0K Dec 25 21:51 .
drwxr-x--x. 5 root abrt 4.0K Dec 25 21:50 ..
-rw-------. 1 root root    6 Dec 25 21:50 analyzer
-rw-------. 1 root root    6 Dec 25 21:50 architecture
-rw-------. 1 root root 2.9K Dec 25 21:50 backtrace
-rw-------. 1 root root    6 Dec 25 21:50 component
-rw-------. 1 root root    1 Dec 25 21:50 count
-rw-------. 1 root root    0 Dec 25 21:50 event_log
-rw-------. 1 root root   25 Dec 25 21:50 kernel
-rw-------. 1 root root   76 Dec 25 21:50 kernel_tainted_long
-rw-------. 1 root root    3 Dec 25 21:50 kernel_tainted_short
-rw-------. 1 root root   10 Dec 25 21:50 last_occurrence
-rw-------. 1 root root  135 Dec 25 21:50 machineid
-rw-------. 1 root root  131 Dec 25 21:50 not-reportable
-rw-------. 1 root root  393 Dec 25 21:50 os_info
-rw-------. 1 root root   38 Dec 25 21:50 os_release
-rw-------. 1 root root   73 Dec 25 21:50 reason
-rw-------. 1 root root    4 Dec 25 21:50 runlevel
-rw-------. 1 root root   10 Dec 25 21:50 time
-rw-------. 1 root root    6 Dec 25 21:50 type
-rw-------. 1 root root    1 Dec 25 21:50 uid
-rw-------. 1 root root    5 Dec 25 21:50 username
-rw-------. 1 root root   40 Dec 25 21:50 uuid
-rw-------. 1 root root  33M Dec 25 07:38 vmcore
-rw-------. 1 root root  35K Dec 25 07:38 vmcore-dmesg.txt

それぞれのファイルの詳細は https://gist.github.com/hiboma/431d0a5e3e8fe8a1a2b699a71e61abf9 にまとめた。vmcore が取れていれば crash を使って原因の解析ができる

vmcore が残る

ところで /var/crash 以下にも kdump が採取した vmcore が残っている

# /var/crash 
$ sudo ls -hali /var/crash/127.0.0.1-2016-12-25-07\:38\:42/vmcore
310061 -rw-------. 1 root root 33M Dec 25 07:38 /var/crash/127.0.0.1-2016-12-25-07:38:42/vmcore

# /var/spool/abrtd にも残ってる
$ sudo ls -hali /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42/vmcore
19216963 -rw-------. 1 root root 33M Dec 25 07:38 /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42/vmcore

vmcore のサイズが大きい場合に、内容が同じ vmcore が重複するのはもったいない。設定で回避できるだろうか?


abrtd にはクラッシュをレポートする機能 (libreport) もついている。次回以降でまとめる

ミドルウェア: abrtd

abrtd の素振りログを残す。調べてみてもあんまりエントリ無いので、ここに書いたことで誰かの何かの足しになろう

abrtd を使うことで SIGSEGV を受けたプロセスのコアの収集や、カーネルパニックを起こした際の vmcore の収集を自動化できる

検証環境

リファレンス

https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-abrt.html

インストールと起動

sudo yum install abrt-cli
sudo systemctl enable abrtd.service
sudo systemctl start abrtd
UNIT FILE                                     STATE   
abrt-ccpp.service                             enabled 
abrt-oops.service                             enabled 
abrt-pstoreoops.service                       disabled
abrt-vmcore.service                           enabled 
abrt-xorg.service                             enabled 
abrtd.service                                 enabled 

検証なので puppet や chef は使わずに手作業でペペっと

プロセスを SIGSEGV で kill する

22.2. ABRT のインストールとそのサービスの起動 の手順をなぞって試す。sleep プロセスを SIGSEGV で kill して動作を確かめるとよいらしい

$ sleep 100 &
[1] 2954
$ kill -SEGV 2954
$ fg
-bash: fg: job has terminated
[1]+  Segmentation fault      (core dumped) sleep 100

/var/log/messages にログが残る

Dec 15 10:53:21 localhost abrt-hook-ccpp: Process 2954 (sleep) of user 1000 killed by SIGSEGV - dumping core

abrt-cli list で abrtd がキャッチしたクラッシュを一覧できる

$ sudo abrt-cli list
id 3cd5767798e6794fa2593aa1ee29f52c91e41818
reason:         sleep killed by SIGSEGV
time:           Thu Dec 15 10:53:21 2016
cmdline:        sleep 100
package:        coreutils-8.22-18.el7
uid:            1000 (vagrant)
count:          1
Directory:      /var/spool/abrt/ccpp-2016-12-15-10:53:21-2954

The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges

さらに /var/spool/abrt/ にプロセス実行時のあれこれのデータが残る

$ sudo ls -hal /var/spool/abrt/ccpp-2016-12-15-10:53:21-2954
total 312K
drwxr-x---. 2 root abrt 4.0K Dec 15 11:08 .
drwxr-x--x. 4 root abrt   94 Dec 15 11:03 ..
-rw-r-----. 1 root abrt    6 Dec 15 10:53 abrt_version
-rw-r-----. 1 root abrt    4 Dec 15 10:53 analyzer
-rw-r-----. 1 root abrt    6 Dec 15 10:53 architecture
-rw-r-----. 1 root abrt  190 Dec 15 10:53 cgroup
-rw-r-----. 1 root abrt    9 Dec 15 10:53 cmdline
-rw-r-----. 1 root abrt    9 Dec 15 10:53 component
-rw-r-----. 1 root abrt 1.3K Dec 15 10:53 core_backtrace
-rw-r-----. 1 root abrt 376K Dec 15 10:53 coredump
-rw-r-----. 1 root abrt    1 Dec 15 10:55 count
-rw-r-----. 1 root abrt  298 Dec 15 10:53 dso_list
-rw-r-----. 1 root abrt 2.3K Dec 15 10:53 environ
-rw-r-----. 1 root abrt    0 Dec 15 10:53 event_log
-rw-r-----. 1 root abrt   14 Dec 15 10:53 executable
-rw-r-----. 1 root abrt    4 Dec 15 10:53 global_pid
-rw-r-----. 1 root abrt   21 Dec 15 10:53 hostname
-rw-r-----. 1 root abrt   25 Dec 15 10:53 kernel
-rw-r-----. 1 root abrt   10 Dec 15 10:55 last_occurrence
-rw-r-----. 1 root abrt 1.3K Dec 15 10:53 limits
-rw-r-----. 1 root abrt  135 Dec 15 10:53 machineid
-rw-r-----. 1 root abrt 1.6K Dec 15 10:53 maps
-rw-r-----. 1 root abrt  138 Dec 15 10:53 open_fds
-rw-r-----. 1 root abrt  393 Dec 15 10:53 os_info
-rw-r-----. 1 root abrt   37 Dec 15 10:53 os_release
-rw-r-----. 1 root abrt   21 Dec 15 10:53 package
-rw-r-----. 1 root abrt    4 Dec 15 10:53 pid
-rw-r-----. 1 root abrt    6 Dec 15 10:53 pkg_arch
-rw-r-----. 1 root abrt    1 Dec 15 10:53 pkg_epoch
-rw-r-----. 1 root abrt   19 Dec 15 10:53 pkg_fingerprint
-rw-r-----. 1 root abrt    9 Dec 15 10:53 pkg_name
-rw-r-----. 1 root abrt    6 Dec 15 10:53 pkg_release
-rw-r-----. 1 root abrt    6 Dec 15 10:53 pkg_vendor
-rw-r-----. 1 root abrt    4 Dec 15 10:53 pkg_version
-rw-r-----. 1 root abrt 1.2K Dec 15 10:53 proc_pid_status
-rw-r-----. 1 root abrt   13 Dec 15 10:53 pwd
-rw-r-----. 1 root abrt   23 Dec 15 10:53 reason
-rw-r-----. 1 root abrt    4 Dec 15 10:53 runlevel
-rw-r-----. 1 root abrt   10 Dec 15 10:53 time
-rw-r-----. 1 root abrt    4 Dec 15 10:53 type
-rw-r-----. 1 root abrt    4 Dec 15 10:53 uid
-rw-r-----. 1 root abrt    8 Dec 15 10:53 username
-rw-r-----. 1 root abrt   40 Dec 15 10:53 uuid
-rw-r-----. 1 root abrt  155 Dec 15 10:53 var_log_messages

各ファイルの詳細は長いので gist にまとめた https://gist.github.com/hiboma/5b7caa8e0a4a9e3254aeda9d86b86a72

自作のバイナリでのテスト

こんな C のコードを書いてテストをした

static int i = 0;

int main() {
    char buffer[16];

    for(;;) 
        buffer[i++] = 'a';
}

実行するとインデックスでの参照がスタック領域を超えページフォルトを起こし、SIGSEGV で kill される

/var/log/messages にログが残るが、先ほどとは内容が違う

Dec 15 10:57:09 localhost kernel: a.out[3057]: segfault at 7fff75726000 ip 0000000000400502 sp 00007fff75724710 error 6 in a.out[400000+1000]
Dec 15 10:57:09 localhost abrt-hook-ccpp: Process 3057 (a.out) of user 1000 killed by SIGSEGV - dumping core
Dec 15 10:57:09 localhost abrt-hook-ccpp: Failed to create core_backtrace: dwfl_getthread_frames failed: No DWARF information found
Dec 15 10:57:09 localhost abrt-server: Executable '/home/vagrant/a.out' doesn't belong to any package and ProcessUnpackaged is set to 'no'
Dec 15 10:57:09 localhost abrt-server: 'post-create' on '/var/spool/abrt/ccpp-2016-12-15-10:57:09-3057' exited with 1
Dec 15 10:57:09 localhost abrt-server: Deleting problem directory '/var/spool/abrt/ccpp-2016-12-15-10:57:09-3057'

RPM として提供されていないバイナリの場合は ProcessUnpackaged を yes にしておかないと abrtd の採取対象とならないようだ

$ sudo perl -i'' -nlpe 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/' /etc/abrt/abrt-action-save-package-data.conf

再度同じ手順を踏むと abrtd がキャッチしてくれた (設定変更後の abrtd の再起動はいらないみたい)

$ sudo abrt-cli list
id 856651691a20719d3e5387eda67265af645f64da
reason:         a.out killed by SIGSEGV
time:           Thu Dec 15 11:02:27 2016
cmdline:        aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
uid:            1000 (vagrant)
count:          2
Directory:      /var/spool/abrt/ccpp-2016-12-15-11:02:27-3114

The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges

おおっと cmdline: が aaaaaa … になっている。バッファオーバーフローで argv[0] のスタックまで破壊してしまったせいだろう。これはこれで知見だ


abrtd には様々なオプションや拡張が用意されているが とりあえずここまで

トレーニングライド: 稲城〜聖蹟桜ヶ丘

またもや お布団峠 を越えられず午後から出走

稲城聖蹟桜ヶ丘らへんの丘を負荷をかけてのぼって、のんびりおりて、終わり

多摩川

続きを読む

ソースコードリーディング: static void init_once(void *foo)

カーネルトリビア

Linux カーネルのソース (CentOS7) を読んでいると、下記のようなコードを見つけた

static void init_once(void *foo)
{
         struct socket_alloc *ei = (struct socket_alloc *)foo;
 
         inode_init_once(&ei->vfs_inode);
}

変数名が foo とは ... 何とも適当ぽい。もうちょっと調べてみると他の箇所にもある

static void init_once(void *foo)
{
        struct ext4_inode_info *ei = (struct ext4_inode_info *) foo;

        INIT_LIST_HEAD(&ei->i_orphan);
        init_rwsem(&ei->xattr_sem);
        init_rwsem(&ei->i_data_sem);
        init_rwsem(&ei->i_mmap_sem);
        inode_init_once(&ei->vfs_inode);
}

GNU global でリストしてみると いろんなファイルシステムで同様の宣言が見られる

init_once         262 fs/adfs/super.c  static void init_once(void *foo)
init_once         127 fs/affs/super.c  static void init_once(void *foo)
init_once         298 fs/befs/linuxvfs.c static void init_once(void *foo)
init_once         262 fs/bfs/inode.c   static void init_once(void *foo)
init_once         412 fs/block_dev.c   static void init_once(void *foo)
init_once        8670 fs/btrfs/inode.c static void init_once(void *foo)
init_once          69 fs/coda/inode.c  static void init_once(void *foo)
init_once          80 fs/efs/super.c   static void init_once(void *foo)
init_once         183 fs/ext2/super.c  static void init_once(void *foo)
init_once         506 fs/ext3/super.c  static void init_once(void *foo)
init_once         936 fs/ext4/super.c  static void init_once(void *foo)
init_once          72 fs/f2fs/super.c  static void init_once(void *foo)
init_once          40 fs/fat/cache.c   static void init_once(void *foo)
init_once         594 fs/fat/inode.c   static void init_once(void *foo)
init_once         192 fs/hpfs/super.c  static void init_once(void *foo)
init_once         711 fs/hugetlbfs/inode.c static void init_once(void *foo)
init_once         383 fs/inode.c       static void init_once(void *foo)
init_once          89 fs/isofs/inode.c static void init_once(void *foo)
init_once         186 fs/jfs/jfs_metapage.c static void init_once(void *foo)
init_once         860 fs/jfs/super.c   static void init_once(void *foo)
init_once          82 fs/minix/inode.c static void init_once(void *foo)
init_once          70 fs/ncpfs/inode.c static void init_once(void *foo)
init_once        1832 fs/nfs/inode.c   static void init_once(void *foo)
init_once          94 fs/proc/inode.c  static void init_once(void *foo)
init_once         373 fs/qnx4/inode.c  static void init_once(void *foo)
init_once         633 fs/qnx6/inode.c  static void init_once(void *foo)
init_once         589 fs/reiserfs/super.c static void init_once(void *foo)
init_once         408 fs/squashfs/super.c static void init_once(void *foo)
init_once         332 fs/sysv/inode.c  static void init_once(void *p)
init_once         155 fs/udf/super.c   static void init_once(void *foo)
init_once        1449 fs/ufs/super.c   static void init_once(void *foo)
init_once         346 ipc/mqueue.c     static void init_once(void *foo)
init_once         282 net/socket.c     static void init_once(void *foo)
init_once        1495 net/sunrpc/rpc_pipe.c init_once(void *foo)
init_once         148 security/integrity/iint.c static void init_once(void *foo)

static void init_once(void *foo) は kmem_cache_create() に渡す関数ポインタとして利用されていて、みな同じ宣言になっている。

所謂 foo bar foo なんだろうけど、他になんか意味があるのかなぁ ... とか勘ぐりを入れてしまう。ただ単に最初にコミットされたコードが そのまま伝染しているのかもしれない。いや、やっぱり foo は構成員のみが知り得る特殊な暗号としての意味が潜んでいて ... (考え過ぎ)

Linux カーネルと言えど「あれ、こんなんでいいのかな???」という変数名 やコメント(時にはジョーク) が混じっていたりして おおらかな気分になれる。他にもいろいろあった気がしたので、思い出したらここに書こう

man-pages 4.09 のリリース

ちょっと前から linux-man の ML を読み始めたのだけど、 man-pages 4.09 のリリースがお知らせされていた

linux-man-pages.blogspot.jp

リリースの内容

詳細はリンク先をみてもらえばよいが、更新内容は Linux Kernel 4.9 で追加された新しいシステムコールを対象にした man もあれば、新しいものに限らず下のように広範なトピックがはいっている。コミットだけで見ると typo fix やスタイル調整も結構な量があるようだ

自分の関心をひいたのは以下の更新

A new pkey_alloc(2) page, written by Dave Hansen, documents the pkey_alloc() and pkey_free() system calls added in Linux 4.9.

4.9 で追加された pkey_alloc(2) 共有ホスティングのようなとこで何か利用できないか? (e.g. mod_process_security )

A new fuse(4) page, written by Keno Fischer, partially documents the /dev/fuse device.

/dev/fuse について。ここ最近、社内外で fuse をハックした実装をよく見かけていたが /dev/fuse そのもの実装をおいたかったのでタイムリ

A new sock_diag(7) page, written by Pavel Emelyanov and Dmitry V. Levin, documents the NETLINK_SOCK_DIAG interface.

sock_diag(7) - Linux manual page socket の内部情報を取るための NETLINK_SOCK_DIAG インタフェースについて。UNIX ドメインソケットのバックログサイズを netlink インタフェースで計測してみたかったのだけど使い方がわからず頓挫していた調査があったので、これもタイムリ

A new tmpfs(5) page, written by me, provides an overview of the tmpfs filesystem.

tmpfs について。内部実装は System V 共有メモリの anon なページの mmap(2) でも使われている点への言及など

リリースの間隔

man-pages の過去リリースを見ると、 kernel のマイナーバージョン更新 (今回は 4.8 -> 4.9 ) にタイミングを合わせているよな感じ

kernel man-pages
4.9 - Sun, 11 Dec 2016 4.09 - Mon, 12 Dec 2016
4.8 - Sun, 2 Oct 2016 4.08 - Sat, 8 Oct 2016
4.7 - Sun, 24 Jul 2016 4.07 - Sun, 17 Jul 2016
4.6 - Sun, 15 May 2016 4.06 - Wed, 11 May 2016

? バージョニングも揃ってるぽいので、後で過去ログを調べてみよう

man-pages のメンテナについて

このエントリを書くまで認知していなかったのだが、 man-pages のメンテンナである Michael Kerrisk さんは 『Linuxプログラミングインタフェース』本の著者でもあって「ああ なるほど」である

Linuxプログラミングインタフェース

Linuxプログラミングインタフェース

厚い