システムコール、プロセスとtask_struct構造体

					2019年01月11日
情報科学類 オペレーティングシステム II

                                       筑波大学 システム情報系 
                                       新城 靖
                                       <yas@cs.tsukuba.ac.jp>

このページは、次の URL にあります。
http://www.coins.tsukuba.ac.jp/~yas/coins/os2-2018/2019-01-11
あるいは、次のページから手繰っていくこともできます。
http://www.coins.tsukuba.ac.jp/~yas/
http://www.cs.tsukuba.ac.jp/~yas/

■連絡事項

2019/01/11 15:00: レポート(宿題)の問題(103) Ready状態のプロセスの間違いを修正しました。「Ready 状態」について回答して下さい。
2019/01/11 15:00: レポート(宿題)の問題(105) getgidシステム・コールを修正しました。UIDではなくGIDにしました。

■今日の大事な話

システム・コールとライブラリの共通点と相違点
トラップ命令
strace コマンド
プロセスの構造
- PID (process identifier), UID, groups
- task_struct 構造体
- 状態(state)
- current 変数

◆参考書

Robert Love: "Linux Kernel Development", Addison-Wesley Professional (2010). ISBN-13: 9780672329463

Claudia Salzberg Rodriguez, Gordon Fischer, and Steven Smolski: "The Linux Kernel Primer: A Top-Down Approach for x86 and PowerPC Architectures", Prentice Hall (2005). ISBN-10: 0131181637

Daniel P. Bovet, Marco Cesati 著, 高橋浩和 (監訳), 杉田由美子, 清水正明 , 高杉昌督 , 平松雅巳 , 安井隆宏(訳) 詳解 Linuxカーネル第3版オライリー・ジャパン (2007). ISBN-13: 978-4873113135

Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman (著), 山崎康宏 , 山崎邦子 , 長原宏治 , 長原陽子(訳): "Linuxデバイスドライバ", オライリージャパン (2005). ISBN-13: 978-4873112534

■オペレーティングシステムII

◆この授業の狙い

「オペレーティングシステムI」の理論を実践へ
ハードウェアとソフトウェアのインタラクションを知る
実際のOSのソースコードに慣れる

◆この授業を受ける意義

将来、オペレーティング・システム・カーネルをいじる、特にデバイス・ドライバを書く時の基礎的な知識を得る。
OSの仕組みを知ることでOSをうまく使えるようになる。
身近の、複雑で、比較的大きい、難易度が高いプログラムに触れる。
メタレベルのプログラミングを意識してみる。 OSは、普通のプログラムのメタレベルのプログラム。

将来カーネルをいじる人もいじらない人にも意義がある。

◆メタレベルのプログラム

インタプリタ言語を考える。例：Ruby。

$ ls -l hello.rb  
-rw-r--r-- 1 yas prof 26 Dec  7 06:35 hello.rb
$ cat hello.rb  
printf("hello, world!\n")
$ ruby hello.rb  
hello, world!
$

Ruby 言語のインタプリタ自身は、C 言語で記述されている。

rubyのCのソース（メタ）、コンパイル＆リンク、実行形式、プロセス、hello.rbソース（プログラム）
図? メタレベルのプログラミング

プログラム「hello.rb」の動きを変更する方法

プログラミング: hello.rb を書き換える
メタレベルのプログラミング: ruby インタプリタのプログラムを書き換える

「hello.rb」は、ruby インタプリタから見ると、入力「データ」の１つ。

◆メタレベルのプログラムとしてのOS

$ ls -l hello.c 
-rw-r--r-- 1 yas prof 44 Dec  7 06:25 hello.c
$ cat hello.c 
main()
{
        printf("hello, %s!\n","world");
}
$ cc hello.c -o hello 
$ ./hello  
hello, world!
$

プロセス、カーネル（メタ）、ハードウェア（メタメタ）
図? メタレベルのプログラムとしてのOSカーネル

プログラム「hello.c」の動きを変更する方法

プログラミング: hello.c を書き換える
メタレベルのプログラミング: OSカーネルのプログラムを書き換える

「hello(実行形式)」は、OSカーネルから見ると、入力「データ」に相当する。

OSカーネル自身は、普通は、ハードウェアによるインタプリタ(CPU、入出力)で実行される。インタフェースは、機械語命令や入出力機器への操作。

OSカーネルへのインタフェースは、システム・コール。 == OSカーネルは、システム・コールのインタプリタ。

◆シラバス

◆Linux

教材としては、Linux を使う。

2年生の科目「システムプログラミング序論」との連携。
ソースコードが公開されている。
研究開発でよく使われる。
道具がそろっている。

2019年1月現在、学類では次のコンピュータで Linux が使える。

iMac
- abelia01-abelia50, borage01-borage50, crocus01-crocus40。 MacOSX 10.9, Windows 8.1, Linux (CentOS 6.10) の multi-boot。普段は、MacOSX が動いている。MacOSX にログインする前に CentOS を選択する。
PC
- dahlia01 - dahlia30。Windows 8.1 と Linux (CentOS 6.7) の dual boot。起動時に CentOS を選択する。
サーバ
- pentas-comp{a,b,c,d,e,f}
- violet-nwa (www), その他

サーバには、ssh でログインして使う。

■システム・コールとライブラリ

システム・コールとライブラリは、プログラマにとってのオペレーティング・システム。共通点は、両方とも、Ｃ言語からは、関数呼出しの形で使えること。 2つを合わせて、API (Application Programming Interface) とも言う。

◆OSの構造

図? 3層、複数コンポーネント
図? OSの構造

プログラム・コードの場所

システム・コール: カーネルに含まれている。
ライブラリ: アプリケーションのプログラムに「リンク」されている。

◆システム・コールのライブラリの違い

システム・コール(system call)

カーネル（システム）のプログラムを直接的に利用する。
最小を目指して設計する。
プロセスの外に働きかける。
実装で特権命令が使える。

ライブラリ(library)

カーネルの機能を直接的には使わないもの。(システム・コールの力を借りて間接的に使うことはある。)
便利さを目指す。
(システム・コールの助けがなければ)メモリの内容を書き換えるだけ。
実装で特権命令が使えない。

システムコールの例：

open(), close(), read(), write()

ライブラリの例：

memcpy(), memset(), strcmp()
fopen(), fclose(), fread(), fwrite()
printf(), fgets(), getchar()

システムコールとライブラリの見分け方（Unix編）

マニュアルの２章にあればシステムコール。例: READ(2)
マニュアルの３章にあればライブラリ関数。例: PRINTF(3)

同じUnix系OSでも、細かい所でシステム・コールとライブラリが入れ替わっていることもある。

システム・コールは、トラップ命令（trap instruction）を含む。その部分は、アセンブリ言語。

ライブラリ関数は、大部分はＣ言語で書かれている。 printf() のソース・プログラムがある。

Ｃ言語で記述したプログラムは、文法さえあっていればコンパイルはできる。ライブラリ関数やシステムコールがないと動作しない。

◆リンク

ライブラリやシステム・コールは、コンパイルされてオブジェクト・コードの形で保存されている。実行形式を作る時に取り出され、アプリケーション・プログラマから作成したオブジェクト・コード（main()関数など）と結合（リンク）される。

静的リンク(static link): プログラムを実行する前(実行形式を作成する時点)で、ライブラリ関数の呼出しをすべて機械語の手続き呼び出し命令に変換する。データへの参照を固定番地に変換する。
動的リンク(dynamic link): プログラムを実行中に必要に応じてリンクを行う。

動的リンクを行う時には、共有ライブラリ(shared library) を使い、メモリの節約をする。

Microsoft Windows では、システムコールとライブラリの区別が希薄。 Win32 API。3000以上。 Unix のシステムコールは、300程度。

◆hello.cとgcc -S

main()
{
	printf("hello, %s!\n","world");
}

$ ls hello*   
hello.c
$ make hello    
cc     hello.c   -o hello
hello.c: In function 'main':
hello.c:3: warning: incompatible implicit declaration of built-in function 'printf'
$ ./hello  
hello, world!
$ gcc -m32 -S hello.c 
hello.c: In function 'main':
hello.c:3: warning: incompatible implicit declaration of built-in function 'printf'
$ ls hello* 
hello  hello.c  hello.s
$

「gcc -m32 -S hello.c」のように、「-S」オプションをつけると、通常は削除されるアセンブリ言語の出力が残される。「-m32」は、32ビットのコードを出力させるためのオプション。

	.file	"hello.c"
	.section	.rodata
.LC0:
	.string	"world"
.LC1:
	.string	"hello, %s!\n"
	.text
.globl main
	.type	main, @function
main:
	pushl	%ebp
	movl	%esp, %ebp
	andl	$-16, %esp
	subl	$16, %esp
	movl	$.LC0, 4(%esp)
	movl	$.LC1, (%esp)
	call	printf
	leave
	ret
	.size	main, .-main
	.ident	"GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-4)"
	.section	.note.GNU-stack,"",@progbits

アセンブリ言語の出力には、main() 関数のみが含まれている。 printf() 関数は含まれていない。
C言語で printf() の呼び出しは、アセンブリ言語レベルでは、call 命令になっている。

◆printf() のソース・プログラム

~yas/os2/glibc-2.12/stdio-common/printf.c

＜省略＞
  28:	int
  29:	__printf (const char *format, ...)
  30:	{
  31:	  va_list arg;
  32:	  int done;
  33:	
  34:	  va_start (arg, format);
  35:	  done = vfprintf (stdout, format, arg);
  36:	  va_end (arg);
  37:	
  38:	  return done;
  39:	}
＜省略＞
  42:	ldbl_strong_alias (__printf, printf);

vfprintf() を呼んでいる。フォーマッティングは、共通。最後は (stdout なので)write() システム・コールが呼ばれる。
va_start(), va_end(), va_arg() は可変長の引数を扱うマクロ。man ページ va_start(3) 参照。

PRINTF(3)                  Linux Programmer's Manual                 PRINTF(3)

NAME
       printf,   fprintf,  sprintf,  snprintf,  vprintf,  vfprintf,  vsprintf,
       vsnprintf - formatted output conversion
SYNOPSIS
...
       int printf(const char *format, ...);
       int fprintf(FILE *stream, const char *format, ...);
...
       int vfprintf(FILE *stream, const char *format, va_list ap);
...
DESCRIPTION
...
       The functions vprintf(), vfprintf(), vsprintf(), vsnprintf() are equiv-
       alent  to  the  functions  printf(),  fprintf(), sprintf(), snprintf(),
       respectively, except that they are called with a va_list instead  of  a
       variable  number  of  arguments. These functions do not call the va_end
       macro. Consequently, the value of ap is undefined after the  call.  The
       application should call va_end(ap) itself afterwards.
...

◆write()システム・コールのマニュアル

WRITE(2)                   Linux Programmer's Manual                  WRITE(2)

NAME
       write - write to a file descriptor

SYNOPSIS
       #include <unistd.h>

       ssize_t write(int fd, const void *buf, size_t count);

DESCRIPTION
       write()  writes  up  to  count bytes to the file referenced by the file
       descriptor fd from the buffer starting at buf.  POSIX requires  that  a
       read()  which  can  be  proved  to  occur  after a write() has returned
       returns the new data.  Note that not all file systems  are  POSIX  con-
       forming.

RETURN VALUE
       On  success,  the  number of bytes written are returned (zero indicates
       nothing was written).  On error, -1  is  returned,  and  errno  is  set
       appropriately.   If  count  is zero and the file descriptor refers to a
       regular file, 0 may be returned, or an error could be detected.  For  a
       special file, the results are not portable.

ERRORS
       EAGAIN Non-blocking  I/O  has  been  selected  using O_NONBLOCK and the
              write would block.

       EBADF  fd is not a valid file descriptor or is not open for writing.
...

◆write()システム・コール(ユーザ空間)

x86 アーキテクチャ(32ビット)の write.o 逆アセンブル結果より、主要部分抜粋。　

write:
	...
	push   %ebx		# ebxレジスタの内容をスタックへ退避
	mov    0x10(%esp),%edx	# 第3引数をレジスタ edx へ
	mov    0xc(%esp),%ecx	# 第2引数をレジスタ ecx へ
	mov    0x8(%esp),%ebx	# 第1引数をレジスタ ebx へ
	mov    $0x4,%eax	# システム・コールの番号 eax へ
	call   *_dl_sysinfo	# 変数 _dl_sysinfo の内容の関数を呼び出す
	pop    %ebx		# ebxレジスタの内容を回復
	cmp    $0xfffff001,%eax	# エラーが起きたら
	jae    __syscall_error	# __syscall_errorへジャンプ (errno等の保存)
	ret    			# 呼び出した関数へリターン

write() システム・コールの内容がない。
_dl_sysinfo の内容は、以下の __kernel_vsyscall が入っている。
システム・コールの番号と引数は、レジスタに入れられている。
システム・コールの結果は、レジスタやフラグに入れて返される。

linux-4.20/arch/x86/entry/vdso/vdso32/system_call.S

  15:	__kernel_vsyscall:
...
  42:	        pushl   %ecx
  45:	        pushl   %edx
  48:	        pushl   %ebp
...
  52:	        #define SYSENTER_SEQUENCE       "movl %esp, %ebp; sysenter"
...
  60:	        ALTERNATIVE "", SYSENTER_SEQUENCE, X86_FEATURE_SEP
...
  64:	        int     $0x80
...
  72:	        popl    %ebp
  75:	        popl    %edx
  78:	        popl    %ecx
  81:	        ret

__kernel_vsyscall は、sysenter 命令、または、 int 命令 (interrupt)でカーネルに制御を移す。
VDSO (virtual dynamic shared object) とは、ユーザ空間にあり、システム・コール処理の手助けをする小さなコードがあるメモリである。カーネルの設定によりメモリの内容が変化する。同じバイナリのプログラムでも、カーネルの設定やCPU のモデルによって動きが変化する。
__kernel_vsyscall の場合、設定により、sysenter 命令か int 命令かどちらかが使われる。両方は使われない。

参考

■Linuxカーネルのソース

◆バージョン

3.0 (2011年20周年) 以降。3つの数からなる。

「メジャー・バージョン」．「リビジョン」．「パッチ番号」例: 4.19.13
新しい機能は、リビジョンが上がる所で入る。例: 4.19 の次は、4.20 。
重大な問題がバグが見つかると、パッチが出される。例: 4.19.{,1,2,3,...}
開発中、リリース前には、release candidate として-rc1, -rc2, -rc3 のよう出される。例: 4.20-{rc1,rc2,...}

2.6 系列は、4つの数からなる。例

2.6.26.1

「メジャー・バージョン」．「マイナー・バージョン」．「リビジョン」．「パッチ番号」

2.6 以前には、2.4, 2.2, 2.0 等が広く使われた。

◆kernel.org

Linux のカーネルのソース・コードは、 http://kernel.org/ に保存されている。

展開の仕方

$ tar xf linux-X.Y.Z.tar.xz 
$ tar xf linux-X.Y.Z.tar.bz2

tar コマンドが圧縮形式を認識できない時の展開の仕方。

$ xz    -d < linux-X.Y.Z.tar.xz  | tar xf - 
$ bzip2 -d < linux-X.Y.Z.tar.bz2 | tar xf -

.bz2 は、bzip2 コマンドで圧縮したもの。.xz は、xz コマンドで圧縮したもの。
.tar は、tar コマンドで固めた(複数のファイルを1つにまとめた)もの。

~yas/os2/linux-4.20 に展開したものがある。

◆カーネルのディレクトリ構成

カーネル・ソースのトップレベルのディレクトリ
ディレクトリ	説明
Documentation	ドキュメント
arch	アーキテクチャ依存
block	ブロック入出力層
crypto	暗号化
drivers	デバイス・ドライバ
firmware	ファームウェア
fs	VFS(Virtual File System)とファイル・システム
include	カーネル用のヘッダ・ファイル
init	起動と初期化(initialization)
ipc	プロセス間通信(interprocess communication)
kernel	カーネルの中心部分
lib	ヘルパ
mm	メモリ管理(memory management)
net	ネットワーク
samples	サンプルコード
scripts	カーネルのコンパイルに必要なスクリプト
security	Linux Security Module
sound	サウンド・サブシステム
tools	カーネル開発用のツール
usr	起動直後にユーザ空間で実行されるプログラム(initramfs)
virt	仮想化インフラ

■システム・コール

◆システムコールの番号

システム・コールの種類は、番号(整数)で区別される。番号は、アーキテクチャ(CPU)に依存している。

(自動生成されたもの)

linux-4.20/arch/x86/include/generated/uapi/asm/unistd_32.h
   4:	#define __NR_restart_syscall 0
   5:	#define __NR_exit 1
   6:	#define __NR_fork 2
   7:	#define __NR_read 3
   8:	#define __NR_write 4
   9:	#define __NR_open 5
  10:	#define __NR_close 6
  11:	#define __NR_waitpid 7
  12:	#define __NR_creat 8
  13:	#define __NR_link 9
  14:	#define __NR_unlink 10
  15:	#define __NR_execve 11
  16:	#define __NR_chdir 12
...
 383:	#define __NR_statx 383
 384:	#define __NR_arch_prctl 384
 385:	#define __NR_io_pgetevents 385
 386:	#define __NR_rseq 386
 387:

◆システム・コールの表 sys_call_table

linux-4.20/arch/x86/include/asm/syscall.h
  26:	typedef asmlinkage long (*sys_call_ptr_t)(unsigned long, unsigned long,
  27:	                                          unsigned long, unsigned long,
  28:	                                          unsigned long, unsigned long);
...
  30:	extern const sys_call_ptr_t sys_call_table[];
...
  33:	#define ia32_sys_call_table sys_call_table
  34:	#define __NR_syscall_compat_max __NR_syscall_max

linux-4.20/arch/x86/entry/syscall_32.c

  25:	#define __SYSCALL_I386(nr, sym, qual) [nr] = sym,
  26:	
  27:	__visible const sys_call_ptr_t ia32_sys_call_table[__NR_syscall_compat_max+1] = {
  28:	        /*
  29:	         * Smells like a compiler bug -- it doesn't work
  30:	         * when the & below is removed.
  31:	         */
  32:	        [0 ... __NR_syscall_compat_max] = &sys_ni_syscall,
  33:	#include <asm/syscalls_32.h>

linux-4.20/arch/x86/include/generated/asm/syscalls_32.h
   2:	__SYSCALL_I386(0, sys_restart_syscall, )
   7:	__SYSCALL_I386(1, sys_exit, )
  12:	__SYSCALL_I386(2, sys_fork, )
  17:	__SYSCALL_I386(3, sys_read, )
  22:	__SYSCALL_I386(4, sys_write, )
  27:	__SYSCALL_I386(5, sys_open, )
  32:	__SYSCALL_I386(6, sys_close, )
  37:	__SYSCALL_I386(7, sys_waitpid, )
  42:	__SYSCALL_I386(8, sys_creat, )
  47:	__SYSCALL_I386(9, sys_link, )
  52:	__SYSCALL_I386(10, sys_unlink, )
  57:	__SYSCALL_I386(11, sys_execve, )
  62:	__SYSCALL_I386(12, sys_chdir, )
...
1812:	__SYSCALL_I386(384, sys_arch_prctl, )
1817:	__SYSCALL_I386(385, sys_io_pgetevents, )
1822:	__SYSCALL_I386(386, sys_rseq, )

１つのシステム・コールを処理するために、1つの関数が定義されている。
関数の名前は、伝統的に sys_ で始まる。ユーザ空間のシステム・コールと紛れないようにするため。例: ユーザの write() システム・コールは、カーネル内の sys_write() という関数で処理される。
システムコールは、sys_call_table という表に登録されている。 n番目のシステム・コールは、テーブルのn番目にある関数を呼び出す。 C言語で書くと、次のようになる。
```
sys_call_ptr_t sys_call_table[__NR_syscall_max+1];
...
{
    long n = システム・コールの番号;
    long f = sys_call_table[n];
    (*f)( 引数0, 引数1, 引数2 ); // 関数と思って呼ぶ
}
```

◆sys_write()

linux-4.20/fs/read_write.c
 607:	SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
 608:	                size_t, count)
 609:	{
 610:	        return ksys_write(fd, buf, count);
 611:	}

 591:	ssize_t ksys_write(unsigned int fd, const char __user *buf, size_t count)
 592:	{
 593:	        struct fd f = fdget_pos(fd);
 594:	        ssize_t ret = -EBADF;
 595:	
 596:	        if (f.file) {
 597:	                loff_t pos = file_pos_read(f.file);
 598:	                ret = vfs_write(f.file, buf, count, &pos);
 599:	                if (ret >= 0)
 600:	                        file_pos_write(f.file, pos);
 601:	                fdput_pos(f);
 602:	        }
 603:	
 604:	        return ret;
 605:	}

この定義は、以下のように展開される。

asmlinkage long sys_write(unsigned int fd, const char __user *buf,
	   	size_t count)
{
	省略
}

今日は sys_write() の内容は、説明しない。
write() システム・コールは、fs/read_write.c の中の sys_write() 関数で処理される。
sys_write() という名前は、SYSCALL_DEFINE3() というマクロで作られる。 3 は、3引数の意味。普通は 0 引数 6 引数まで。
マクロにより、システム・コールを処理する関数には、asmlinkage というキーワード(コンパイラへの指示(directive))が付く。Cコンパイラは、アセンブリ言語からの呼び出しが簡単になるようなコードを出力する。
エラーの番号は、エラー番号は、小さい正の整数。大文字 E で始まる名前（マクロ）が付けられている。定義は、 <errno.h> (include/uapi/asm-generic/errno-base.h) 等に含まれている。
システム・コールの処理をする関数 sys_xxx() は、成功すると正の値を返す。エラーが発生すると、カーネル内では、エラー番号を負の値にしたものを返す。
システム・コールの結果は、ユーザ空間にはCPUのレジスタやCPUのフラグ（条件分岐に使うもの）に入れて返される。
ユーザ空間でシステム・コールは、成功すると、 0以上の値を返す。失敗すると、負の値(-1) 等を返す。
ユーザ空間でシステム・コールのエラー番号は、グローバル変数 errno を見ると分かる。 (マルチスレッドのプログラムでは、スレッド固有データ) x86-32 では、__syscall_error という手続きがレジスタにあるエラー番号をグローバル変数 errno にセットする。 write()システム・コール(ユーザ空間) 参照。

◆エラー番号の例

linux-4.20/include/uapi/asm-generic/errno-base.h
   5:	#define EPERM            1      /* Operation not permitted */
   6:	#define ENOENT           2      /* No such file or directory */
   7:	#define ESRCH            3      /* No such process */
   8:	#define EINTR            4      /* Interrupted system call */
   9:	#define EIO              5      /* I/O error */
  10:	#define ENXIO            6      /* No such device or address */
  11:	#define E2BIG            7      /* Argument list too long */
  12:	#define ENOEXEC          8      /* Exec format error */
  13:	#define EBADF            9      /* Bad file number */
  14:	#define ECHILD          10      /* No child processes */
  15:	#define EAGAIN          11      /* Try again */
  16:	#define ENOMEM          12      /* Out of memory */
  17:	#define EACCES          13      /* Permission denied */
  18:	#define EFAULT          14      /* Bad address */
...

◆SYSCALL_DEFINEマクロ

linux-4.20/include/linux/syscalls.h
 207:	#define SYSCALL_DEFINE0(sname)                                  \
 208:	        SYSCALL_METADATA(_##sname, 0);                          \
 209:	        asmlinkage long sys_##sname(void);                      \
 210:	        ALLOW_ERROR_INJECTION(sys_##sname, ERRNO);              \
 211:	        asmlinkage long sys_##sname(void)
...
 214:	#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
 215:	#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
 216:	#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
 217:	#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
 218:	#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
 219:	#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
...
 223:	#define SYSCALL_DEFINEx(x, sname, ...)                          \
 224:	        SYSCALL_METADATA(sname, x, __VA_ARGS__)                 \
 225:	        __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

 235:	#define __SYSCALL_DEFINEx(x, name, ...)                                 \
...
 239:	        asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))       \
 240:	                __attribute__((alias(__stringify(__se_sys##name))));    \
...
 244:	        asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  \
 245:	        {                                                               \
 246:	                long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
...
 250:	        }                                                               \
...
 252:	        static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))

SYSCALL_DEFINEn マクロにより、システム・コールを処理する関数が定義される。

関数名として、「sys_」というプレフィックスが付けられる。
「##」は、Cプリプロセッサの命令で、文字列の結合を意味する。
SYSCALL_DEFINEn マクロの引数は、「型と変数名」の組の可変長。
(上の例では、__se_sys##name() と __do_sys_##name() を定義し、前者から後者を呼び出している。 sys##name()は__se_sys##name()の別名(alias)。 )

◆システム・コールの実行のまとめ

main()、printf()、・・・、write()、systnter トラップ、・・・、sys_write()
図? hello world プログラムでのシステム・コールの実行

プログラムの実行は、ユーザ空間とカーネル空間に別れる。
各空間の内部の関数呼び出しは、call 命令で行われる。
ユーザ空間からカーネル空間への切替えは、トラップ命令で行われる。 x86 では sysenter 命令や int 命令が使われる。
ユーザ空間での write() の呼び出しは、カーネルでは sys_write() の呼出しになる。

■システム・コールやライブラリを観察するためのコマンド

◆strace コマンド

システム・コールの動きを調べるには、strace コマンド(Linux) が便利。

$ ./hello 
hello, world!
$ strace ./hello 
execve("./hello", ["./hello"], [/* 41 vars */]) = 0
brk(0)                                  = 0x1858000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fab706f4000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=61827, ...}) = 0
mmap(NULL, 61827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fab706e4000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\356\301O9\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1926760, ...}) = 0
mmap(0x394fc00000, 3750152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x394fc00000
mprotect(0x394fd8a000, 2097152, PROT_NONE) = 0
mmap(0x394ff8a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18a000) = 0x394ff8a000
mmap(0x394ff8f000, 18696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x394ff8f000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fab706e3000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fab706e2000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fab706e1000
arch_prctl(ARCH_SET_FS, 0x7fab706e2700) = 0
mprotect(0x394ff8a000, 16384, PROT_READ) = 0
mprotect(0x394fa1f000, 4096, PROT_READ) = 0
munmap(0x7fab706e4000, 61827)           = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fab706f3000
write(1, "hello, world!\n", 14hello, world!
)         = 14
exit_group(14)                          = ?
$

最後に exit() システム・コールが実行され、プログラムが終了している。
その前に、write() システム・コールが実行されている。引数は、1, "hello, world!\n", 14。その結果が「hello, world!」という表示。システム・コールの結果が 14 (書き込んだバイト数)。
その前の部分は、動的リンクの処理とメモリの確保の処理。 libc (/lib64/libc.so.6) のファイルが開かれ、 mmap() によりメモリにマップされている。

◆ltrace コマンド

ltrace コマンド(Linux) を使うと、ライブラリの呼び出しを調べることができる。

$ ./hello 
hello, world!
$ ltrace ./hello 
(0, 0, 716032, -1, 0x1f25bc2)                                                                                   = 0x394fa21160
__libc_start_main(0x4004c4, 1, 0x7fff87ef0a78, 0x4004f0, 0x4004e0 
printf("hello, %s!\n", "world"hello, world!
)                                                                                 = 14
+++ exited (status 14) +++
$

◆gdb デバッガ

$ gdb hello 
省略
Reading symbols from /home/prof/yas/coins/syspro-2010/cc/hello...(no debugging symbols found)...done.
(gdb) b main        # ブレークポイントの設定
Breakpoint 1 at 0x4004c8
(gdb) r             # 実行
Starting program: /home/prof/yas/coins/syspro-2010/cc/hello 
Breakpoint 1, 0x00000000004004c8 in main ()
(gdb) b write       # ブレークポイントの設定
Breakpoint 2 at 0x394f816ee0: file ../sysdeps/unix/syscall-template.S, line 82. (2 locations)
(gdb) c             # 実行継続
Continuing.
Breakpoint 2, write () at ../sysdeps/unix/syscall-template.S:82
82      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) bt            # バックトレース
#0  write () at ../sysdeps/unix/syscall-template.S:82
#1  0x000000394fc71ad3 in _IO_new_file_write (f=0x394ff8e7a0, data=, n=14) at fileops.c:1268
#2  0x000000394fc73085 in new_do_write (fp=0x394ff8e7a0, data=0x7ffff7ffc000 "hello, world!\n", to_do=14) at fileops.c:522
#3  _IO_new_do_write (fp=0x394ff8e7a0, data=0x7ffff7ffc000 "hello, world!\n", to_do=14) at fileops.c:495
#4  0x000000394fc7174d in _IO_new_file_xsputn (f=0x394ff8e7a0, data=0x4005e7, n=2) at fileops.c:1350
#5  0x000000394fc4461f in _IO_vfprintf_internal (s=, format=, ap=) at vfprintf.c:1672
#6  0x000000394fc4f18a in __printf (format=) at printf.c:35
#7  0x00000000004004dc in main ()
(gdb) c             # 実行継続
Continuing.
hello, world!

Program exited with code 016.
(gdb)

◆その他のプロセスを調べるコマンド

ktrace (FreeBSD, MacOSX 10.4)
dtrace, dtruss (Solaris, MacOSX 10.5以降)
truss (Solaris, System V Unix)

■プロセスとは

「オペレーティングシステムI」の復習

実行中のプログラムのイメージ。機械語のプログラムがメモリに読み込まれて「プロセッサ(CPU)」の実行の対象になったもの。
資源割当の単位
- 資源として、CPU時間、メモリ、アドレス空間、レジスタ、開いたファイル等を持つ
- CPU資源の割当ては、スケジューリングという。
保護の単位。他のプロセスのメモリは、直接的には見えない。プロセスが暴走(runaway)しても、他のプロセスには影響を及ぼさない。普通、暴走したプロセスを殺せば、回復する。システム全体の再起動は不要。
ファイル等のアクセス制御に用いる権限(利用者の識別子、利用者のグループの識別子)を持つ
プロセスの操作は、生成、終了、強制終了、プログラムの実行、一時停止、再開、デバッグなど。
３つの基本的な状態を持つ

◆プロセスの３つの状態

基本は３つ。新規と終了を入れたら５つ。

プロセスの基本的な状態
状態	説明
新規(New)	プロセスが作られつつある。
実行待ち(Ready)	CPUがあれば実行できるが CPU がないので実行されていない。CPUが割り当てられるのを待っている。
実行中(Running)	CPUが実際に割り当てられ、実行されている。
待機中(Waiting、Blocked)	プロセスが、I/Oの完了やシグナルの受信といった事象(event)が起きてるのを待っている。
終了(Terminated)	プロセスが実行を終えた。

New、Ready、Running、Waiting、Terminated
図? プロセスの５状態

◆プロセスとスレッド

スレッドとは、１つのプロセス（のアドレス空間）の内部にふくまれている論理的な並列処理の単位。

シングルスレッドのプログラム: １度に１つの手続き（Ｃの関数）しか動かない。
マルチスレッドのプログラム: １度にスレッドの数だけの手続きが論理的には同時に動く。 (同期でブロックされているものも含む)

スレッドはプロセスの機能のうち、保護の機能を抜いて高速化したもの。歴史的には、SMP (symmetric multiprocessor) での効率的な並列処理のために導入された。同一プロセスに属するスレッドは、アドレス空間やメモリを共有する。生成、消滅、スレッド間通信が高速に実現される。

■利用者から見たプロセスの見え方

次の3つのレベルで見える

システム・コール
psコマンド
/procファイル・システム

◆Unixにおけるプロセスに関するシステム・コール(一部)

fork(): プロセスのコピーを作る。
getpid(), getppid(): 自分のプロセス識別子(process identifier)、親プロセス(parent)の識別子の取得。
getuid(), geteuid(), setuid(), seteuid(), setreuid(): プロセスの属性のうち、UID (user identifier)の取得と設定を行う。
getgid(), getegid(), getgroups(), setgid(), setegid(), setregid(), setgroups(): プロセスの属性のうち、GID (group identifier)の取得と設定を行う。

◆ps lコマンド

ps l の結果のうち、次の属性に注目。IDは、identifierの意味。

表示	説明
STAT	State。状態。
PID	Process ID。プロセス1つ1つに重複ないように(unique)割り当てた番号。
PPID	Parent PID。親プロセスのPID。
UID	User ID。プロセスを生成した利用者の識別子。

$ ps l 
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1013 19935 19934  20   0 106452  1808 wait   Ss   pts/0      0:00 -bash
0  1013 19984 19935  20   0 6258068 98480 futex_ Sl  pts/0      0:01 /usr/bin/ja
0  1013 20067 19935  20   0 153232  5232 poll_s S    pts/0      0:00 xterm -clas
0  1013 20072 20067  20   0 106440  1720 n_tty_ Ss+  pts/1      0:00 bash
0  1013 20157 19935  20   0 108132   980 -      R+   pts/0      0:00 ps l
$

プロセスは、プロセス識別子(PID)で区別される。
プロセスには、親プロセスがいる。
プロセスは、全体で木構造を形成する。

◆その他のコマンド

kill: プロセスを強制終了
pstree: プロセスを木構造を視覚的に分かりやすい形で表示
lsof: プロセスが開いているファイルの表示
ls /proc/PID; cat /proc/PID/status

◆/proc ファイル・システム

/proc の下に、カーネル内のデータを取り出すための疑似的なファイルが存在する。特に、/proc/PID の下には、プロセス識別子がPID のプロセスの情報が現れる。詳しくは、man procを見なさい。

$ echo $$ 
23069
$ ls /proc/$$ 
attr             cpuset   fd        maps        numa_maps  schedstat  status
auxv             cwd      io        mem         oom_adj    smaps      task
cmdline          environ  limits    mounts      oom_score  stat       wchan
coredump_filter  exe      loginuid  mountstats  root       statm
$ head -11 /proc/$$/status  
Name:   bash
State:  S (sleeping)
SleepAVG:       98%
Tgid:   23069
Pid:    23069
PPid:   23068
TracerPid:      0
Uid:    1013    1013    1013    1013
Gid:    510     510     510     510
FDSize: 256
Groups: 20 510 1020 1065 1150 
$

◆fork() と pid を調べるプログラム

   1:	/*
   2:	        fork-pid.c -- fork() して画面に pid を表示するプログラム
   3:	        ~yas/syspro/proc/fork-pid.c
   4:	        Created on: 2010/12/13 21:19:17
   5:	*/
   6:	
   7:	#include <sys/types.h>  /* getpid(), getppid() */
   8:	#include <unistd.h>     /* getpid(), getppid() */
   9:	#include <stdio.h>
  10:	
  11:	main()
  12:	{
  13:	    pid_t pid;
  14:	        fork();
  15:	        pid = getpid();
  16:	        printf("pid=%d\n", pid );
  17:	}

$ make fork-pid 
cc     fork-pid.c   -o fork-pid
$ ./fork-pid 
pid=1005
pid=1006
$ ./fork-pid 
pid=1011
pid=1012
$

fork()してgetpid()してprintf()するプログラム
図? fork()によるプロセス生成と getpid()

fork() は、Unix でプロセスを生成するシステム・コール。プロセスをコピーすることで生成する。
コピーが作られているので printf() がそれぞれのプロセスで実行され、合計で 2 回実行される。
プロセスのコピーといっても、PID は異なる。

◆ppid (parent pid) を調べるプログラム

   1:	/*
   2:	        proc-pid-ppid.c -- 画面に pid と ppid を表示するプログラム
   3:	        ~yas/syspro/proc/proc-pid-ppid.c
   4:	        Created on: 2010/12/13 21:00:48
   5:	*/
   6:	
   7:	#include <sys/types.h>  /* getpid(), getppid() */
   8:	#include <unistd.h>     /* getpid(), getppid() */
   9:	#include <stdio.h>
  10:	
  11:	main()
  12:	{
  13:	    pid_t pid, ppid;
  14:	        pid = getpid();
  15:	        ppid = getppid();
  16:	        printf("pid=%d, ppid=%d\n", pid, ppid );
  17:	}

$ make proc-pid-ppid 
cc     proc-pid-ppid.c   -o proc-pid-ppid
$ echo $$ 
10771
$ ./proc-pid-ppid  
pid=10873, ppid=10771
$ ./proc-pid-ppid  
pid=10874, ppid=10771
$ ./proc-pid-ppid  
pid=10875, ppid=10771
$

シェルの PID は、$$ という変数で参照できる。
シェルは、コマンドを実行する時に fork() システム・コールでプロセスを生成している。
生成されたプロセスの PID は、プロセスごとに異なる。
fork() した場合、PPID は、コピー元の PID になる。
シェルのプロセスにも、親プロセスがいる。
PID と PPID により、システム全体ではプロセスの木構造が作られる。

◆fork()によるプロセスの木

   1:	/*
   2:	        fork-hello.c -- 画面に文字列を表示するプログラム
   3:	        ~yas/syspro/proc/fork-hello.c
   4:	        Start: 2001/05/13 23:19:01
   5:	*/
   6:	
   7:	#include <stdio.h>
   8:	
   9:	main()
  10:	{
  11:	        fork();
  12:	        fork();
  13:	        fork();
  14:	        printf("hello\n");
  15:	}

$ make fork-hello 
cc     fork-hello.c   -o fork-hello
$ ./fork-hello  
hello
hello
hello
hello
$ hello
hello
hello
hello

各 fork() で、プロセスの数が2倍になる。合計で、2 ³ == 8 倍になる。
実際の親子関係は、複雑。

図? fork() を 3 回するプログラム
図? fork()システム・コールによるプロセスのコピー

◆ユーザ

ユーザ(user, 利用者)とは、Unixの外では、個人（人間）。 Unixの内部では、次のどれかで表現する。

ユーザ名(user name): 文字列
UID(user ID, user identifier): 16ビット-32ビットの整数

Unixでは、全てのファイルやプロセスは、あるユーザの所有物である。ファイルとプロセスには、UID が付加されている。

◆グループ

グループ(group)とは、Unixの外の世界では、計算機を使う人間の集合。 Unixの内部では、次のどれかで表現する。

グループ名(group name): 文字列
GID(group ID, group identifier): 16ビット-32ビットの整数

１人のユーザが複数のグループに属することができる。

◆プロセスの属性

プロセスは、UID (1個) と GID を複数個持つ。

◆idコマンド

idコマンドを使うと、そのプロセス(の親プロセスであるシェルから継承した) UIDとGIDが調べられる。

$ id 
uid=1013(yas) gid=510(prof) groups=510(prof),20(games),1020(c-admin),1065(c-spec),1150(tebiki) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$

◆id-simple.c

id コマンドは、内部的にはgetuid(), getgid(), getgroups() システム・コールを使っている。以下は、id コマンドの簡易版である。

   1:	
   2:	/*
   3:	        id-simple.c -- a simple id command
   4:	        Created on: 2009/12/07 22:16:23
   5:	*/
   6:	
   7:	#include <unistd.h>     /* getuid(), getgid(), getgroups() */
   8:	#include <sys/types.h>  /* getuid(), getgid(), getgroups() */
   9:	#include <stdio.h>      /* printf() */
  10:	
  11:	#define MAXNGROUPS 100
  12:	
  13:	main( int argc, char *argv[], char *envp[] )
  14:	{
  15:	    uid_t uid ;
  16:	    gid_t gid ;
  17:	    gid_t groups[MAXNGROUPS];
  18:	    int len, i;
  19:	        uid = getuid();
  20:	        gid = getgid();
  21:	        len = getgroups(MAXNGROUPS,&groups[0]);
  22:	        printf("uid=%d gid=%d groups=", uid, gid );
  23:	        for( i=0; i<len; i++ )
  24:	            printf("%d,", groups[i]);
  25:	        printf("\n");
  26:	}

$ cc id-simple.c -o id-simple 
$ ./id-simple 
uid=1013 gid=510 groups=20,510,1020,1065,1150,
$

◆UID、GIDとアクセス制御

１年生の「コンピュータリテラシ」の試料も、参考になる。

http://www.coins.tsukuba.ac.jp/~yas/coins/literacy-2018/2018-05-22/index.html#access-control

■Linux task構造体

利用者レベルの視点では、プロセスは、メモリに読み込まれてCPUが割り当てられれば実行可能な「プログラム」である。メタレベルでは、「データ」になる。 Linux のプロセスは、task_struct 構造体というデータ構造で表現されている。

Linux の特殊事情

Linux のtask_struct 構造体は、カーネル・レベルのスレッドを実装するためにも利用されている。
Linux のプロセス識別子は、名前空間(namespace) ごとに、分割されている。1つの名前空間内では、同じプロセス識別子のプロセスは1つしか存在しない。名前空間が異なれば、同じプロセス識別子のプロセスが存在し得る。名前空間の機能は、1つのカーネルで、複数のホスティングのサービスを提供する時に利用される。1つのカーネルを多重化(multiplex)して使える。 Linux 専用の仮想計算機としても使える。

◆task_struct構造体

linux-4.20/include/linux/sched.h
 590:	struct task_struct {
...
 599:	        volatile long                   state;
...
 694:	        int                             exit_state;
 695:	        int                             exit_code;
...
 750:	        pid_t                           pid;
 751:	        pid_t                           tgid;
...
 764:	        struct task_struct __rcu        *real_parent;
...
 767:	        struct task_struct __rcu        *parent;
...
 772:	        struct list_head                children;
 773:	        struct list_head                sibling;
 774:	        struct task_struct              *group_leader;
...
 786:	        struct pid                      *thread_pid;
...
 842:	        const struct cred __rcu         *cred;
...
 851:	        char                            comm[TASK_COMM_LEN];
...
1224:	};

◆state

プロセスの状態。psコマンドで STAT の部分に現れる。一般的に、プロセスは、３つの状態を持つ。 Linux のプロセスの状態はもう少し多い。主に task_struct 構造体の stateというフィールドでプロセスの状態を表ている。(補助的に task_struct の exit_state も使う)。

linux-4.20/include/linux/sched.h
  71:	#define TASK_RUNNING                    0x0000
  72:	#define TASK_INTERRUPTIBLE              0x0001
  73:	#define TASK_UNINTERRUPTIBLE            0x0002
  74:	#define __TASK_STOPPED                  0x0004
  75:	#define __TASK_TRACED                   0x0008
  76:	/* Used in tsk->exit_state: */
  77:	#define EXIT_DEAD                       0x0010
  78:	#define EXIT_ZOMBIE                     0x0020
  79:	#define EXIT_TRACE                      (EXIT_ZOMBIE | EXIT_DEAD)
  80:	/* Used in tsk->state again: */
  81:	#define TASK_PARKED                     0x0040
  82:	#define TASK_DEAD                       0x0080
  83:	#define TASK_WAKEKILL                   0x0100
  84:	#define TASK_WAKING                     0x0200
  85:	#define TASK_NOLOAD                     0x0400
  86:	#define TASK_NEW                        0x0800
  87:	#define TASK_STATE_MAX                  0x1000

一般的な状態	Linuxの状態	ps表示	説明
実行待ち(Ready)	TASK_RUNNING	R	実行可能。CPU が割り当てられていれば実行中。
実行中(Running)	TASK_RUNNING	R	実行可能。CPU が割り当てられていれば実行中。
待機中(Waiting、Blocked)	TASK_INTERRUPTIBLE	S	キーボードや他のプロセスからの入力を待っている。
	TASK_UNINTERRUPTIBLE	D	ディスク入出力などの完了を待っている。割り込み不可。
	__TASK_STOPPED, __TASK_TRACED	T	一時的に停止しているか、デバッグの対象になっている。
終了(Terminated)	TASK_DEAD	Z	既に終了していて、終了処理の完了を待ってる。

◆pid_t型

pid_t 型は、システム・コールのレベルで(APIとして) プロセス識別子を表す型。int型を typedef で名前を付けている。1から32,768までで明いている部分を再利用する。(32,768を超えたら、1に戻って開いている番号を探して使う。)

linux-4.20/include/linux/types.h
  22:	typedef __kernel_pid_t          pid_t;

linux-4.20/include/uapi/asm-generic/posix_types.h
  28:	typedef int             __kernel_pid_t;

◆struct pid

APIとしてのプロセス識別子を、カーネルの中で表現するための構造体。

linux-4.20/include/linux/pid.h
  60:	struct pid
  61:	{
...
  67:	        struct upid numbers[1];
  68:	};

  53:	struct upid {
...
  55:	        int nr;
...
  58:	};

◆pidとtgid

Linux には、PID が何種類かある。カーネル・レベルのスレッドを生成すると、 task_struct も新たに作られる。その時、task_struct にある pid というフィールドも変わる。getpid() などのユーザ空間の API の実装は、カーネル内では、 TGID (Thread Group ID)に対応させる。

linux-4.20/include/linux/pid.h
   7:	enum pid_type
   8:	{
   9:	        PIDTYPE_PID,
  10:	        PIDTYPE_TGID,
  11:	        PIDTYPE_PGID,
  12:	        PIDTYPE_SID,
  13:	        PIDTYPE_MAX,
  14:	};

シングルスレッドなら、PIDTYPE_PID 型の PID と PIDTYPE_TGID 型の PID は同じ番号になる。カーネルレベルのスレッドを生成すると、その PIDTYPE_PID 型の PID は変化するが、PIDTYPE_TGID 型の PID は変化しない。 getpid() で使われるのは、PIDTYPE_TGID 型の PID。 group_leader は、この意味のスレッド・グループの先頭のスレッドを指す。

PGID は、Process Group ID。これは、killpg() システム・コール等で、プロセスのグループを使ったシグナルの送信に使われる。この機能は、シェルのジョブコントロールの実装に使われる。たとえば、^Z でパイプでつながったプロセス全部を一時的に止める時に使う。 PGID は、ps j コマンドで表示される。

SID は、Session ID。端末を開くと新しいセッションが始まる。 SID は、ps j コマンドで表示される。

◆char comm[TASK_COMM_LEN]

command名。最大16文字。

◆プロセスの木構造

real_parent, children, sibling というフィールドでプロセスの木構造が作られる。

task_struct、parent、child、sibling
図? プロセスの木構造

◆struct task_struct *real_parent

親プロセス(fork() システム・コールでコピー元のプロセス。)のtask_struct構造体へのポインタ。親が先に死んだ場合には、initプロセス(PID==1の最初に作られるプロセス)に養子に出される。

◆struct task_struct *parent

ptrace で、トレースしているプロセス(デバッガ等)。

◆struct list_head children

子プロセスのリストの先頭。

◆struct list_head sibling

兄弟プロセス（つまり、同じ親プロセスの子プロセス）のリスト。

◆struct cred *cred

credentials。資格。ファイルをアクセスする時等にプロセスがどのような権限を持っているかを表す。

task_struct構造体、cred構造体、group_info構造体
図? uid, gid, groups の保持方法

◆struct cred

task_struct に保存すべき内容のうち、uid、gid、groups 等を抜き出したもの。

linux-4.20/include/linux/cred.h
 116:	struct cred {
...
 125:	        kuid_t          uid;            /* real UID of the task */
 126:	        kgid_t          gid;            /* real GID of the task */
...
 151:	        struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
 152:	        struct group_info *group_info;  /* supplementary groups for euid/fsgid */
...
 154:	} __randomize_layout;

  30:	struct group_info {
  31:	        atomic_t        usage;
  32:	        int             ngroups;
  33:	        kgid_t          gid[0];
  34:	} __randomize_layout;

linux-4.20/include/linux/uidgid.h
  21:	typedef struct {
  22:	        uid_t val;
  23:	} kuid_t;

  26:	typedef struct {
  27:	        gid_t val;
  28:	} kgid_t;

linux-4.20/include/linux/types.h
  32:	typedef __kernel_uid32_t        uid_t;
  33:	typedef __kernel_gid32_t        gid_t;

linux-4.20/include/uapi/asm-generic/posix_types.h
  49:	typedef unsigned int    __kernel_uid32_t;
  50:	typedef unsigned int    __kernel_gid32_t;

kuid_t は、uid をカーネル内で保持するための型。32 ビットのuid_t (unsigned int) を保持するための構造体として定義されている。 (システム・コールの結果を返す所で、名前空間によるマッピングが行われることがある。)

◆uidとgid

uidは、ユーザを識別する番号、gidは、グループを識別する番号を保持する。ファイルを開く時等のアクセス権のチェックに使われる。

◆group_info

追加のgid (getgroups()) を保持する。

■current

変数 current は、カーネル中で現在実行中のプロセスの task_struct 構造体を保持する。さまざまなシステム・コールで、current を参照する。

直感的には、次のような大域変数があると思ってよい(実際には、CPUごとに異なる値を持つ)。

struct task_struct *current;

current→task_struct
図? current変数によるtask_structの参照

◆getuid()システム・コール

getuid() システム・コールは、現在実行中のプロセスの UID を返す。そのために、current を使う。

linux-4.20/kernel/sys.c
 916:	SYSCALL_DEFINE0(getuid)
 917:	{
 918:	        /* Only we change this so SMP safe */
 919:	        return from_kuid_munged(current_user_ns(), current_uid());
 920:	}

linux-4.20/include/linux/cred.h

 362:	#define current_uid()           (current_cred_xxx(uid))
 363:	#define current_gid()           (current_cred_xxx(gid))

 357:	#define current_cred_xxx(xxx)                   \
 358:	({                                              \
 359:	        current_cred()->xxx;                    \
 360:	})

 280:	#define current_cred() \
 281:	        rcu_dereference_protected(current->cred, 1)

 375:	#ifdef CONFIG_USER_NS
 376:	#define current_user_ns()       (current_cred_xxx(user_ns))
 377:	#else
 378:	static inline struct user_namespace *current_user_ns(void)
 379:	{
 380:	        return &init_user_ns;
 381:	}
 382:	#endif

linux-4.20/include/linux/uidgid.h
 163:	static inline uid_t from_kuid_munged(struct user_namespace *to, kuid_t kuid)
 164:	{
 165:	        uid_t uid = from_kuid(to, kuid);
 166:	        if (uid == (uid_t)-1)
 167:	                uid = overflowuid;
 168:	        return uid;
 169:	}

 121:	#ifdef CONFIG_USER_NS
...
 141:	#else
...
 153:	static inline uid_t from_kuid(struct user_namespace *to, kuid_t kuid)
 154:	{
 155:	        return __kuid_val(kuid);
 156:	}
...
 189:	#endif /* CONFIG_USER_NS */

  34:	static inline uid_t __kuid_val(kuid_t uid)
  35:	{
  36:	        return uid.val;
  37:	}

getuid() システム・コールの実装では、current_uid() を呼ぶ。これは、kuid_t 型の UID を返す。
current_uid() は、次のように展開される。
- current_uid()
- current_cred_xxx(uid)
- current_cred()->uid
- rcu_dereference_protected(current->cred, 1)->uid
rcu_dereference() の dereference は、ポインタが参照している先を取り出すことを意味する。rcu は、read-copy update の省略形。マルチプロセッサで、ポインタが変更される可能性がある時でも、ロックなしで読み込むことができる。意味を考える時には、最初は rcu_dereference() を無視してよい。よって、current_uid() は、意味的にこれと同じ。
- current->cred->uid
from_kuid_munged() は、kuid_t を uid_t (unsigned int, 32ビット) へ変換する。名前空間無効の時は、第１引数は使わない。 from_kuid(), __kuid_val() を呼び、kuid_t という構造体から val　というフィールドを取り出す。 (名前が有効なら、UID のマッピングが行われることがある。)

まとめると、getuid() システム・コールは、(名前空間が無効なら)次のようなコードと同じ。

SYSCALL_DEFINE0(getuid)
{
	kuid_t kuid;
	uid_t uid;
	kuid = current->cred->uid;
	uid = kuid.val;
	return uid;
}

◆fork()システム・コール

fork() システム・コールの実装では、task_struct をコピーし、uid, gid を引き継ぐ。

linux-4.20/kernel/fork.c
2285:	SYSCALL_DEFINE0(fork)
2286:	{
...
2288:	        return _do_fork(SIGCHLD, 0, 0, NULL, NULL, 0);
...
2293:	}

2190:	long _do_fork(省略)
2196:	{
...
2199:	        struct task_struct *p;
...
2201:	        long nr;
...
2221:	        p = copy_process(clone_flags, stack_start, stack_size,
2222:	                         child_tidptr, NULL, trace, tls, NUMA_NO_NODE);
2234:	        pid = get_task_pid(p, PIDTYPE_PID);
2235:	        nr = pid_vnr(pid);
...
2258:	        return nr;
2259:	}

1677:	static __latent_entropy struct task_struct *copy_process(省略)
1686:	{
1687:	        int retval;
1688:	        struct task_struct *p;
...
1756:	        p = dup_task_struct(current, node);
...
1789:	        retval = copy_creds(p, clone_flags);
...
1805:	        INIT_LIST_HEAD(&p->children);
1806:	        INIT_LIST_HEAD(&p->sibling);
....
1938:	                pid = alloc_pid(p->nsproxy->pid_ns_for_children);
...
1974:	        p->pid = pid_nr(pid);
...
1984:	                p->group_leader = p;
1985:	                p->tgid = p->pid;
...
2018:	                p->real_parent = current;
...
2070:	                        list_add_tail(&p->sibling, &p->real_parent->children);
...
2103:	        return p;
2159:	}

 839:	static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
 840:	{
 841:	        struct task_struct *tsk;
...
 848:	        tsk = alloc_task_struct_node(node);
...
 861:	        err = arch_dup_task_struct(tsk, orig);
...
 926:	        return tsk;
...
 933:	}


 824:	int __weak arch_dup_task_struct(struct task_struct *dst,
 825:	                                               struct task_struct *src)
 826:	{
 827:	        *dst = *src;
 828:	        return 0;
 829:	}

fork() システム・コールの実装では、copy_process() で、task_struct をコピーする。親プロセス側の返り値として子プロセスの PID を返す。
copy_process() は、dup_task_struct() で task_struct をコピーする。
- dup_task_struct() は、alloc_task_struct_node() で新しい task_struct を割り当てる。arch_dup_task_struct() で、task_structをコピーする。
  - arch_dup_task_struct() は、task_struct の多くのメンバを、そのままコピー(*dst = *src)する。
copy_process() は、copy_creds() で、cred をコピーする(参照カウントを増やす)。
children や sibling は、空にする。
alloc_pid() で pid を新しく割り当てる。
group_leader, tgid は自分自身を指す。
real_parent は、親プロセスを指す。

注意: Linux では、単純な fork() 以外に、PID 等をコピーして引き継げるようなシステム・コール clone() がある。

■GNU global

大きなソースコードを読むには、grepやgrep -r よりも GNU GLOBAL が便利。

gtags: ソースコードを解析して索引ファイル (GTAGS, GRTAGS, GPATH という名前) を作る。一度だけやれば十分。 Linux では、make gtags で GNU global 用の索引が作られる。
global id: 引数で与えられた id を「定義している」ファイルの名前を表示する。
global -x id: 引数で与えられた id を「定義している」ファイルの名前と行を表示する。
global -s id
global -sx id: 引数で与えられた、「定義」以外のid のファイルの名前(-xでその行)を表示する。 Linux で、SYSCALL_DEFINE0() 等の中のシステム・コール名を探すのに使える。
global -r id
global -rx id: 引数で与えられた id を利用しているファイルの名前(-xでその行)を表示する。

実行例

$ pwd 
/home/prof/yas/os2/linux-4.20
$ 
$ ls -l G* 
-rw-r--r--. 1 yas prof   7421952  1月  3 19:47 2019 GPATH
-rw-r--r--. 1 yas prof 396378112  1月  3 19:35 2019 GRTAGS
-rw-r--r--. 1 yas prof 266887168  1月  3 19:35 2019 GTAGS
$ global task_struct 
fs/proc/internal.h
include/linux/sched.h
$ global -rx task_struct|head -5 
task_struct       118 arch/x86/entry/vsyscall/vsyscall_64.c     struct task_struct *tsk;
task_struct         9 arch/x86/include/asm/current.h struct task_struct;
task_struct        11 arch/x86/include/asm/current.h DECLARE_PER_CPU(struct task_struct *, current_task);
task_struct        13 arch/x86/include/asm/current.h static __always_inline struct task_struct *get_current(void)
task_struct       288 arch/x86/include/asm/elf.h struct task_struct;
$ global -rx task_struct | wc 
   3641   30439  358675
$ global getpid 
$ global -s getpid 
kernel/sys.c
samples/bpf/task_fd_query_user.c
samples/bpf/test_current_task_under_cgroup_user.c
samples/connector/ucon.c
samples/timers/hpet_example.c
scripts/kconfig/confdata.c
$ global -sx getpid | grep SYSCALL 
getpid            888 kernel/sys.c     SYSCALL_DEFINE0(getpid)
$

◆Emacs gtags-mode

Emacs の gtags-mode を使うと、Emacs の中で、Gnu Global の機能を使って定義に移動できる。 ~/.emacs 等に次のような設定を加える。(/usr/local3/coins/ のパス名は、 coins のみ有効。) これで、C 言語のファイルについて gtags-mode が有効になる。

(autoload 'gtags-mode "/usr/local3/coins/linux/share/gtags/gtags.el" "" t)
(setq gtags-suggested-key-mapping t)
(add-hook 'c-mode-common-hook 
	  (lambda ()
	    (gtags-mode 1))
)

gtags-mode では、次のようなキーが使えるようになる。

キー	関数	説明
M-.	gtags-find-tag	定義に移動する (global -x)
M-*	gtags-pop-stack	元に戻る
C-c r	gtags-find-rtag	呼びだし元を探す (global -rx)
C-c s	gtags-find-symbol	シンボルを探す (global -sx)

マウスのボタンが使えることもある。

ボタン	関数	説明
<mouse-2>	gtags-find-tag-by-event	定義に移動する
<mouse-3>	gtags-pop-stack	元に戻る

参考

https://www.gnu.org/software/global/globaldoc_toc.html#Emacs-editor, GNU GLOBAL Source Code Tag System Tutorial/ 3.6 Extended Emacs using GLOBAL

Emacs 以外に vim 等でも使える。

■毎週のレポートの出し方

A4 用紙を使う。B5不可。両面化。複数枚になる時には、左上を閉じる。

上部に次のヘッダを含める。

情報科学類 オペレーティングシステムII 課題<n> 学籍番号 ________ 名前________ 提出日________

締切は、次の授業の回。欠席した時は、次に出席した回に提出する。
レポートの結果は、成績の20%として反映させる。
- レポートを未提出で、試験100点なら、0*0.2 + 100*0.8 == 80 (A)
- レポート満点で、試験50点(D相当)なら、100*0.2 + 50*0.8 == 60 (C)
期限が過ぎても受け取る。ただし、減点する。
レポートの内容は、その日の授業内容に即したものであること。授業とは関係ない、検索してたまたま見つかったことを解答しないこと。
実際のソースコードは複雑である。解答は授業の範囲内で簡単なもので十分である。

■課題1 システムコール、プロセスとtask_struct構造体

★問題(101) システム・コールとライブラリ関数の相違点

システム・コールとライブラリ関数の相違点を述べなさい。

★問題(102) access()システムコールの引数と結果

access() システム・コールのマニュアルには、次のような記述がある。

ACCESS(2)                  Linux Programmer's Manual                 ACCESS(2)



NAME
       access - check real user's permissions for a file

SYNOPSIS
       #include <unistd.h>

       int access(const char *pathname, int mode);

DESCRIPTION
       access()  checks  whether the calling process can access the file path-
       name.  If pathname is a symbolic link, it is dereferenced.
...
RETURN VALUE
       On  success  (all requested permissions granted), zero is returned.  On
       error (at least one bit in mode asked for a permission that is  denied,
       or  some other error occurred), -1 is returned, and errno is set appro-
       priately.
...

このシステム・コールを処理する関数がカーネルの中でどのように定義されているか、その概略(引数と結果の宣言)を示しなさい。関数の内容は空でよい。マクロを利用しても利用しなくてもどちらでもよい。

引数と結果の宣言
{
   /*内容*/
}

★問題(103) Ready状態のプロセス

オペレーティング・システムでは、「一般に」プロセスは、実行待ち(Ready)、実行中(Running)、待機中(Waiting、Blocked)という３つの状態を持つ。 Linux において、プロセスが from_kuidReady 状態であることを示すために、task struct のフィールド state に、何という値を設定しているか。

★問題(104) fork()システム・コール

fork() システムコールの実装について、本日の授業の範囲内で、次の項目を答えなさい。

プロセスに対応している構造体の名前
その構造体をコピーする関数
その構造体でコピーするメンバの例
その構造体でコピーしないメンバの例

★問題(105) getuid()getgidシステム・コール

getuid()getgid() (Get Group ID) システム・コールを実装の概略を、今日の授業の範囲内で答えなさい。利用する重要な変数、マクロ、構造体を列挙しなさい。そして、どのようにポインタをたどっていくかを示しなさい。概略を記述するためには、簡易的なＣ言語、日本語、または、英語を使いなさい。

なお、実際の getuid()getgid() システム・コールの実装は、名前空間の導入により複雑になっており、今日の授業の範囲を超えている。この課題では、実際のコードではなく、この授業の範囲内で答えなさい。（実際のコードをそのまま回答しても、得点を与えない。）

Last updated: 2019/01/11 15:37:12

Yasushi Shinjo / <yas@cs.tsukuba.ac.jp>