start_kernel(): Linux가 운영체제가 되는 순서

핵심 질문

부팅 초기에 함수 호출 순서가 왜 그렇게 엄격할까요? 정답은 아직 사용할 수 없는 기능을 먼저 쓰지 않기 위해서입니다. allocator가 없을 때 동적 메모리를 요구하면 안 되고, scheduler가 준비되기 전에 timer interrupt가 task 전환을 요구해도 안 되며, kthreadd가 생기기 전에 PID 1이 kernel thread를 만들게 해서도 안 됩니다.

먼저 그림과 줄별 설명으로 읽기

1. 쉬운 모델: 공사 중인 도시의 개통 순서

도로가 없는데 버스를 운행할 수 없고, 신호등 제어실이 없는데 교차로 전원을 켤 수 없습니다. 부팅도 같습니다. start_kernel()의 호출 순서는 subsystem 이름의 나열이 아니라 의존성 그래프를 일렬로 편 결과입니다.

2. 실제 초기화 순서와 각 단계의 산출물

초기화 함수가 끝났다는 말의 정확한 범위

mm_core_init()으로 메모리 관리의 핵심이 준비되어도 곧바로 모든 blocking allocation이 안전한 것은 아닙니다. 함수가 존재하는 것, 내부 자료구조가 준비된 것, 잠들었다 깨어날 실행 문맥이 있는 것은 다른 조건입니다. kernel_init_freeable()은 scheduler 준비 이후에야 gfp_allowed_mask = __GFP_BITS_MASK로 허용 범위를 넓힙니다.

workqueue의 두 단계가 좋은 예입니다. 앞 단계는 다른 subsystem이 work를 등록할 수 있도록 장부를 만듭니다. 실제로 그것을 처리할 kthread를 만들고 실행시키는 것은 뒤 단계입니다. 초기화 함수에서 “등록했으니 완료될 때까지 기다리자”라고 생각하면 아직 생기지 않은 worker를 기다리는 의존성 순환을 만들 수 있습니다. CPU 하나로 실행 중이라도 이런 대기 관계는 생깁니다.

3. 원문에서 순서를 확인한다

architecture와 security의 실제 순서 · init/main.c 908–941

asmlinkage __visible __init __no_sanitize_address __noreturn __no_stack_protector
void start_kernel(void)
{
	char *command_line;
	char *after_dashes;

	set_task_stack_end_magic(&init_task);
	smp_setup_processor_id();
	debug_objects_early_init();
	init_vmlinux_build_id();

	cgroup_init_early();

	local_irq_disable();
	early_boot_irqs_disabled = true;
	...
	boot_cpu_init();
	page_address_init();
	pr_notice("%s", linux_banner);
	setup_arch(&command_line);
	jump_label_init();
	static_call_init();
	early_security_init();
	setup_boot_config();
	setup_command_line(command_line);
	setup_nr_cpu_ids();
	setup_per_cpu_areas();
	smp_prepare_boot_cpu();
	early_numa_node_init();

v6.18.37에서 setup_arch()가 early_security_init()보다 먼저입니다. LSM의 early hook이 static key와 static call을 사용하므로 그 둘도 security 초기화보다 먼저 준비합니다. 이 순서는 과거 글의 코드 조각을 기억으로 옮기지 말고 해당 tag에서 확인해야 합니다.

scheduler가 interrupt보다 먼저인 이유 · init/main.c 978–1038

/* Set up the scheduler prior starting any interrupts ... */
sched_init();
...
workqueue_init_early();
rcu_init();
kvfree_rcu_init();
trace_init();
...
early_irq_init();
init_IRQ();
tick_init();
rcu_init_nohz();
timers_init();
srcu_init();
hrtimers_init();
softirq_init();
timekeeping_init();
time_init();
...
early_boot_irqs_disabled = false;
local_irq_enable();

이름이 비슷해도 이 버전의 함수는 init_timers()가 아니라 timers_init()입니다. timer interrupt가 시작되면 wakeup과 softirq, scheduler 상태를 건드릴 수 있으므로 sched_init()가 먼저 와야 합니다. workqueue_init_early()는 생성과 queueing을 허용할 뿐, worker 실행은 나중의 workqueue_init()과 kthread 준비까지 기다립니다.

generic core 초기화의 끝 · init/main.c 1080–1110

pid_idr_init();
anon_vma_init();
thread_stack_cache_init();
cred_init();
fork_init();
proc_caches_init();
uts_ns_init();
time_ns_init();
key_init();
security_init();
dbg_late_init();
net_ns_init();
vfs_caches_init();
pagecache_init();
signals_init();
seq_file_init();
proc_root_init();
nsfs_init();
pidfs_init();
cpuset_init();
mem_cgroup_init();
cgroup_init();
...
/* Do the rest non-__init'ed, we're now alive */
rest_init();

rest_init() 앞까지가 kernel이 task를 만들고 schedule할 수 있는 core state를 구축하는 구간입니다. device driver의 다수는 아직 올라오지 않았고, root filesystem도 아직 mount되지 않았습니다.

4. rest_init(): PID 1과 PID 2, 그리고 idle

세 실행 흐름을 만드는 곳 · init/main.c 711–758

static noinline void __ref __noreturn rest_init(void)
{
	struct task_struct *tsk;
	int pid;

	rcu_scheduler_starting();
	pid = user_mode_thread(kernel_init, NULL, CLONE_FS);
	...
	set_cpus_allowed_ptr(tsk, cpumask_of(smp_processor_id()));
	...
	pid = kernel_thread(kthreadd, NULL, NULL, CLONE_FS | CLONE_FILES);
	...
	kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
	...
	system_state = SYSTEM_SCHEDULING;
	complete(&kthreadd_done);

	schedule_preempt_disabled();
	cpu_startup_entry(CPUHP_ONLINE);
}

1. PID 1을 먼저 예약user_mode_thread(kernel_init, ...)를 먼저 호출해 init task가 PID 1을 얻습니다.
2. 임시 CPU 고정sched_init_smp() 전에는 migration이 완전히 준비되지 않아 init task를 boot CPU에 고정합니다.
3. PID 2 생성kernel_thread(kthreadd, ...)가 이후 kernel thread 생성 요청을 담당할 task를 만듭니다.
4. 동시성 문 열기complete(&kthreadd_done) 뒤에야 PID 1이 기다림을 끝내고 후속 초기화를 진행할 수 있습니다.
5. boot task의 최종 역할원래 실행 흐름은 한 번 schedule한 뒤 cpu_startup_entry()에서 idle thread가 됩니다.

kernel_init()은 먼저 wait_for_completion(&kthreadd_done)에서 기다립니다. 그 뒤 kernel_init_freeable()로 initcall을 실행하고, asynchronous init 작업이 끝난 후 free_initmem()으로 __init 메모리를 반환합니다. rest_init()이 __init가 아닌 __ref 함수인 이유도 init thread와 root thread 사이의 free-initmem race를 피하기 위해서라고 원문 주석에 명시돼 있습니다.

먼저 생성하되 먼저 진행시키지는 않는다

PID 할당 순서와 실행 순서는 다릅니다. init을 먼저 생성해야 PID 1이 됩니다. 하지만 init이 kthread 생성을 요청할 때에는 요청을 처리하는 kthreadd_task가 이미 게시되어 있어야 합니다. 그래서 rest_init()은 PID 1의 생성과 후속 실행 사이에 completion을 둡니다.

completion은 순간적인 신호만 보내고 사라지는 장치가 아닙니다. PID 0이 먼저 complete()하고 나중에 PID 1이 wait하더라도 완료 상태를 소비하고 진행합니다. 반대로 PID 1이 먼저 기다리면 완료 시 깨웁니다. 그래서 이 코드는 “PID 1이 이미 wait 중이어야 한다”는 타이밍 가정이 필요 없습니다. 단, 이 completion은 모든 driver 초기화가 끝났다는 신호가 아니라 kthreadd 준비라는 특정 조건을 게시합니다.

system_state = SYSTEM_SCHEDULING도 같은 문맥에서 읽어야 합니다. 이 전역 상태를 바꾸는 대입문 자체가 scheduler를 구현하거나 CPU를 시작시키는 것은 아닙니다. 이미 준비한 조건을 다른 경로와 진단 코드에 알리는 단계입니다. 부팅이 끝났다는 SYSTEM_RUNNING 전환은 훨씬 뒤의 PID 1 경로에 있습니다.

4.1 PID 1이 initcall을 실행할 수 있는 이유

kernel_init_freeable()은 memory allocation 범위를 열고 smp_prepare_cpus(), workqueue_init(), early initcall을 거친 뒤 smp_init()과 sched_init_smp()를 호출합니다. 이후 do_basic_setup()에서 driver model을 준비하고 일반 initcall을 실행합니다. 따라서 early initcall과 level 0 이후의 initcall은 실행 전제부터 다릅니다.

한 initcall의 실행 경계 · init/main.c:1274–1295 중 핵심 발췌

int count = preempt_count();
...
do_trace_initcall_start(fn);
ret = fn();
do_trace_initcall_finish(fn, ret);
...
if (preempt_count() != count) {
    sprintf(msgbuf, "preemption imbalance ");
    preempt_count_set(count);
}
if (irqs_disabled()) {
    strlcat(msgbuf, "disabled interrupts ", sizeof(msgbuf));
    local_irq_enable();
}

4.2 __init 메모리를 돌려주기 전 지켜야 할 것

부팅 전용 함수는 영구적으로 RAM을 차지할 필요가 없습니다. __init과 __initdata로 분리한 구간을 부팅 뒤 회수하면 다른 용도로 재사용할 수 있습니다. 문제는 코드를 가리키는 주소가 여전히 남아 있거나 다른 CPU가 그 코드를 실행 중인 경우입니다. allocator는 그것이 예전 함수 주소였다는 사실을 기억해 보호해 주지 않습니다.

rest_init()이 __ref인 이유는 root thread가 아직 그 함수를 빠져나오지 못했는데 init thread가 init 영역을 회수하는 경우를 피하기 위해서입니다. __ref는 일반적인 use-after-free 해결책이 아닙니다. 장기 사용 callback을 무심코 __init 함수로 등록했다면 callback의 수명을 바꾸거나 함수 배치를 수정해야 합니다. build의 section mismatch 경고를 숨기는 것만으로는 문제가 해결되지 않습니다.

4.3 PID 1이 어떤 프로그램으로 바뀌는가

PID 1은 처음에는 커널의 kernel_init()을 실행합니다. 이후 run_init_process()가 kernel_execve()를 호출하여 그 task의 프로그램을 userspace init으로 바꿉니다. 성공할 때마다 새 PID 1을 만드는 것이 아닙니다. 파일이 존재해도 CPU architecture, ELF interpreter, 실행 권한 등의 이유로 exec에 실패할 수 있습니다.

Failed to execute /init가 나왔다면 커널 entry보다 initramfs 안의 실행 파일과 interpreter를 먼저 봅니다. 동적 ELF에 지정된 loader가 없으면 실행 파일이 존재해도 실패합니다. root filesystem 자체를 준비하지 못한 경우와 이미 rootfs가 있는데 init 실행이 실패한 경우는 조사 순서가 다릅니다. 소스의 분기를 부팅 로그와 연결해야 불필요한 MMU 디버깅으로 되돌아가지 않습니다.

5. 순서를 바꾸면 깨지는 불변 조건

• interrupt gate: local_irq_enable() 전에는 IRQ, tick, timer, softirq, timekeeping의 최소 경로가 모두 초기화되어야 합니다.
• allocator boundary: mm_core_init() 전후로 사용할 수 있는 allocator가 다릅니다. early code가 일반 blocking allocation을 요구하면 안 됩니다.
• console은 부분 준비: console_init() 시점에는 PCI 등 모든 bus가 준비된 것이 아닙니다. console driver는 early 조건을 감당해야 합니다.
• PID 1 before kthreadd: init을 먼저 생성해 PID 1을 보장하지만, 실행은 completion으로 막아 kthreadd보다 앞서 kernel thread를 만들지 못하게 합니다.
• init memory lifetime: async init 작업과 참조가 끝나기 전에 free_initmem()을 호출하면 이미 반환된 코드로 실행할 수 있습니다.
• configuration changes the path: ACPI, initrd, lockdep, tracing, security, cgroup 설정에 따라 호출의 효과와 비용이 달라집니다.

6. 마지막 로그로 멈춘 위치를 좁히기

7. 재현 가능한 관찰 방법

• 초기 출력: 보드에 맞는 earlycon과 ignore_loglevel, 충분한 log_buf_len=을 사용합니다. 주소와 clock 설정이 틀리면 earlycon 자체가 침묵합니다.
• initcall 시간: kernel command line에 initcall_debug를 넣고 함수별 시작·종료와 반환값을 수집합니다. 이것은 start_kernel()의 모든 core 호출을 자동 계측하는 옵션은 아닙니다.
• boot graph: timestamp가 포함된 dmesg를 scripts/bootgraph.pl로 분석해 initcall 구간을 시각화합니다.
• 함수 graph: 동일 baseline의 debug kernel에서 function graph tracer를 제한적으로 사용합니다. 초기 ftrace 준비 전 구간은 보이지 않을 수 있습니다.
• QEMU/GDB: start_kernel, sched_init, rest_init와 IRQ enable 직전 소스 행에 breakpoint를 두고 CPU, SP, interrupt mask를 함께 기록합니다. local_irq_enable은 macro/inline이므로 독립 함수 symbol이 없을 수 있습니다.
• 비교 실험: config, compiler, command line, DTB/ACPI table hash를 보존해야 두 boot log의 시간 차이를 의미 있게 비교할 수 있습니다.

관측 도구가 볼 수 있는 구간을 먼저 고른다

symbol이 있는 debug vmlinux와 일치하는 QEMU image를 사용한 GDB 절차

file vmlinux
target remote :1234
break start_kernel
break rest_init
break kernel_init
break kernel_init_freeable
continue
info threads
info registers
bt

QEMU는 선택한 architecture·machine에 맞게 시작하고, GDB 연결 포트와 멈춤 옵션을 설정해야 합니다. 위 절차는 이미 그 환경을 준비했다는 전제입니다. KASLR을 사용하는 image는 런타임 주소에 맞춘 symbol 처리가 필요하므로 통제된 부팅 실험에서는 nokaslr 여부도 기록합니다. 이 글에는 실제 보드/QEMU 실행 로그를 첨부하지 않았습니다. 소스 순서 검증과 실행 측정을 구분합니다.

결과 기록에는 최소한 kernel tag, .config, compiler, command line, firmware/DTB, 마지막 진입 함수와 복귀 여부를 포함합니다. 예를 들어 initcall 시작은 있지만 종료가 없다면 breakpoint로 대기 중 stack을 확인하고, 종료와 음수 ret이 있다면 해당 초기화의 오류 경로를 봅니다. console 출력 지연 때문에 마지막 로그만으로 PC를 추정하지 않습니다.

8. 이 글의 범위 밖

특히 line number는 v6.18.37에만 고정됩니다. 다른 stable release에서 함수 이름이 같더라도 ordering과 config guard를 다시 확인해야 합니다.

원문과 검증 범위

• 사이트에 보존한 Linux v6.18.37 init/main.c 원문
• 줄 번호가 붙은 원문: start_kernel()
• Linux stable v6.18.37 start_kernel()
• Linux stable v6.18.37 rest_init()
• Linux v6.6 비교 설명