시그널을 받는 쪽에서 보이는 신원을 맞춥니다

이 코드는 어떤 문제를 푸나요?

시그널은 번호 하나만 전달하는 일이 아닙니다. PID·UID를 담은 정보라면 필요할 때 받는 태스크의 namespace에 맞춰 신원을 변환합니다. 이 함수는 시그널 정보를 정리한 뒤 실제 큐 처리 함수로 넘깁니다. 여기서 사용자 핸들러를 바로 호출하는 것은 아닙니다.

읽을 범위: v6.18.37 · kernel/signal.c · send_signal_locked 1183–1217행입니다. 아래에 이 범위의 원문과 각 줄의 설명을 실었습니다. 주제 전체의 흐름과 다른 경로는 기존 분석에서 함께 읽으실 수 있습니다.

먼저 알아둘 개념

namespace

PID와 UID 같은 번호가 어느 범위에서 해석되는지 정합니다.

siginfo

시그널 원인과 발신 정보 등을 담는 기록입니다. 특별한 포인터 값으로 정보의 종류를 나타내기도 합니다.

처음 읽을 때

코드를 읽을 때 SEND_SIG_NOINFO·SEND_SIG_PRIV·PID/UID를 담은 siginfo·그 밖의 정보를 나눕니다. 그다음 어느 상태가 바뀌는지 각 줄에서 확인하세요.

더 깊이 살펴볼 때

이 경로의 호출 문맥, 잠금·인터럽트 상태, 오류 시 남는 자원을 함께 추적해 보세요. 호출된 함수가 수행하는 작업과 현재 함수가 직접 보장하는 범위를 구분하는 것이 중요합니다.

그림으로 보는 변화

GIF 재생1단계 · 멈춰 보기2단계 · 멈춰 보기3단계 · 멈춰 보기

1단계 고정

GIF 원본 열기

1. 발신 정보 판별

정보 없음·커널 요청·PID/UID를 담은 정보·그 밖의 정보를 서로 배타적인 네 경로로 나눕니다.

분기는 정보 형식에 따른 선택입니다.

2. PID·UID 포함 정보만 조건부 변환

PID/UID를 담은 siginfo 경로에서만 user namespace 차이와 발신 PID 가시성에 따라 필드를 바꿉니다.

번호 변환은 대상 task_struct 교체가 아닙니다.

3. pending 처리 함수 호출

모든 경로가 __send_signal_locked()에 합류하지만 무시되거나 이미 pending이면 새 큐 항목은 생기지 않을 수 있습니다.

전달 요청과 실제 핸들러 실행 시점은 다릅니다.

send_signal_locked를 한 줄씩 읽기

줄 번호는 v6.18.37 원문 기준입니다. 주석·빈 줄을 포함한 함수 전체를 먼저 보고, 그 아래에서 각 줄을 설명합니다.

int send_signal_locked(int sig, struct kernel_siginfo *info,
		       struct task_struct *t, enum pid_type type)
{
	/* Should SIGKILL or SIGSTOP be received by a pid namespace init? */
	bool force = false;

	if (info == SEND_SIG_NOINFO) {
		/* Force if sent from an ancestor pid namespace */
		force = !task_pid_nr_ns(current, task_active_pid_ns(t));
	} else if (info == SEND_SIG_PRIV) {
		/* Don't ignore kernel generated signals */
		force = true;
	} else if (has_si_pid_and_uid(info)) {
		/* SIGKILL and SIGSTOP is special or has ids */
		struct user_namespace *t_user_ns;

		rcu_read_lock();
		t_user_ns = task_cred_xxx(t, user_ns);
		if (current_user_ns() != t_user_ns) {
			kuid_t uid = make_kuid(current_user_ns(), info->si_uid);
			info->si_uid = from_kuid_munged(t_user_ns, uid);
		}
		rcu_read_unlock();

		/* A kernel generated signal? */
		force = (info->si_code == SI_KERNEL);

		/* From an ancestor pid namespace? */
		if (!task_pid_nr_ns(current, task_active_pid_ns(t))) {
			info->si_pid = 0;
			force = true;
		}
	}
	return __send_signal_locked(sig, info, t, type, force);
}

int send_signal_locked(int sig, struct kernel_siginfo *info,

		       struct task_struct *t, enum pid_type type)

	bool force = false;

	if (info == SEND_SIG_NOINFO) {

		force = !task_pid_nr_ns(current, task_active_pid_ns(t));

	} else if (info == SEND_SIG_PRIV) {

		force = true;

	} else if (has_si_pid_and_uid(info)) {

		struct user_namespace *t_user_ns;

		rcu_read_lock();

		t_user_ns = task_cred_xxx(t, user_ns);

		if (current_user_ns() != t_user_ns) {

			kuid_t uid = make_kuid(current_user_ns(), info->si_uid);

			info->si_uid = from_kuid_munged(t_user_ns, uid);

		rcu_read_unlock();

		force = (info->si_code == SI_KERNEL);

		if (!task_pid_nr_ns(current, task_active_pid_ns(t))) {

			info->si_pid = 0;

			force = true;

	return __send_signal_locked(sig, info, t, type, force);

함께 생각해 볼 질문

출처와 읽은 범위

Linux stable v6.18.37 · kernel/signal.c

해당 버전 원본 파일 · 기존 코드 분석 · 설명 원고