Linux Kernel(4.19) Hacks

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(28)덧글(0)

[리눅스커널] 프로세스: thread_info 구조체 - cpu 필드에 대한 상세 분석 4. 프로세스(Process) 관리

by AustinKim
2020/03/01 09:08
rousalome.egloos.com/10012046
덧글수 : 0

thread_info 구조체의 cpu 필드는 프로세스가 실행 중인 CPU 번호를 저장합니다. 그러면 현재 코드가 어떤 CPU에서 구동 중인지 알려면 어떤 함수를 써야 할까요? 커널에서 제공하는 smp_processor_id() 함수를 호출하면 됩니다.

smp_processor_id() 함수 분석

smp_processor_id() 함수를 보면서 세부 동작 방식을 확인해보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/smp.h

1 # define smp_processor_id() raw_smp_processor_id()

https://elixir.bootlin.com/linux/v4.19.30/source/arch/arm/include/asm/smp.h

2 #define raw_smp_processor_id() (current_thread_info()->cpu)

선언부로 봐서 smp_processor_id() 함수는 매크로 타입의 함수임을 알 수 있습니다.

1~2번째 줄을 보면 smp_processor_id() 함수는 raw_smp_processor_id() 함수로 치환됩니다. 이어서 raw_smp_processor_id() 함수를 보면 current_thread_info()->cpu 코드로 치환된다는 사실을 알 수 있습니다.

위 선언부를 통해 알아본 smp_processor_id() 매크로 함수의 실체는 다음과 같습니다.

 smp_processor_id()

 raw_smp_processor_id()

 (current_thread_info()->cpu)

current_thread_info() 함수는 실행 중인 프로세스 스택의 주소를 읽어서 프로세스 스택의 최상단 주소를 얻어옵니다.

---

current_thread_info() 함수의 코드 분석은 4.10.2절에서 확인할 수 있습니다.

---

이번에는 smp_processor_id() 함수를 써서 현재 실행 중인 코드가 어떤 CPU에서 실행 중인지 식별하는 코드를 살펴보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c

01 void resched_curr(struct rq *rq)

02 {

03 struct task_struct *curr = rq->curr;

04 int cpu;

...

05 cpu = cpu_of(rq);

06

07 if (cpu == smp_processor_id()) {

08 set_tsk_need_resched(curr);

09 set_preempt_need_resched();

10 return;

11 }

5번째 줄에서는 함수의 인자인 런큐 구조체에서 런큐 CPU 번호를 cpu 지역변수에 저장합니다. 7번째 줄에서는 smp_processor_id() 함수를 호출해서 현재 wake_up_idle_cpu() 함수가 몇 번 CPU에서 실행 중인지 확인합니다. 이때 현재 실행 중인 CPU 번호와 런큐 CPU 번호가 같으면 8~9번째 줄을 실행하고 함수 실행을 종료합니다.

참고로 67번째 줄의 매크로를 풀어서 실제 동작하는 코드로 바꾸면 아래 코드와 같습니다.

if (cpu == current_thread_info()->cpu) {

smp_processor_id() 함수의 전체 흐름 파악

커널의 다양한 코드에서 smp_processor_id() 함수를 호출해 현재 실행 중인 CPU 번호를 읽습니다. 이번에는 resched_curr() 함수에서 smp_processor_id() 함수를 호출했을 때의 실행 흐름을 확인해 봅시다.

그림 4.20 실행 중인 CPU 번호를 로딩하는 smp_processor() 함수의 실행 흐름

위 함수 콜스택은 라즈베리 파이의 라즈비안에서 확인한 것입니다. SDIO 드라이버에서 워크 핸들러인 brcmf_sdio_dataworker() 함수를 실행합니다. 이 후 __wake_up() 함수를 호출해 프로세스 스케줄링 요청을 수행하는 resched_curr() 함수를 실행합니다.

그림 4.20에서 볼 수 있듯이 resched_curr() 함수에서 smp_processor_id() 함수를 호출하면 실행 중인 프로세스 스택의 최상단 주소에 접근해서 cpu라는 필드를 읽어 옵니다.

set_task_cpu() 함수 분석

실행 중인CPU 번호를 저장하는 thread_info 구조체의 cpu 필드는 set_task_cpu() 함수가 호출될 때 변경됩니다. set_task_cpu() 함수를 보면서 세부 동작 방식을 분석해보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c

void set_task_cpu(struct task_struct *p, unsigned int new_cpu)

{

...

__set_task_cpu(p, new_cpu);

}

set_task_cpu() 함수에서는 두 번째 인자인 new_cpu를 __set_task_cpu() 함수로 전달하며 호출합니다.

이어서 __set_task_cpu() 함수를 보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/sched.h

static inline void __set_task_cpu(struct task_struct *p, unsigned int cpu)

{

...

task_thread_info(p)->cpu = cpu;

task_thread_info() 함수는 태스크 디스크립터를 입력으로 받아 프로세스 스택의 최상단 주소를 반환합니다. thread_info 구조체의 cpu 필드에 매개변수로 전달된 cpu를 저장합니다.

정리하면 set_task_cpu() 함수를 실행하면 다음과 같은 동작을 수행합니다.

 프로세스 스택의 최상단 주소에 접근

 thread_info 구조체의 cpu 필드에 실행 중인 cpu 인자의 값을 저장

그림 4.21을 보면서 set_task_cpu() 함수의 실행 흐름을 확인해 보겠습니다.

그림 4.21 실행 중인 CPU 번호를 저장하는 set_task_cpu() 함수의 흐름

set_task_cpu() 함수를 호출하면 __set_task_cpu() 함수를 호출합니다. 이때 프로세스 스택의 최상단 주소에 접근해 thread_info 구조체의 cpu 필드에 cpu 번호를 저장합니다. 그림 4.21에서는 4를 CPU 번호로 지정합니다.

지금까지 thread_info 구조체의 세부 필드가 어떻게 바뀌는지 살펴봤습니다. 코드 분석을 토대로 태스크 디스크립터보다 thread_info 구조체가 프로세스 세부 동작을 저장하는 역할을 수행한다는 사실을 확인했습니다.

다음 절에서는 프로세스가 생성될 때 thread_info 구조체를 초기화하는 과정을 알아보겠습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : thread_info, 리눅스커널, 프로세스

트랙백(0)핑백(28)덧글(0)

[리눅스커널] thread_info 구조체의 preempt_count - 선점 스케줄링 여부 확인 4. 프로세스(Process) 관리

by AustinKim
2020/03/01 09:04
rousalome.egloos.com/10012045
덧글수 : 0

리눅스 커널의 핵심 동작은 스케줄링입니다. 프로세스는 schedule() 함수를 호출해서 명시적으로 스케줄링할 수도 있지만 인터럽트 처리 후 선점 스케줄링될 수 있습니다. 커널은 스케줄링 동작 중에 thread_info 구조체의 preempt_count 필드에 저장된 값을 보고 선점 스케줄링 실행 여부를 판단합니다.

그런데 여기서 한 가지 의문이 생깁니다. preempt_count 필드가 어떤 값일 때 선점 스케줄링을 시작할까요? preempt_count 필드가 0이면 프로세스가 선점될 수 있는 조건이라고 판단합니다. 그럼 선점 스케줄링 관련 코드를 보면서 세부 동작을 배워봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/arch/arm/kernel/entry-armv.S

1 __irq_svc:

2 svc_entry

3 irq_handler

4

5 #ifdef CONFIG_PREEMPT

6 ldr r8, [tsk, #TI_PREEMPT] @ get preempt count

7 ldr r0, [tsk, #TI_FLAGS] @ get flags

8 teq r8, #0 @ if preempt count != 0

9 movne r0, #0 @ force flags to 0

10 tst r0, #_TIF_NEED_RESCHED

11 blne svc_preempt

12 #endif

다소 낯선 어셈블리 코드지만 차근차근 코드의 의미를 분석해 봅시다. 먼저 1~3번째 줄을 보겠습니다.

1 __irq_svc:

2 svc_entry

3 irq_handler

__irq_svc 레이블은 인터럽트가 발생했을 때 실행되는 인터럽트 벡터입니다. 2~3번째 줄에서는 인터럽트 핸들링을 수행합니다. 즉, 인터럽트가 발생하면 인터럽트에 대응하는 인터럽트 핸들러 함수를 실행하는 동작을 수행합니다.

6~11번째 줄은 스케줄링을 실행할지 결정하는 어셈블리 코드입니다.

6 ldr r8, [tsk, #TI_PREEMPT] @ get preempt count

7 ldr r0, [tsk, #TI_FLAGS] @ get flags

8 teq r8, #0 @ if preempt count != 0

9 movne r0, #0 @ force flags to 0

10 tst r0, #_TIF_NEED_RESCHED

11 blne svc_preempt

어셈블리 코드를 이해하기 쉽게 C 코드로 표현하면 다음과 같습니다.

01 struct thread_info *current_thread_info = task_thread_info(current);

02

03 if (current_thread_info.preempt_count == 0 ) {

04 if (current_thread_info.flags & _TIF_NEED_RESCHED) {

04 svc_preempt(); // 스케줄링 실행

05 }

06 else {

06 current_thread_info.flags = 0;

06 }

변환된 C 코드의 1번째 줄에서는 프로세스 스택의 최상단 주소에 접근해 thread_info 구조체에 접근하며, 이를 current_thread_info라는 변수에 저장합니다.

03~04번째 줄에서는 다음 두 가지 조건을 검사합니다.

 preempt_count 필드가 0인지 여부

 flags 필드와 _TIF_NEED_RESCHED(0x2)와의 AND 연산을 수행해 연산 결과가 true인지 여부

두 조건을 모두 만족하면 svc_preempt() 함수를 호출해 선점 스케줄링을 실행합니다.

---

선점 스케줄링의 자세한 동작 방식은 10장 ‘프로세스 스케줄링’의 10.6절에서 상세히 설명합니다.

---

이번 절에서는 thread_info 구조체의 preempt_count 필드를 어떻게 처리하는 살펴봤습니다. 코드 분석으로 다음과 같은 내용을 알게 됐습니다.

인터럽트 컨텍스트 설정

 시작: preempt_count += HARDIRQ_OFFSET;

 종료: preempt_count -= HARDIRQ_OFFSET;

Soft IRQ 컨텍스트 설정

 시작: preempt_count += SOFTIRQ_OFFSET;

 종료: preempt_count -= SOFTIRQ_OFFSET;

프로세스 스케줄링 가능 여부

 preempt_count가 0이면 선점 스케줄링되는 조건임

프로세스의 세부 실행 상태를 preempt_count 필드로 관리하므로 잘 알아둘 필요가 있습니다. 다음 절에서는 thread_info 구조체의 cpu 필드가 어떤 흐름으로 바뀌는지 살펴보겠습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : preempt_count, 선점, preempt, 리눅스커널

트랙백(0)핑백(28)덧글(0)

[리눅스커널] thread_info 구조체의 preempt_count - Soft IRQ 컨텍스트 실행 4. 프로세스(Process) 관리

by AustinKim
2020/03/01 09:01
rousalome.egloos.com/10012044
덧글수 : 0

Soft IRQ 컨텍스트의 시작 상태 저장

프로세스가 Soft IRQ 서비스를 처리 중이면 preempt_count 필드에 SOFTIRQ_OFFSET 매크로를 저장합니다. 다음 그림을 보면서 Soft IRQ 컨텍스트의 실행 시작을 설정하는 과정을 알아보겠습니다.

그림 4.18 Soft IRQ 컨텍스트 설정 시의 함수 흐름

그림 4.18에서 irq_exit() 함수가 보일 것입니다. 이 함수가 Soft IRQ 실행의 시작점입니다. 이처럼 Soft IRQ는 인터럽트 핸들링이 끝나면 실행을 시작합니다.

그렇다면 언제 Soft IRQ 컨텍스트를 설정할까요? 정답은 __do_softirq() 함수를 보면 알 수 있습니다. irq_exit() 함수에서 Soft IRQ 서비스 요청 여부를 체크한 다음 __do_softirq() 함수를 호출합니다. Soft IRQ 서비스를 실행하는 __do_softirq() 함수에서 프로세스 스택의 최상단 주소에 접근합니다.

thread_info 구조체의 preempt_count 필드에 Soft IRQ 실행을 나타내는 SOFTIRQ_OFFSET(0x100) 매크로를 더합니다. __do_softirq() 함수의 코드를 보면서 이를 확인해 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/softirq.c

01 asmlinkage __visible void __softirq_entry __do_softirq(void)

02 {

...

03 __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);

04 in_hardirq = lockdep_softirq_start();

05

06 restart:

07 /* Reset the pending bitmask before enabling irqs */

08 set_softirq_pending(0);

09

10 local_irq_enable();

11

12 h = softirq_vec;

13

14 while ((softirq_bit = ffs(pending))) {

15 unsigned int vec_nr;

16 int prev_count;

17

18 h += softirq_bit - 1;

19

20 vec_nr = h - softirq_vec;

21 prev_count = preempt_count();

22

23 kstat_incr_softirqs_this_cpu(vec_nr);

24

25 trace_softirq_entry(vec_nr);

26 h->action(h);

27 trace_softirq_exit(vec_nr);

...

28 }

...

29

30 lockdep_softirq_end(in_hardirq);

31 account_irq_exit_time(current);

32 __local_bh_enable(SOFTIRQ_OFFSET);

위 코드는 __do_softirq() 함수에서 중요한 부분을 요약한 것입니다. 먼저 03번째 줄을 봅시다.

03 __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);

thread_info 구조체의 preempt_count 필드에 접근해 다음과 같이 +SOFTIRQ_OFFSET 플래그만큼 증가합니다.

preempt_count += SOFTIRQ_OFFSET(0x100)

06~28번째 줄은 Soft IRQ 서비스를 실행하는 동작입니다.

마지막 32번째 줄 코드를 보겠습니다.

32 __local_bh_enable(SOFTIRQ_OFFSET);

thread_info 구조체의 preempt_count 필드에 접근해 -SOFTIRQ_OFFSET 플래그만큼 감소시킵니다.

preempt_count -= SOFTIRQ_OFFSET(0x100)

이번에는 Soft IRQ 컨텍스트를 설정하는 __local_bh_disable_ip() 함수를 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/softirq.c

01 void __local_bh_disable_ip(unsigned long ip, unsigned int cnt)

02 {

...

03 __preempt_count_add(cnt);

03번째 줄에서 cnt 인자로 __preempt_count_add() 함수를 호출합니다.

__preempt_count_add() 함수는 전달된 인자를 thread_info 구조체의 preempt_count 필드에 더합니다. 여기서 cnt는 SOFTIRQ_OFFSET 매크로를 저장하고 있으니 thread_info 구조체의 preempt_count는 다음 수식과 같이 바뀝니다. 참고로 thread_info 구조체는 실행 중인 프로세스 스택의 최상단 주소에 있다는 점을 기억하세요.

preempt_count += SOFTIRQ_OFFSET;

Soft IRQ 서비스를 실행하는 서브 함수에서 in_softirq() 매크로를 if 문과 함께 쓰면 현재 실행 중인 코드가 Soft IRQ 컨텍스트인지 알 수 있습니다. in_softirq() 매크로 함수를 쓰는 예제 코드를 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/mm/memcontrol.c

bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages)

{

01 gfp_t gfp_mask = GFP_KERNEL;

...

02 /* Don't block in the packet receive path */

03 if (in_softirq())

04 gfp_mask = GFP_NOWAIT;

03~04번째 줄을 보면 in_softirq() 함수가 true를 반환하면 04번째 줄 코드를 실행합니다. 이 코드는 Soft IRQ 컨텍스트에서 gfp_mask를 GFP_NOWAIT로 설정한다는 의미입니다.

in_softirq() 함수는 thread_info 구조체의 preempt_count 필드에 대해 다음과 같은 AND 연산을 수행합니다.

preempt_count & 0xFF00 (SOFTIRQ_MASK)

__do_softirq() 함수에서 Soft IRQ 서비스를 실행하기 전 __local_bh_disable_ip() 함수를 호출하면 thread_info 구조체의 preempt_count는 0x100이 됩니다.

Soft IRQ 서비스를 실행하는 중에 in_softirq() 함수를 실행하면 thread_info 구조체의 preempt_count 필드가 0x2100이므로 true를 반환합니다.

0x100 & 0xFF00 (SOFTIRQ_MASK) // true

Soft IRQ 컨텍스트의 종료 상태를 저장

이번에는 Soft IRQ 서비스 함수의 호출을 마친 다음에 어떤 동작을 하는지 알아보겠습니다. 그림 4.19는 처리 과정을 나타낸 것입니다.

그림 4.19 Soft IRQ 컨텍스트 설정 해제 시의 함수 흐름

'Soft IRQ 컨텍스트'가 종료됐다는 정보는 __do_softirq() 함수에서 Soft IRQ 서비스 핸들러 함수를 호출한 후 설정합니다. 처리 과정은 다음과 같습니다.

1. 프로세스 스택 최상단 주소에 접근한다.

2. thread_info 구조체의 preempt_count 필드에서 SOFTIRQ_OFFSET(0x100) 비트를 뺀다.

'Soft IRQ 컨텍스트'가 종료됐다고 업데이트한 후 오른쪽의 ① 구간으로 표시된 함수에서 in_softirq() 함수를 호출하면 false를 반환합니다. 이는 __do_softirq() 함수에서 Soft IRQ 서비스 실행을 마무리하면 __local_bh_enable() 함수를 호출해 thread_info 구조체의 preempt_count 필드에서 SOFTIRQ_OFFSET(0x100)를 빼는 연산을 수행하기 때문입니다.

이어서 Soft IRQ 서비스 실행을 마치면 호출하는 __local_bh_enable() 함수를 분석해 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/softirq.c

01 static void __local_bh_enable(unsigned int cnt)

02 {

...

03 __preempt_count_sub(cnt);

04 }

03번째 줄과 같이 __preempt_count_sub() 함수를 호출합니다. 이번에는 실행 중인 프로세스 스택의 최상단 주소에 접근한 후 thread_info 구조체의 preempt_count 필드에 -SOFTIRQ_OFFSET(0x100)만큼 감소시킵니다.

preempt_count -= SOFTIRQ_OFFSET;

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : SOFTIRQ_OFFSET, 리눅스커널, SoftIRQ, preempt_count

트랙백(0)핑백(28)덧글(0)

[리눅스커널] thread_info 구조체의 preempt_count - 인터럽트 컨텍스트 실행 저장 4. 프로세스(Process) 관리

by AustinKim
2020/03/01 08:57
rousalome.egloos.com/10012043
덧글수 : 0

리눅스 시스템에서 인터럽트는 언제든지 발생할 수 있습니다. 인터럽트가 발생하면 프로세스 실행을 멈추고 인터럽트에 해당하는 인터럽트 핸들러를 실행합니다. 커널에서는 인터럽트가 발생해서 인터럽트 서비스 루틴을 실행하는 동작을 인터럽트 컨텍스트라고 부릅니다.

---

참고로 인터럽트는 외부 입출력 장치에 어떤 변화가 있을 때 발생하는 전기 신호 혹은 이를 CPU에게 알려서 처리하는 과정을 뜻합니다. 리눅스 커널은 인터럽트를 처리할 수 있는 함수를 지원하며, 자세한 내용은 5장의 5.1절에서 설명합니다.

---

thread_info 구조체의 preempt_count 필드에 인터럽트가 실행 중인 상태를 나타내는 비트를 설정합니다. 이 비트를 읽어 인터럽트 컨텍스트 유무를 식별합니다. 리눅스 커널에서는 현재 실행 중인 코드가 인터럽트 컨텍스트 내에 있는지 알려주는 in_interrupt() 함수를 제공합니다.

다음 그림을 보면서 인터럽트가 발생했을 때 어떤 흐름으로 thread_info 구조체의 preempt_count 필드가 바뀌는지 알아보겠습니다.

그림 4.16 인터럽트 컨텍스트 설정 시의 함수 흐름

그림 4.16에서 인터럽트 컨텍스트를 설정하는 실행 흐름은 다음과 같습니다.

1. __wake_up_common_lock() 함수를 실행하는 도중에 인터럽트 발생

2. 인터럽트 벡터인 __irq_svc 레이블 실행

3. 다음과 같은 인터럽트 제어 함수를 호출

 bcm2836_arm_irqchip_handle_irq()

 __handle_domain_irq()

4. __handle_domain_irq() 함수에서 irq_enter() 매크로 함수를 호출

4.1 프로세스 스택 최상단 주소에 접근한 후 thread_info 구조체의 preempt_count 필드에 HARDIRQ_OFFSET(0x10000) 비트를 더함

5. 화살표 방향으로 함수를 계속 호출해서 인터럽트 핸들러 함수인 usb_hcd_irq() 함수를 호출

5.1 서브루틴 함수를 실행

4.1단계 이후에 실행하는 모든 하위 함수에서 in_interrupt() 함수를 호출하면 true를 반환합니다. 예를 들면, 그림 4.16에서 irq_enter() 함수 이후로 호출되는 usb_hcd_irq() 함수에서 in_interrupt() 함수를 호출하면 true를 반환합니다.

다음과 같이 if 문과 in_interrupt() 매크로를 함께 쓰면 실행 코드가 인터럽트 컨텍스트인지 확인할 수 있습니다.

if (in_interrupt()) {

// 인터럽트 컨텍스트에서 실행할 코드

}

in_interrupt() 함수는 thread_info 구조체의 preempt_count 필드에 대해 다음과 같은 AND 비트 연산을 수행합니다.

preempt_count & 0x001FFF00 (HARDIRQ_MASK | SOFTIRQ_MASK | NMI_MASK)

irq_enter() 함수를 실행하면 thread_info 구조체의 preempt_count 필드가 0x10000이니 true를 반환합니다.

0x10000 & 0x001FFF00 (HARDIRQ_MASK | SOFTIRQ_MASK | NMI_MASK) // true

그럼 인터럽트 컨텍스트라는 정보가 업데이트되는 __irq_enter() 함수를 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/hardirq.h

1 #define __irq_enter() \

2 do { \

3 account_irq_enter_time(current); \

4 preempt_count_add(HARDIRQ_OFFSET); \

5 trace_hardirq_enter(); \

6 } while (0)

4번째 줄을 실행하면 thread_info 구조체의 preempt_count 필드에 HARDIRQ_OFFSET(0x10000) 비트를 더합니다.

preempt_count_add() 매크로 함수는 프로세스 스택의 최상단 주소에 접근해서 preempt_count 필드에 val인자를 더하는 동작을 수행합니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/preempt.h

#define preempt_count_add(val) __preempt_count_add(val)

인터럽트 서비스 루틴의 실행을 시작할 때 thread_info 구조체의 preempt_count 필드에 HARDIRQ_OFFSET 비트를 더하게 됩니다.

인터럽트 컨텍스트의 종료 상태 저장

이번에는 인터럽트 서비스 루틴을 종료한 다음에 호출하는 irq_exit() 함수를 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/softirq.c

1 void irq_exit(void)

2 {

...

3 account_irq_exit_time(current);

4 preempt_count_sub(HARDIRQ_OFFSET);

4번째 줄을 실행해서 thread_info 구조체의 preempt_count 필드에 HARDIRQ_OFFSET 비트를 뺍니다.

인터럽트 핸들링을 마무리한 다음 irq_exit() 함수를 실행하는 코드의 흐름은 다음 그림과 같습니다.

그림 4.17 인터럽트 컨텍스트가 해제될 때의 함수 흐름

보다시피 인터럽트 핸들링을 끝냈으니 다시 검은색 화살 방향으로 함수가 호출됩니다. 이 과정에서 irq_exit() 함수를 실행해서 thread_info 구조체의 preempt_count 필드에서 HARDIRQ_OFFSET 비트를 뺍니다.

이후 in_interrupt() 함수를 호출하면 false를 반환합니다. 그 이유는 irq_exit() 함수를 실행하면 thread_info 구조체의 preempt_count 필드가 0x0으로 바뀌기 때문입니다.

이를 연산하는 과정은 다음과 같습니다.

false = 0x0000 & 0x001FFF00 (HARDIRQ_MASK | SOFTIRQ_MASK | NMI_MASK)

irq_exit() 함수를 호출한 이후에는 리눅스 커널이 인터럽트 컨텍스트가 아니라고 판단하는 것입니다. 리눅스 커널에서 실행 중인 코드가 인터럽트 컨텍스트인지 점검하는 루틴은 자주 볼 수 있습니다.

지금까지의 소스 분석으로 다음과 같은 내용을 알게 됐습니다.

 인터럽트 컨텍스트의 실행 여부를 프로세스 스택의 최상단 주소에 있는 thread_info 구조체의 preempt_count 필드에 저장함

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : 리눅스커널, preempt_count, thread_info, 프로세스

트랙백(0)핑백(28)덧글(0)

[리눅스커널] 프로세스: thread_info 구조체란? 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 13:38
rousalome.egloos.com/10012008
덧글수 : 0

지금까지 프로세스 속성을 관리하는 자료구조인 태스크 디스크립터를 배웠습니다. 커널에서는 태스크 디스크립터뿐만 아니라 thread_info 구조체로 프로세스 실행 동작을 관리합니다.

이번 절에서는 thread_info 구조체를 소개하고 각 필드의 의미를 살펴보겠습니다. 또한 thread_info 구조체 중 preempt_count 필드를 중심으로 프로세스의 실행 흐름을 분석하겠습니다.

thread_info 구조체란?

태스크 디스크립터는 프로세스의 공통 속성 정보를 저장하고 관리합니다. 추가로 커널에서는 프로세스의 세부 실행 정보를 저장하거나 로딩하는 자료구조가 필요한데 이를 thread_info 구조체에서 관리합니다.

thread_info 구조체는 다음과 같은 프로세스의 핵심 실행 정보를 저장합니다.

 선점 스케줄링 실행 여부

 시그널 전달 여부

 인터럽트 컨텍스트와 Soft IRQ 컨텍스트 상태

 휴면 상태로 진입하기 직전 레지스터 세트를 로딩 및 백업

그럼 thread_info 구조체의 정체가 무엇인지 좀 더 자세히 알아보겠습니다.

먼저 thread_info 구조체는 어디에 있을까요? thread_info 구조체는 프로세스 스택에서 최상단 주소에 있습니다. 프로세스마다 자신만의 스택이 있으니 프로세스마다 1개의 thread_info 구조체가 있는 셈입니다.

thread_info 구조체는 다음과 같은 프로세스의 세부 실행 정보를 저장합니다.

 컨텍스트 정보

 스케줄링 직전 실행했던 레지스터 세트

 프로세스 세부 실행 정보

그런데 위에서 언급한 동작은 CPU 아키텍처마다 구현 방식이 다릅니다. 즉, x86, ARMv7, ARMv8, PowerPC별로 구현 방식이 다릅니다. 그래서 CPU 아키텍처별로 프로세스의 세부 정보를 저장하는 자료구조인 thread_info 구조체가 필요한 것입니다.

다음 코드의 검색 결과를 보면서 아키텍처별 thread_info 구조체를 확인해 보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/ident/thread_info

arch/alpha/include/asm/thread_info.h, line 15 (as a struct)

arch/arc/include/asm/thread_info.h, line 42 (as a struct)

arch/arm/include/asm/thread_info.h, line 49 (as a struct)

arch/arm64/include/asm/thread_info.h, line 39 (as a struct)

...

arch/x86/include/asm/thread_info.h, line 56 (as a struct)

다음은 x86 아키텍처의 thread_info 구조체 선언부입니다.

https://elixir.bootlin.com/linux/v4.19.30/source/arch/x86/include/asm/thread_info.h

struct thread_info {

unsigned long flags; /* low level flags */

u32 status; /* thread synchronous flags */

};

thread_info 구조체의 필드가 2개밖에 없습니다.

다음은 ARMv7 아키텍처의 thread_info 구조체 선언부입니다.

https://elixir.bootlin.com/linux/v4.19.30/source/arch/arm/include/asm/thread_info.h

struct thread_info {

unsigned long flags; /* low level flags */

int preempt_count; /* 0 => preemptable, <0 => bug */

mm_segment_t addr_limit; /* address limit */

struct task_struct *task; /* main task structure */

__u32 cpu; /* cpu */

...

};

라즈비안에서는 ARMv7 아키텍처에서 실행되므로 위 경로에 있는 thread_info 구조체로 프로세스의 세부 동작을 관리합니다.

이번에는 thread_info 구조체에 대해 정리해 봅시다. 먼저 태스크 디스크립터인 task_struct 구조체와 thread_info 구조체의 차이점은 무엇일까요?

태스크 디스크립터인 task_struct 구조체는 CPU 아키텍처에 독립적인 프로세스 관리용 속성을 저장합니다. 커널 버전이 같으면 x86이나 ARMv7에서 task_struct 구조체의 기본 필드는 같습니다. 하지만 thread_info 구조체는 CPU 아키텍처에 종속적인 프로세스의 세부 속성을 저장하므로 서로 다릅니다.

thread_info 구조체에서 관리하는 커널의 핵심 동작은 무엇인가요? thread_info 구조체에서 관리하는 커널의 세부 동작은 다음과 같습니다.

 현재 실행 중인 코드가 인터럽트 컨텍스트인지 여부

 현재 프로세스가 선점 가능한 조건인지 점검

 프로세스가 시그널을 받았는지 여부

 컨텍스트 스케줄링 전후로 실행했던 레지스터 세트를 저장하거나 로딩

이번에는 thread_info 구조체를 소개했습니다. 이어서 thread_info 구조체의 세부 필드를 살펴보겠습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(29)덧글(0)

[리눅스커널] 프로세스: 태스크 디스크립터(task_struct 구조체) - 프로세스 연결 리스트 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 13:25
rousalome.egloos.com/10012007
덧글수 : 0

task_struct 구조체의 tasks 필드는 list_head 구조체로서 연결 리스트 타입입니다. 커널에서 구동 중인 모든 프로세스는 tasks 연결 리스트에 등록돼 있습니다. 그렇다면 프로세스의 태스크 디스크립터 tasks 연결 리스트 필드는 언제 init 프로세스의 태스크 디스크립터 tasks 연결 리스트에 등록될까요?

프로세스는 처음 생성될 때 init_task 전역변수 필드인 tasks 연결 리스트에 등록됩니다. 프로세스를 생성할 때 호출되는 copy_process() 함수를 보면서 처리 과정을 살펴보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/fork.c

1 static __latent_entropy struct task_struct *copy_process(

2 unsigned long clone_flags,

3 unsigned long stack_start,

4 unsigned long stack_size,

5 int __user *child_tidptr,

6 struct pid *pid,

7 int trace,

8 unsigned long tls,

9 int node)

10 {

11 struct task_struct *p;

12 p = dup_task_struct(current, node);

...

13 list_add_tail_rcu(&p->tasks, &init_task.tasks);

12번째 줄을 실행하면 커널로부터 태스크 디스크립터를 할당받습니다. 다음 13번째 줄에서는 init_task.tasks 연결 리스트의 마지막 노드에 현재 프로세스의 task_struct 구조체의 tasks 주소를 등록한다.

자료구조를 변경하는 커널 코드를 읽으니 감이 잘 오지 않습니다. 이번에는 프로세스 태스크 디스크립터의 전체 구조에서 tasks 필드를 확인해 봅시다.

1 (static struct task_struct) [D:0xA1A171B8] init_task = (

2 (long int) [D:0xA1A171B8] state = 0,

3 (void *) [D:0xA1A171BC] stack = 0xA1A00000,

...

4 (struct sched_info) [D:0xA1A174A8] sched_info = ((long unsigned int) pcount = 0,

5 (struct list_head) [D: 0xA1A174C8] tasks = (

6 (struct list_head *) [D:0xA1A174E8] next = 0xA1618310 -> (

7 (struct list_head *) [D:0xA1618330] next = 0xB1618A70,

8 (struct list_head *) [D:0xA1618334] prev = 0xA1A174E8),

9 (struct list_head *) [D: 0xA1A174CC] prev = 0xA7778330),

init_task.tasks 필드 구조체는 list_head 구조체의 연결 리스트이며 6~7번째 줄의 디버깅 정보와 같이 next 필드를 가리키고 있습니다. init_task 전역변수는 task_struct 구조체와 같이 태스크 디스크립터라는 점을 기억합시다.

6번째 줄에서 init_task.tasks.next는 0xA1618330 주소를 가리키고 있습니다. 이 주소는 어떤 의미일까요? 바로 init_task.tasks 연결 리스트에 추가된 다음 프로세스의 task_struct 구조체의 tasks 필드 주소를 가리킵니다. 이 처리 흐름을 그림으로 표현하면 다음과 같습니다.

그림 4.14에서 [1]로 표시된 부분을 보면 태스크 디스크립터의 next 필드는 0xA1618310 주소를 가리킵니다. 여기서 중요한 질문을 던지겠습니다. 0xA1618310 주소의 정체는 무엇일까요? 바로 연결 리스트에 등록된 다음 프로세스 태스크 디스크립터의 next 필드 주소를 의미합니다. [1]에서 시작된 화살표 끝부분이 가리키는 박스를 보면 0xA1618310 주소가 보입니다. 이는 0xA1618000 주소에 있는 태스크 디스크립터의 tasks 필드의 주소인 것입니다.

이번에는 그림 4.14에서 [2]로 표시된 부분을 눈으로 따라가 보겠습니다. next 필드는 0xA16191B0 주소를 가리킵니다. 0xA16191B0 주소는 연결 리스트에 등록된 다음 프로세스 태스크 디스크립터의 next 필드 주소를 의미합니다. 모든 프로세스가 이렇게 연결 리스트로 등록돼 있습니다. 이 방식으로 커널에서 구동 중인 모든 프로세스의 태스크 디스크립터 주소를 알 수 있습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(29)덧글(0)

[리눅스커널] 프로세스: 태스크 디스크립터(task_struct 구조체) - 프로세스 상태 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 13:21
rousalome.egloos.com/10012006
덧글수 : 0

태스크 디스크립터에는 프로세스 상태를 관리하는 다음과 같은 두 가지 필드가 있습니다.

 state: 프로세스 실행 상태

 flags: 프로세스 세부 동작 상태와 속성 정보

먼저 프로세스의 상태를 저장하는 state 필드를 소개합니다.

volatile long state;

프로세스 상태를 저장하는 필드로 다음 매크로 중 하나를 저장합니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/sched.h

#define TASK_RUNNING 0x0000

#define TASK_INTERRUPTIBLE 0x0001

#define TASK_UNINTERRUPTIBLE 0x0002

위 매크로에서 정의한 프로세스의 상태는 다음과 같습니다.

 TASK_RUNNING: CPU에서 실행 중이거나 런큐에서 대기 상태에 있음

 TASK_INTERRUPTIBLE: 휴면 상태

 TASK_UNINTERRUPTIBLE: 특정 조건에서 깨어나기 위해 휴면 상태로 진입한 상태

리눅스 시스템에서 확인되는 프로세스들은 대부분 TASK_INTERRUPTIBLE 상태입니다. TASK_RUNNING 혹은 TASK_UNINTERRUPTIBLE 상태인 프로세스가 비정상적으로 많으면 시스템에 문제(데드락, 특정 프로세스 스톨)가 있는 경우가 많습니다.

---

프로세스 상태별 세부 동작 방식은 10장 ‘프로세스 스케줄링’에서 상세히 다룹니다.

---

다음으로 flags 필드를 소개합니다.

unsigned int flags;

프로세스 종류와 프로세스 세부 실행 상태를 저장하는 필드입니다. flags 필드는 PF_*로 시작하는 매크로 필드를 OR 연산한 결과를 저장합니다.

PF_* 매크로 가운데 눈여겨볼 만한 코드는 다음과 같습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/sched.h

#define PF_IDLE 0x00000002 /* I am an IDLE thread */

#define PF_EXITING 0x00000004 /* Getting shut down */

#define PF_EXITPIDONE 0x00000008 /* PI exit done on shut down */

#define PF_WQ_WORKER 0x00000020 /* I'm a workqueue worker */

#define PF_KTHREAD 0x00200000 /* I am a kernel thread */

각 매크로의 의미는 다음과 같습니다.

 PF_IDLE: 아이들 프로세스

 PF_EXITING: 프로세스 종료 중인 상태

 PF_EXITPIDONE: 프로세스 종료를 마무리한 상태

 PF_WQ_WORKER: 프로세스가 워커 스레드인 경우

 PF_KTHREAD: 프로세스가 커널 스레드인 경우

flags 필드에 저장된 값으로 프로세스의 세부 실행 상태를 알 수 있습니다. 커널은 flags에 저장된 프로세스의 세부 동작 상태를 읽어서 프로세스를 제어합니다. 그래서 이번에는 flags 필드로 프로세스의 실행 흐름을 제어하는 한 가지 예를 들어 보겠습니다.

https://elixir.bootlin.com/linux/v3.7/source/drivers/staging/android/lowmemorykiller.c

1 static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc)

2 {

3 struct task_struct *tsk;

4 struct task_struct *selected = NULL;

5 int rem = 0;

...

6 for_each_process(tsk) {

7 struct task_struct *p;

8 int oom_score_adj;

9

10 if (tsk->flags & PF_KTHREAD)

11 continue;

12

13 p = find_lock_task_mm(tsk);

14 if (!p)

15 continue;

...

16 lowmem_print(2, "select %d (%s), adj %d, size %d, to kill\n",

17 p->pid, p->comm, oom_score_adj, tasksize);

18 }

위 코드는 안드로이드에서 메모리 회수를 위해 특정 프로세스를 종료하는 lowmem_shrink() 함수의 일부분입니다. 이 코드에서 10~11 번째 줄을 봅시다.

10 if (tsk->flags & PF_KTHREAD)

11 continue;

10번째 줄에서는 태스크 디스크립터의 flags 필드와 PF_KTHREAD 매크로를 대상으로 AND 연산을 수행합니다. 이 조건을 만족하면 11번째 줄을 실행해 아래 부분의 코드를 실행하지 않습니다. 이 코드의 의도는 프로세스 타입이 커널 스레드이면 프로세스를 종료하지 않겠다는 것입니다. 이 같은 방식으로 프로세스 실행 정보를 읽어서 예외 처리를 수행합니다.

이어서 exit_state 필드를 확인해봅시다.

int exit_state;

프로세스 종료 상태를 저장합니다. 다음 매크로 중 하나 값을 저장합니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/sched.h

/* Used in tsk->exit_state: */

#define EXIT_DEAD 0x0010

#define EXIT_ZOMBIE 0x0020

#define EXIT_TRACE (EXIT_ZOMBIE | EXIT_DEAD)

마지막으로 exit_code 필드를 확인해봅시다.

int exit_code;

프로세스의 종료 코드를 저장하는 필드입니다. do_exit() 함수의 3번째 줄에서 종료 코드를 저장합니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/exit.c

1 void __noreturn do_exit(long code)

2 {

...

3 tsk->exit_code = code;

do_exit() 함수를 호출할 때 인자로 다음과 같은 시그널이나 프로세스를 종료하는 옵션을 지정할 수 있습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/arch/arm/mm/fault.c

01 static void

02 __do_kernel_fault(struct mm_struct *mm, unsigned long addr, unsigned int fsr,

03 struct pt_regs *regs)

04 {

...

05 do_exit(SIGKILL);

06 }

5번째 줄을 보면 SIGKILL 인자와 함께 do_exit() 함수를 호출합니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : 리눅스커널, 태스크디스크립터

트랙백(0)핑백(29)덧글(0)

[리눅스커널] 프로세스: do_task_dead() 함수를 호출하고 난 후의 동작 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 13:18
rousalome.egloos.com/10012005
덧글수 : 0

do_task_dead() 함수에서 __schedule() 함수를 호출하고 나면 커널은 어떻게 프로세스를 소멸시킬까요? 먼저 __schedule() 함수를 호출하면 어떤 흐름으로 finish_task_switch() 함수를 호출하는지 살펴보겠습니다. 다음은 이번 절에서 분석할 함수의 목록입니다.

 __schedule() 함수

 context_switch() 함수

 finish_task_switch() 함수

위 함수들이 실행되면서 다음과 같은 과정으로 프로세스가 소멸됩니다.

 종료할 프로세스는 do_exit() 함수에서 대부분 자신의 리소스를 커널에게 반납하고 자신의 상태를 TASK_DEAD로 바꾼다.

 컨텍스트 스위칭을 한다.

 컨텍스트 스위칭으로 다음에 실행하는 프로세스는 finish_task_switch() 함수에서 이전에 실행했던 프로세스 상태(종료할 프로세스)가 TASK_DEAD이면 프로세스 스택 공간을 해제한다.

조금 끔찍한 비유를 들면서 이 동작 방식을 설명하겠습니다. 전쟁 영화에서 '자살을 하기 두려운 병사가 다른 동료에게 자신을 죽여달라고 권총을 주는 장면'을 본 적이 있나요? 이와 조금 비슷한 상황인데, 프로세스가 스스로 자신의 스택 메모리 공간을 해제하지 못하니 컨텍스트 스위칭을 수행한 후 다음에 실행되는 프로세스에게 자신의 스택 메모리 공간을 해제하고 소멸시켜 달라고 부탁하는 것입니다.

실행 흐름을 설명했으니 __schedule() 함수를 보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c

01 static void __sched notrace __schedule(bool preempt)

02 {

...

03 if (likely(prev != next)) {

...

04 rq = context_switch(rq, prev, next, &rf);

05 } else {

06 rq->clock_update_flags &= ~(RQCF_ACT_SKIP|RQCF_REQ_SKIP);

07 rq_unlock_irq(rq, &rf);

08 }

...

09 }

04번째 줄에서 context_switch() 함수를 호출해 컨텍스트 스위칭을 실행합니다.

다음으로 context_switch() 함수를 보겠습니다.

[https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c]

01 static __always_inline struct rq *

02 context_switch(struct rq *rq, struct task_struct *prev,

03 struct task_struct *next, struct rq_flags *rf)

04 {

...

05 switch_to(prev, next, prev);

06 barrier();

07

08 return finish_task_switch(prev);

09 }

08 번째 줄에서는 finish_task_switch() 함수를 호출합니다. schedule() 함수를 호출하면 결국 finish_task_switch() 함수가 호출됩니다.

---

__schedule() 함수와 context_switch() 함수를 실행해 프로세스가 컨텍스트 스위칭이 이뤄지는 과정은 10장 '스케줄링'의 10.9절을 참고하세요.

---

__schedule() 함수에서 finish_task_switch() 함수까지 호출되는 흐름을 살펴봤으니 이번에는 finish_task_switch() 함수를 분석할 차례입니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c

01 static struct rq *finish_task_switch(struct task_struct *prev)

02 __releases(rq->lock)

03 {

...

04 if (unlikely(prev_state == TASK_DEAD)) {

05 if (prev->sched_class->task_dead)

06 prev->sched_class->task_dead(prev);

07

08 kprobe_flush_task(prev);

09

10 put_task_stack(prev);

11

12 put_task_struct(prev);

13 }

04번째 줄은 이전에 실행했던 프로세스 상태가 TASK_DEAD일 때 05~12번째 줄을 실행하는 조건문입니다.

10번째 줄을 보겠습니다. put_task_stack() 함수를 호출해서 프로세스 스택 메모리 공간을 해제하고 커널 메모리 공간에 반환합니다.

이어서 12번째 줄에서는 put_task_struct() 함수를 실행해 프로세스를 표현하는 자료구조인 task_struct가 위치한 메모리를 해제합니다.

finish_task_switch() 함수에 ftrace 필터를 걸고 finish_task_switch() 함수가 호출되는 함수 흐름을 확인하면 다음과 같습니다.

01 TaskSchedulerSe-1803 [000] .... 2630.705218: do_exit+0x14/0xbe0 <-do_group_exit+0x50/0xe8

02 TaskSchedulerSe-1803 [000] .... 2630.705234: <stack trace>

03 => do_exit+0x18/0xbe0

04 => do_group_exit+0x50/0xe8

05 => get_signal+0x160/0x7dc

06 => do_signal+0x274/0x468

07 => do_work_pending+0xd4/0xec

08 => slow_work_pending+0xc/0x20

09 => 0x756df704

10 TaskSchedulerSe-1803 [000] dns. 2630.705438: sched_wakeup: comm=rcu_sched pid=10 prio=120 target_cpu=000

11 TaskSchedulerSe-1803 [000] dnh. 2630.705466: sched_wakeup: comm=jbd2/mmcblk0p2- pid=77 prio=120 target_cpu=000

12 TaskSchedulerSe-1803 [000] d... 2630.705479: sched_switch: prev_comm=TaskSchedulerSe prev_pid=1803 prev_prio=120 prev_state=R+ ==> next_comm=rcu_sched next_pid=10 next_prio=120

13 rcu_sched-10 [000] d... 2630.705483: finish_task_switch+0x14/0x230 <-__schedule+0x328/0x9b0

14 rcu_sched-10 [000] d... 2630.705504: <stack trace>

15 => finish_task_switch+0x18/0x230

16 => __schedule+0x328/0x9b0

17 => schedule+0x50/0xa8

18 => rcu_gp_kthread+0xdc/0x9fc

19 => kthread+0x140/0x170

20 => ret_from_fork+0x14/0x28

위 ftrace 메시지는 TaskSchedulerSe-1803 프로세스가 종료되는 과정을 담고 있습니다.

01~08번째 줄 메시지를 보겠습니다.

01 TaskSchedulerSe-1803 [000] .... 2630.705218: do_exit+0x14/0xbe0 <-do_group_exit+0x50/0xe8

02 TaskSchedulerSe-1803 [000] .... 2630.705234: <stack trace>

03 => do_exit+0x18/0xbe0

04 => do_group_exit+0x50/0xe8

05 => get_signal+0x160/0x7dc

06 => do_signal+0x274/0x468

07 => do_work_pending+0xd4/0xec

08 => slow_work_pending+0xc/0x20

TaskSchedulerSe-1803 프로세스가 종료 시그널을 받고 do_exit() 함수를 호출합니다.

다음 12번째 줄입니다.

12 TaskSchedulerSe-1803 [000] d... 2630.705479: sched_switch: prev_comm=TaskSchedulerSe prev_pid=1803 prev_prio=120 prev_state=R+ ==> next_comm=rcu_sched next_pid=10 next_prio=120

TaskSchedulerSe-1803 프로세스에서 pid가 10인 rcu_sched 프로세스로 스케줄링됩니다.

마지막으로 13~20번째 줄을 보겠습니다.

13 rcu_sched-10 [000] d... 2630.705483: finish_task_switch+0x14/0x230 <-__schedule+0x328/0x9b0

14 rcu_sched-10 [000] d... 2630.705504: <stack trace>

15 => finish_task_switch+0x18/0x230

16 => __schedule+0x328/0x9b0

17 => schedule+0x50/0xa8

18 => rcu_gp_kthread+0xdc/0x9fc

19 => kthread+0x140/0x170

20 => ret_from_fork+0x14/0x28

rcu_sched 프로세스는 finish_task_switch() 함수에서 TaskSchedulerSe-1803 프로세스의 마지막 리소스를 정리합니다.

TaskSchedulerSe-1803 프로세스는 do_exit() 함수에서 태스크 디스크립터의 여러 필드를 해제했습니다. 그런데 do_exit() 함수를 TaskSchedulerSe-1803 프로세스의 스택 공간에서 실행 중이니 스스로 자신의 스택 공간을 해제할 수 없습니다. 따라서 스케줄링을 한 후 다음에 실행하는 프로세스인 rcu_sched가 종료되는 TaskSchedulerSe-1803 프로세스의 스택 메모리 공간을 해제하는 것입니다.

이번 절에서는 프로세스가 생성되고 종료되는 흐름을 살펴봤습니다. 이어서 프로세스를 표현하고 관리하는 프로세스 자료구조를 살펴보겠습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(34)덧글(0)

[리눅스커널] 프로세스: do_task_dead() 함수 분석 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 13:15
rousalome.egloos.com/10012004
덧글수 : 0

이어서 do_task_dead() 함수를 분석하겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c

01 void __noreturn do_task_dead(void)

02 {

03 set_special_state(TASK_DEAD);

04 current->flags |= PF_NOFREEZE;

05

06 __schedule(false);

07 BUG();

08 for (;;)

09 cpu_relax();

10 }

03번째 줄에서 set_special_state() 함수를 호출해 프로세스 상태를 TASK_DEAD 플래그로 바꿉니다. 04번째 줄에서는 프로세스 태스크 디스크립터의 flags 필드에 PF_NOFREEZE 플래그를 OR 연산으로 적용합니다.

---

current는 현재 실행 중인 프로세스 태스크 디스크립터 자료구조로서 task_struct 구조체 타입입니다.

---

06번째 줄에서는 __schedule(false) 함수를 호출해 스케줄링을 요청합니다. __schedule() 함수에 false를 전달하는 이유는 선점 스케줄링을 실행하지 않겠다는 의미입니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

** 선점 스케줄링 여부 확인

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: 프로세스 종료 흐름 파악 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 13:11
rousalome.egloos.com/10012003
덧글수 : 0

프로세스는 크게 두 가지 흐름으로 종료됩니다.

 유저 애플리케이션에서 exit() 함수를 호출할 때

 종료 시그널을 전달받을 때

먼저 프로세스가 종료되는 흐름을 알아보겠습니다.

커널에서 제공하는 do_exit() 함수를 실행하면 프로세스를 종료할 수 있습니다. do_exit() 함수에서 커널이 프로세스를 종료하는 코드를 분석하기에 앞서 do_exit() 함수가 어떤 흐름으로 호출되는지 살펴봅시다. 다음 그림은 프로세스가 종료되는 두 가지 흐름입니다.

그림 4.11 유저 프로세스가 종료될 때의 실행 흐름

exit() 시스템 콜 실행

그림 4.11의 왼쪽은 유저 공간에서 exit 시스템 콜을 발생시켰을 때 프로세스가 종료되는 흐름입니다. 보통 유저 프로세스가 정해진 시나리오에 따라 종료해야 할 때 exit() 함수를 호출합니다. 시스템 콜을 발생시킨 후 해당 시스템 콜 핸들러인 sys_group_exit() 함수를 호출합니다. 이후 do_exit() 함수를 호출합니다.

종료 시그널을 전달받았을 때

그림 4.11의 오른쪽은 POSIX kill 시그널을 받아 프로세스가 소멸하는 흐름입니다. 유저 프로세스뿐만 아니라 커널 프로세스도 커널 내부에서 종료 시그널을 받으면 소멸됩니다. 참고로 커널 함수로 send_signal() 함수를 호출하면 특정 프로세스 종료 시그널을 전달할 수 있습니다. 종료 시그널을 받은 프로세스는 do_exit() 함수를 실행해 종료됩니다.

do_exit() 함수로 커널이 프로세스를 종료시키는 세부 동작 못지 않게 프로세스가 종료되는 흐름을 파악하는 것이 중요합니다. 그 이유는 무엇일까요? 유저 애플리케이션 프로세스나 커널 프로세스가 예외 상황에서 의도하지 않게 종료해서 문제가 발생하는 경우가 있기 때문입니다.

프로세스가 종료될 때 처리되는 흐름을 알면 이런 문제를 만났을 때 커널의 어느 함수부터 분석해야 할지 결정할 수 있습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

** 선점 스케줄링 여부 확인

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: wake_up_new_task() 함수 분석 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 10:53
rousalome.egloos.com/10011994
덧글수 : 0

프로세스 생성의 마지막 단계로 생성한 프로세스를 깨웁니다. 이 동작은 wake_up_new_task() 함수가 수행합니다.

 프로세스 상태를 TASK_RUNNING으로 변경

 현재 실행 중인 CPU 번호를 thread_info 구조체의 cpu 필드에 저장

 런큐에 프로세스를 큐잉

이번 절에서는 다음 wake_up_new_task() 함수를 분석하겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/sched/core.c

1 void wake_up_new_task(struct task_struct *p)

2 {

3 struct rq_flags rf;

4 struct rq *rq;

5

6 add_new_task_to_grp(p);

7 raw_spin_lock_irqsave(&p->pi_lock, rf.flags);

8

9 p->state = TASK_RUNNING;

10 #ifdef CONFIG_SMP

11 __set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0, 1));

12 #endif

13 rq = __task_rq_lock(p, &rf);

14 update_rq_clock(rq);

15 post_init_entity_util_avg(&p->se);

16

17 mark_task_starting(p);

18 activate_task(rq, p, ENQUEUE_NOCLOCK);

wake_up_new_task() 함수의 인자인 task_struct *p는 새롭게 생성된 프로세스의 태스크 디스크립터입니다.

9 번째 줄을 보겠습니다.

9 p->state = TASK_RUNNING;

프로세스 상태를 TASK_RUNNING으로 바꿉니다.

다음으로 11 번째 줄을 봅시다.

11 __set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0, 1));

__set_task_cpu() 함수를 호출해 프로세스의 thread_info 구조체의 cpu 필드에 현재 실행 중인 CPU 번호를 저장합니다.

마지막으로 13~17 번째 줄을 봅시다.

13 rq = __task_rq_lock(p, &rf);

14 update_rq_clock(rq);

15 post_init_entity_util_avg(&p->se);

16

17 mark_task_starting(p);

18 activate_task(rq, p, ENQUEUE_NOCLOCK);

13번째 줄에서 런큐 주소를 읽은 다음, 18번째 줄에서 activate_task() 함수를 호출해 런큐에 새롭게 생성한 프로세스를 큐잉합니다. 그런데 여기서 생성한 프로세스를 바로 실행할 수 있을까요?

프로세스 스케줄러는 런큐에 대기 중인 프로세스와 우선순위를 계산해 새로 생성된 프로세스를 실행할지 결정합니다. 만약 실행을 기다리는 프로세스가 많거나 우선순위가 높은 프로세스가 이미 실행 중이면 새롭게 생성된 프로세스를 바로 실행할 수는 없습니다. 하지만 일반적인 상황에서 새로 생성된 프로세스는 바로 실행합니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: copy_process() 함수 분석 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 10:50
rousalome.egloos.com/10011993
덧글수 : 0

프로세스를 생성하는 핵심 동작은 copy_process() 함수에서 수행합니다. 대부분 부모 프로세스에 있는 리소스를 복사하는 동작입니다. 그럼 copy_process() 함수 코드를 본격적으로 분석해 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/fork.c

1 static __latent_entropy struct task_struct *copy_process(

2 unsigned long clone_flags,

3 unsigned long stack_start,

4 unsigned long stack_size,

5 int __user *child_tidptr,

6 struct pid *pid,

7 int trace,

8 unsigned long tls,

9 int node)

10 {

11 int retval;

12 struct task_struct *p;

...

13 retval = -ENOMEM;

14 p = dup_task_struct(current, node);

15 if (!p)

16 goto fork_out;

...

17 /* Perform scheduler related setup. Assign this task to a CPU. */

18 retval = sched_fork(clone_flags, p);

19 if (retval)

20 goto bad_fork_cleanup_policy;

21

...

22 retval = copy_files(clone_flags, p);

23 if (retval)

24 goto bad_fork_cleanup_semundo;

25 retval = copy_fs(clone_flags, p);

26 if (retval)

27 goto bad_fork_cleanup_files;

28 retval = copy_sighand(clone_flags, p);

29 if (retval)

30 goto bad_fork_cleanup_fs;

먼저 14번째 줄을 봅시다.

14 p = dup_task_struct(current, node);

15 if (!p)

16 goto fork_out;

dup_task_struct() 함수는 생성할 프로세스의 태스크 디스크립터인 task_struct 구조체와 커널 프로세스 스택 공간을 할당합니다. 이후 task_struct 구조체 주소를 반환합니다. dup_task_struct() 함수를 호출해 태스크 디스크립터를 p에 저장합니다.

다음으로 18번째 줄을 보겠습니다.

18 retval = sched_fork(clone_flags, p);

19 if (retval)

20 goto bad_fork_cleanup_policy;

태스크 디스크립터를 나타내는 task_struct 구조체에서 스케줄링 관련 정보를 초기화합니다.

다음으로 22~27번째 줄을 분석하겠습니다.

22 retval = copy_files(clone_flags, p);

23 if (retval)

24 goto bad_fork_cleanup_semundo;

25 retval = copy_fs(clone_flags, p);

26 if (retval)

27 goto bad_fork_cleanup_files;

여기서는 프로세스의 파일 디스크립터 관련 내용(파일 디스크립터, 파일 디스크립터 테이블)을 초기화합니다. 부모 file_struct 구조체의 내용을 자식 프로세스에게 복사합니다. 만약 프로세스 생성 플래그 중 CLONE_FILES로 프로세스를 생성했을 경우 참조 카운트만 증가합니다.

다음으로 분석할 코드는 29번째 줄입니다.

28 retval = copy_sighand(clone_flags, p);

29 if (retval)

30 goto bad_fork_cleanup_fs;

프로세스가 등록한 시그널 핸들러 정보인 sighand_struct 구조체를 생성해서 복사합니다.

이번 절까지 프로세스를 생성하는 함수를 살펴봤습니다. 이번 절에서는 copy_process() 함수를 실행해 부모 프로세스의 리소스를 새로 생성하는 프로세스의 task_struct 구조체에 복제하는 과정을 살펴봤습니다.

그런데 프로세스를 생성하는 과정은 여기서 끝일까요? 그렇지 않습니다. 생성한 프로세스를 바로 실행해야 합니다. 다음 절에서 이 내용을 다루겠습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: 커널 스레드는 어떻게 생성할까? 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 09:32
rousalome.egloos.com/10011978
덧글수 : 0

이어서 커널 스레드를 생성하는 과정에서 호출되는 함수를 소개하고 세부 코드를 분석하겠습니다. 커널 스레드가 생성되는 과정은 크게 2단계로 나눌 수 있습니다.

1) 1단계: kthreadd 프로세스에게 커널 스레드 생성을 요청

 kthread_create()

 kthread_create_on_node()

2) 2단계: kthreadd 프로세스가 커널 스레드를 생성

 kthreadd()

 create_kthread()

각 단계별로 실행되는 함수를 살펴보겠습니다.

1단계: kthreadd 프로세스에게 커널 스레드 생성 요청

유저 프로세스를 생성하려면 fork() 함수를 호출해야 하듯이, 커널 스레드를 생성하려면 kthread_create() 커널 함수를 호출해야 합니다. 먼저 kthreadd 프로세스에게 커널 스레드 생성 요청을 하는 함수 실행 흐름을 살펴보겠습니다(그림 4.6).

그림 4.6 커널 스레드 생성 흐름도 1단계

이 그림에서 왼쪽 부분은 커널 스레드 생성을 kthreadd 프로세스에게 요청하는 동작입니다.

kthread_create() 함수 분석

커널 스레드를 생성하려면 먼저 kthread_create() 함수를 호출해야 합니다. 다음 코드는 kthread_create() 함수로서, 매크로 형태로 작성된 것을 알 수 있습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/kthread.h

1 #define kthread_create(threadfn, data, namefmt, arg...) \

2 kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)

3

4 struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),

5 void *data, int node,

6 const char namefmt[],

7 ...)

먼저 함수에 전달하는 인자부터 살펴봅시다.

 int (*threadfn)(void *data)

스레드 핸들 함수 주소를 저장하는 필드입니다. 커널 스레드의 세부 동작은 스레드 핸들 함수에 구현돼 있습니다.

 void *data

스레드 핸들 함수로 전달하는 매개변수입니다. 주로 주소를 전달하며, 스레드를 식별하는 구조체의 주소를 전달합니다.

 int node

노드 정보입니다.

 const char namefmt[]

커널 스레드 이름을 저장합니다.

kthread_create() 함수를 호출할 때 전달하는 인자를 알아봤습니다. 하지만 kthread_create() 함수 구현부만 봐서는 커널 스레드를 생성할 때 어떤 인자를 전달하는지 알기 어렵습니다. 이어서 커널 스레드를 생성하는 예제 코드를 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/drivers/vhost/vhost.c

1 long vhost_dev_set_owner(struct vhost_dev *dev)

2 {

3 struct task_struct *worker;

4 int err;

...

5 /* No owner, become one */

6 dev->mm = get_task_mm(current);

7 worker = kthread_create(vhost_worker, dev, "vhost-%d", current->pid);

7번째 줄을 보면 kthread_create() 함수의 첫 번째 인자로 vhost_worker 스레드 핸들 함수의 이름을 지정합니다.

7 worker = kthread_create(vhost_worker, dev, "vhost-%d", current->pid);

2번째 인자로 dev 변수를 지정하는데, 1번째 줄의 함수 인자를 보면 dev가 어떤 구조체인지 알 수 있습니다. vhost_dev 구조체의 주소를 2번째 인자로 전달하는 것입니다. 이 방식으로 전달하는 인자를 매개변수 혹은 디스크립터라고도 부릅니다.

3번째 인자로 "vhost-%d"를 전달합니다. 이는 커널 스레드 이름을 나타냅니다.

---

이번에는 스레드 핸들 함수로 전달되는 매개변수를 점검해 봅시다. vhost_worker() 함수의 코드를 보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/drivers/vhost/vhost.c

01 static int vhost_worker(void *data)

02 {

03 struct vhost_dev *dev = data;

04 struct vhost_work *work, *work_next;

05 struct llist_node *node;

vhost_dev_set_owner() 함수에서 kthread_create() 함수를 호출할 때 두 번째 인자로 vhost_dev 구조체인 dev를 지정했습니다. 이 주소가 스레드 핸들인 vhost_worker() 함수의 인자로 전달되는 것입니다.

이처럼 vhost_worker() 스레드 핸들 함수의 매개변수로 인자를 전달합니다. 1번째 줄에서 보이는 void 타입의 data 포인터를 vhost_dev 구조체로 형변환(캐스팅)합니다.

커널에서는 이 같은 방식으로 스레드를 관리하는 구조체를 매개변수로 전달합니다.

---

kthread_create() 함수를 호출해 커널 스레드를 생성하는 예제를 봤으니 이어서 kthread_create() 함수의 구현부를 보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/include/linux/kthread.h

1 #define kthread_create(threadfn, data, namefmt, arg...) \

2 kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)

kthread_create() 함수는 선언부와 같이 매크로 타입입니다. 따라서 커널 컴파일 과정에서 전처리기는 kthread_create() 함수를 kthread_create_on_node() 함수로 바꿉니다. 즉, 커널이나 드라이버 코드에서 kthread_create() 함수를 호출하면 실제로 동작하는 코드는 kthread_create_on_node() 함수인 것입니다.

kthread_create_on_node() 함수 분석

kthread_create() 매크로 함수의 실체인 kthread_create_on_node() 함수의 구현부를 보겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/kthread.c

1 struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),

2 void *data, int node,

3 const char namefmt[],

4 ...)

5 {

6 struct task_struct *task;

7 va_list args;

8

9 va_start(args, namefmt);

10 task = __kthread_create_on_node(threadfn, data, node, namefmt, args);

11 va_end(args);

12

13 return task;

14}

함수 구현부를 봐도 특별한 일은 하지 않습니다. 다만 가변 인자를 통해 __kthread_create_on_node() 함수를 호출할 뿐입니다. 결국 __kthread_create_on_node() 함수에서 커널 스레드 생성 요청을 합니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/kthread.c

1 struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),

2 void *data, int node,

3 const char namefmt[],

4 va_list args)

5 {

6 DECLARE_COMPLETION_ONSTACK(done);

7 struct task_struct *task;

8 struct kthread_create_info *create = kmalloc(sizeof(*create),

9 GFP_KERNEL);

10

11 if (!create)

12 return ERR_PTR(-ENOMEM);

13 create->threadfn = threadfn;

14 create->data = data;

15 create->node = node;

16 create->done = &done;

17

18 spin_lock(&kthread_create_lock);

19 list_add_tail(&create->list, &kthread_create_list);

20 spin_unlock(&kthread_create_lock);

21

22 wake_up_process(kthreadd_task);

먼저 8~9번째 줄 코드를 봅시다.

8 struct kthread_create_info *create = kmalloc(sizeof(*create),

9 GFP_KERNEL);

kmalloc() 함수를 호출해 kthread_create_info 구조체 크기만큼 동적 메모리를 할당받습니다.

다음 13~15번째 줄 코드를 봅시다.

13 create->threadfn = threadfn;

14 create->data = data;

15 create->node = node;

생성할 커널 스레드 핸들 함수와 매개변수 및 노드를 kthread_create_info 구조체의 필드에 저장합니다.

다음으로 19번째 줄 코드를 봅시다.

19 list_add_tail(&create->list, &kthread_create_list);

커널 스레드 생성 요청을 관리하는 kthread_create_list 연결 리스트에 &create->list를 추가합니다. kthreadadd 프로세스는 kthread_create_list 연결 리스트를 확인해 커널 스레드 생성 요청이 있었는지 확인합니다. 만약 kthread_create_list 연결 리스트가 비어 있지 않으면 누군가 커널 스레드 생성을 요청했으니 커널 스레드를 생성하는 일을 시작합니다.

다음은 __kthread_create_on_node() 함수의 핵심 코드인 22번째 줄입니다.

22 wake_up_process(kthreadd_task);

kthreadd 프로세스의 태스크 디스크립터인 kthreadd_task를 인자로 삼아 wake_up_process() 함수를 호출해서 kthreadd 프로세스를 깨웁니다.

2단계: kthreadd 프로세스가 커널 스레드를 생성

kthreadd 프로세스를 깨우면 kthreadd 프로세스 스레드 핸들인 kthreadd() 함수가 실행을 시작합니다.

그림 4.7 커널 스레드 생성 흐름: 2단계

먼저 이 그림에서 왼쪽 박스 부분을 눈으로 따라가 봅시다. 1단계에서 커널 스레드를 생성해 달라고 kthreadd 프로세스에게 요청했습니다. 그리고 kthreadd 프로세스를 깨웠습니다.

다음으로 오른쪽 박스 부분을 보겠습니다. kthreadd 프로세스를 깨우면 kthreadd 프로세스 스레드 핸들인 kthreadd() 함수가 호출되어 프로세스를 생성합니다.

kthreadd() 함수 분석

kthreadd 프로세스의 스레드 핸들인 kthreadd() 함수를 분석하겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/kthread.c

1 int kthreadd(void *unused)

2 {

3 struct task_struct *tsk = current;

4

5 /* Setup a clean context for our children to inherit. */

6 set_task_comm(tsk, "kthreadd");

7 ignore_signals(tsk);

8 set_cpus_allowed_ptr(tsk, cpu_all_mask);

9 set_mems_allowed(node_states[N_MEMORY]);

10

11 current->flags |= PF_NOFREEZE;

12 cgroup_init_kthreadd();

13

14 for (;;) {

15 set_current_state(TASK_INTERRUPTIBLE);

16 if (list_empty(&kthread_create_list))

17 schedule();

18 __set_current_state(TASK_RUNNING);

19

20 spin_lock(&kthread_create_lock);

21 while (!list_empty(&kthread_create_list)) {

22 struct kthread_create_info *create;

23

24 create = list_entry(kthread_create_list.next,

25 struct kthread_create_info, list);

26 list_del_init(&create->list);

27 spin_unlock(&kthread_create_lock);

28

29 create_kthread(create);

30

31 spin_lock(&kthread_create_lock);

32 }

33 spin_unlock(&kthread_create_lock);

34 }

복잡해 보이는 kthreadd() 함수의 핵심 기능은 다음과 같습니다.

 kthread_create_info 연결 리스트를 확인해 프로세스 생성 요청을 확인

 create_kthread() 함수를 호출해 프로세스를 생성

kthreadd() 함수 분석을 시작하기 전에 한 가지 생각해 볼 점이 있습니다. kthreadd 프로세스를 깨우면 kthreadd() 함수가 실행한다고 했는데, 실제 kthreadd() 함수의 어느 코드가 실행할까요?

kthreadd 프로세스는 kthreadd() 함수 내에서 프로세스 생성 요청이 있었는지 kthread_create_list 연결 리스트를 지속적으로 점검합니다. 만약 kthreadd 프로세스가 요청한 프로세스 생성을 처리한 다음 더는 생성할 프로세스가 없을 때는 어느 코드를 실행할까요?

16 if (list_empty(&kthread_create_list))

17 schedule();

18 __set_current_state(TASK_RUNNING);

위와 같이 17번째 줄 코드를 실행합니다. schedule() 함수를 호출해 스스로 휴면 상태로 진입하는 동작입니다. 즉, 커널 스레드 생성 요청이 없으면 kthread_create_list 연결 리스트가 비게 되어 휴면하는 것입니다.

이후 커널 스레드 생성 요청을 받아 kthreadd 프로세스를 누군가 깨우면 18번째 줄 코드를 실행합니다. 그 이유는 schedule() 함수로 휴면 상태로 진입한 후 다음에 실행되는 코드이기 때문입니다.

kthreadd 프로세스가 깨어나면 실행되는 코드를 알아봤으니 이어서 함수 코드를 분석하겠습니다.

21~32번째 줄 코드를 보기 전에 while 문 조건인 21번째 줄 코드를 봅시다. kthread_create_list라는 연결 리스트가 비어있지 않으면 21~32번째 줄 코드를 실행해서 커널 스레드를 생성합니다.

21 while (!list_empty(&kthread_create_list)) {

22 struct kthread_create_info *create;

23

24 create = list_entry(kthread_create_list.next,

25 struct kthread_create_info, list);

26 list_del_init(&create->list);

27 spin_unlock(&kthread_create_lock);

28

29 create_kthread(create);

30

31 spin_lock(&kthread_create_lock);

32 }

24~25번째 줄 코드를 봅시다. kthread_create_list.next 필드를 통해 kthread_create_info 구조체의 주소를 읽습니다.

연결 리스트 타입인 kthread_create_list 전역변수와 스레드 생성 정보를 나타내는 kthread_create_info 구조체의 관계는 다음과 같습니다.

그림 4.8 kthread_create_list 연결 리스트와 kthread_create_info 구조체의 관계

kthread_create_info 구조체를 보면서 위 그림을 설명하겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/kthread.c

01 struct kthread_create_info

02 {

03 int (*threadfn)(void *data);

04 void *data;

05 int node;

06

07 struct task_struct *result;

08 struct completion *done;

09

10 struct list_head list;

11 };

kthread_create_info 구조체의 마지막 필드는 list이며 struct list_head 타입입니다. 그런데 kthread_create_list 전역변수의 next 필드가 kthread_create_info 구조체의 list 필드 주소를 가리킵니다. 그림 4.8의 맨 왼쪽 부분에 있는 kthread_create_list의 next 전역변수는 화살표로 kthread_create_info list 구조체의 필드를 가리키는 것입니다.

kthread_create_info 구조체에서 list 필드의 오프셋을 계산해 kthread_create_info 구조체의 시작 주소를 알 수 있습니다.

29번째 줄 코드를 봅시다.

29 create_kthread(create);

create_kthread() 함수를 호출해서 커널 스레드를 생성합니다.

create_kthread() 함수 분석

이제 create_kthread() 함수를 봅시다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/kthread.c

1 static void create_kthread(struct kthread_create_info *create)

2 {

3 int pid;

4

5 #ifdef CONFIG_NUMA

6 current->pref_node_fork = create->node;

7 #endif

8 /* We want our own signal handler (we take no signals by default). */

9 pid = kernel_thread(kthread, create, CLONE_FS | CLONE_FILES | SIGCHLD);

9번째 줄과 같이 kernel_thread() 함수를 호출하는데 CLONE_FS, CLONE_FILES, SIGCHLD 매크로를 OR 연산한 결과를 3번째 인자로 설정합니다.

kernel_thread() 함수 분석

이번에는 kernel_thread() 함수를 분석하겠습니다.

https://elixir.bootlin.com/linux/v4.19.30/source/kernel/fork.c

1 pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)

2 {

3 return _do_fork(flags|CLONE_VM|CLONE_UNTRACED, (unsigned long)fn,

4 (unsigned long)arg, NULL, NULL, 0);

5 }

3번째 줄과 같이 _do_fork() 함수를 호출해 프로세스를 생성하는 일을 시작합니다. 코드 분석을 통해 커널 스레드도 프로세스의 한 종류인 것을 알 수 있습니다.

지금까지 커널 스레드를 생성하는 과정을 코드 분석을 통해 알아봤습니다. 배운 내용을 정리해 봅시다.

첫째, 커널 스레드를 생성하려면 어떤 함수를 호출해야 할까?

 kthread_create() 함수를 호출해야 합니다. 함수의 인자로 '스레드 핸들 함수', '매개변수', '커널 스레드 이름'을 지정해야 합니다.

둘째, 커널 스레드를 생성하는 단계는 무엇일까?

 kthreadd 프로세스에게 커널 스레드 생성을 요청한 후 kthreadd 프로세스를 깨웁니다. kthreadd 프로세스는 깨어나 자신에게 커널 스레드 생성 요청이 있었는지 확인한 후 만약 생성 요청이 있다면 커널 스레드를 생성합니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : 리눅스커널, 프로세스, 커널스레드, 스레드

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: 커널 스레드란? 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 09:24
rousalome.egloos.com/10011973
덧글수 : 0

이전 절까지 유저 영역에서 실행한 프로세스가 어떤 과정으로 생성되고 종료되는지 배웠습니다. 이번 절에서는 커널 공간에서만 실행되는 프로세스인 커널 스레드에 대해 소개하고 생성 과정을 살펴보겠습니다.

커널 스레드란?

커널 프로세스는 커널 공간에서만 실행되는 프로세스입니다. 대부분 커널 스레드 형태로 동작합니다. 커널 스레드는 리눅스 시스템 프로그래밍에서 데몬과 비슷한 일을 하는데, 데몬과 커널 스레드는 백그라운드 작업으로 실행되면서 시스템 메모리나 전원을 제어하는 동작을 수행합니다. 그런데 커널 스레드는 유저 영역과 시스템 콜을 받지 않고 동작합니다. 이 점이 데몬과 커널 스레드의 차이점입니다.

커널 스레드는 다음과 같은 세 가지 특징이 있습니다.

 커널 스레드는 커널 공간에서만 실행되며, 유저 공간과 상호작용하지 않습니다.

 커널 스레드는 실행, 휴면 등 모든 동작을 커널에서 직접 제어 관리합니다.

 대부분의 커널 스레드는 시스템이 부팅할 때 생성되고 시스템이 종료할 때까지 백그라운드로 실행됩니다.

커널 스레드를 소개했으니 이번에는 커널 스레드의 종류를 알아봅시다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: ftrace에서 프로세스 확인하기 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 09:00
rousalome.egloos.com/10011972
덧글수 : 0

ftrace를 열어보면 다양한 이벤트 메시지를 볼 수 있습니다. 공통적으로 모든 ftrace 메시지의 맨 왼쪽 부분에서 프로세스 정보를 볼 수 있습니다.

먼저 다음 ftrace 로그를 보면서 프로세스의 정체를 확인해 봅시다.

chromium-browse-1436 [002] d... 9445.131875: sched_switch: prev_comm=chromium-browse prev_pid=1436 prev_prio=120 prev_state=S ==> next_comm=kworker/2:3 next_pid=1454 next_prio=120

위 ftrace는 sched_switch 이벤트의 포맷 로그입니다.

ftrace 메시지에서 맨 왼쪽 부분에 ftrace를 출력하는 프로세스 정보를 볼 수 있습니다. 포맷은 “프로세스이름-[pid]” 형식입니다. 위에서 보이는 ftrace 메시지의 왼쪽 부분 정보는 pid가 1436인 chromium-browse 프로세스가 실행 중이라는 사실을 말해줍니다.

이번 절에서는 리눅스 터미널에서 ps 명령어를 입력해 프로세스가 무엇인지 설명했습니다. 또한 ftrace 메시지로 프로세스 정보를 확인했습니다. 이어지는 절에서는 프로세스를 생성하는 과정을 배워보겠습니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: 스레드란? 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 08:54
rousalome.egloos.com/10011970
덧글수 : 0

스레드(thread)란 무엇일까요? 스레드는 유저 레벨에서 생성된 가벼운 프로세스라 할 수 있습니다. 스레드는 일반 프로세스에 비해 컨텍스트 스위칭을 수행할 때 시간이 적게 걸립니다. 그 이유는 스레드는 자신이 속한 프로세스 내의 다른 스레드와 파일 디스크립터, 파일 및 시그널 정보에 대한 주소 공간을 공유하기 때문입니다. 프로세스가 자신만의 주소 공간을 갖는 것과 달리 스레드는 스레드 그룹 안의 다른 스레드와 주소 공간을 공유합니다.

하지만 커널 입장에서는 스레드를 다른 프로세스와 동등하게 관리합니다. 대신 각 프로세스 식별자인 태스크 디스크립터(task_struct)에서 스레드 그룹 여부를 점검할 뿐입니다.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기

"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

Thanks,

Austin Kim(austindh.kim@gmail.com)

태그 : 리눅스커널, 스레드

트랙백(0)핑백(37)덧글(0)

[리눅스커널] 프로세스: 태스크란 4. 프로세스(Process) 관리

by AustinKim
2020/02/29 08:53
rousalome.egloos.com/10011969
덧글수 : 0

제가 처음 리눅스 커널 코드를 볼 때 가장 궁금했던 점은 “리눅스 커널 함수의 이름에 ‘task’가 왜 보일까?”라는 것이었습니다. 사실 태스크는 리눅스 외의 다른 운영체제에서 예전부터 많이 쓰던 용어입니다. 운영체제 이론을 다루는 책에서는 태스크라는 단어를 많이 볼 수 있습니다.

태스크는 운영체제에서 어떤 의미일까요? 말 그대로 실행(Execution)이라 말할 수 있습니다.

운영체제 책을 보면 첫 장에서 태스크에 대한 설명을 볼 수 있습니다. 예전에는 특정 코드나 프로그램 실행을 일괄 처리했습니다. 이러한 실행 및 작업 단위를 태스크라고 불렀습니다.

임베디드 개발자는 태스크의 개수와 이름을 지정했고 시스템이 구동되는 동안 태스크는 바뀌지 않았습니다. 예를 들면 화면이 없는 간단한 시나리오로 구동하는 임베디드 시스템에서는 태스크 2개가 서로 시그널을 주고받으며 시스템 전체를 제어했습니다.

시간이 흘러 기존 임베디드 개발자들이 리눅스를 사용하는 임베디드 프로젝트로 유입됐습니다. 기존의 태스크라는 용어에 익숙한 임베디드 개발자들이 리눅스에서도 썼던 '태스크'라는 용어를 사용했습니다. '프로그램을 실행하는 단위'라고 생각했던 태스크의 개념은 프로세스와 겹치는 부분이 많기 때문입니다.

---

예전에 쓰던 용어를 현재 소프트웨어에 그대로 쓰는 경우가 많습니다. 이를 레거시(Legacy)라고 표현하는데, 여기에는 과거의 유물이라는 뜻도 있습니다.

---

그래서 예전에 썼던 태스크라는 용어를 리눅스 커널 소스코드에서 그대로 쓰고 있습니다. 대표적인 예로 프로세스 속성을 표시하는 구조체의 이름을 process_struct 대신 task_struct으로 쓰고 있습니다. 이처럼 프로세스마다 속성을 표현하는 task_struct 구조체를 태스크 디스크립터 혹은 프로세스 디스크립터라고도 합니다.

이처럼 리눅스 커널의 함수 이름이나 변수 중에 task란 단어가 보이면 프로세스 관련 코드라 생각해도 좋습니다. 예를 들어, 다음 함수는 모두 프로세스를 관리 및 제어하는 역할을 수행하며, 함수 이름에 보이는 task는 process로 바꿔도 무방합니다.

 dump_task_regs()

 get_task_mm()

 get_task_pid()

 idle_task()

 task_tick_stop()

그러면 이번 절에서 배운 내용을 간단히 정리해 봅시다.

 리눅스 커널에서 태스크는 프로세스와 같은 개념으로 쓰는 용어다.

 소스코드나 프로세스에 대한 설명을 읽을 때 태스크란 단어를 보면 프로세스와 같은 개념으로 이해하자.

#프로세스

프로세스 소개

* 프로세스란?

* 태스크란?

* 스레드란?

프로세스 확인하기

프로세스는 어떻게 생성할까?

유저 레벨 프로세스 실행 실습

커널 스레드

* 커널 스레드란?

커널 내부 프로세스의 생성 과정

* _do_fork() 함수

프로세스의 종료 과정 분석

태스크 디스크립터(task_struct 구조체)

스레드 정보: thread_info 구조체

프로세스의 태스크 디스크립터에 접근하는 매크로 함수

* current 매크로란?

프로세스 디버깅

* glibc의 fork() 함수를 gdb로 디버깅하기