Art of Pr0gr4m

블로킹, 논블로킹, 동기, 비동기 비교

pr0gr4m — Sun, 28 Jul 2024 08:19:19 +0900

결론부터 이야기하면 동기 IO와 비동기 IO는 'IO 시작 후 완료 전에 다른 작업을 수행할 수 있는지'와 '요청과 완료 순서의 보장'으로 구분할 수 있다. 블로킹 IO와 논블로킹 IO는 레이어(커널, 시스템콜, 특정 언어 및 라이브러리)마다 의미가 조금씩 달라지는데, 시스템 콜에서는 동기 IO 내에 블로킹 모드와 논블로킹 모드가 존재한다. 우선 시스템콜 레이어를 기준으로 해당 내용에 대해 알아보자.

블로킹 시스템콜 IO는 호출 시 해당 작업을 수행할 수 있을 때까지 반환하지 않고 대기한다.

논블로킹 시스템콜 IO는 호출 시 해당 작업을 수행할 수 없다면 바로 반환한다. (혹은 일부 가능 시 일부만 수행하고 반환한다.)

예를 들어서 디스크에 write(disk_fd, "0123456789", 10); 함수를 호출할 때,

디스크 버퍼가 10byte 이상 남은 상황, 3byte 남은 상황, 0byte 남은 (고갈된) 상황을 각각 고려해보자.

(아래 상황은 이해를 위한 단순 예시로, 실제 동작 방식은 조금 다르다는걸 염두하자.)

블로킹모드(default)

- 버퍼 10b 남음 : 바로 "0123456789"을 모두 쓰기 시작한다. 버퍼에 쓰기가 완료될 때까지 대기했다가 반환한다. (대기 시간 : 10b 쓰는 시간)

- 버퍼 3b 남음 : 우선 "012"를 쓴다. 그리고 버퍼가 비워질 때까지 기다린다. 버퍼가 비워지면 "3456789"를 마저 쓴다. 쓰기가 완료될 때까지 대기했다가 반환한다. (대기 시간 : 버퍼 7b 비워지는 시간 + 10b 쓰는 시간)

- 버퍼 0b 남음 : 버퍼가 비워질 때까지 기다린다. 버퍼가 비워지면 쓰기 시작하고, 쓰기가 완료될 때까지 대기했다가 반환한다. (대기 시간 : 버퍼 10b 비워지는 시간 + 10b 쓰는 시간)

(위 설명은 이해를 위한 예시이며, 실제로는 효율을 위해 한번에 대기했다가 한번에 쓰는 등 구현에 따라 다름)

논블로킹모드(O_NONBLOCK)

- 버퍼 10b 남음 : 바로 "0123456789"을 모두 쓰기 시작한다. 버퍼에 쓰기가 완료될 때까지 대기했다가 반환한다. (대기 시간 : 10b 쓰는 시간)

- 버퍼 3b 남음 : "012"를 쓴다. 3byte 쓰기가 완료될 때까지 대기했다가 3을 반환한다. 일부 성공. (대기 시간 : 3b 쓰는 시간)

- 버퍼 0b 남음 : 바로 0을 반환한다. (대기 시간 : 없음)

주의할 점은 논블로킹이라고 해서 아예 대기가 없는 것은 아니다. 쓰기 작업이 수행되는 동안에는 블로킹된다.

단지, 블로킹모드는 요청한 작업을 수행할 수 있을 때까지 무한정 대기하는데 논블로킹 모드는 요청한 작업을 수행할 수 없다면 반환하게 된다.

물론, 디스크 자체에 문제가 생겨서 IO가 아예 불가능한 상황이 된다면 블로킹 모드나 논블로킹 모드나 바로 에러로 반환한다. (이 때는 0을 반환하는 것이 아니라 -1을 반환함)

아무튼 블로킹 모드나 논블로킹 모드나 IO 요청 후 실제 수행하는 동안은 IO 대기 상태가 되고, IO가 완료되면 반환하는 것은 동일하다.

이러한 성격 때문에 여러 개의 IO 요청이 있을 때, 요청과 완료의 순서가 뒤바뀔 일이 없다.

즉,

write(disk_fd, "01234", 5);

write(disk_fd, "56789", 5);

를 나눠서 순서대로 호출했을 때, 절대 "56789" 쓰기가 "01234"보다 먼저 완료될 일이 없다.

이는 블로킹 모드나 논블로킹나 마찬가지다.

요청으로부터 완료되는 순서가 보장되어 있다. 다시 말해, 요청부터 완료까지의 동작들이 한 묶음으로 동기화 되어 있기 때문에 이를 동기(synchronous) IO라고 한다.

(물론, 동일한 쓰레드 내에서의 이야기다. 서로 다른 쓰레드에서 write를 호출했다면 보장되지 않는다.)

동기 IO에서는 함수 호출이 곧 요청이고, 해당 함수의 반환이 곧 완료다.

하나의 함수가 요청과 완료 통지 기능을 전부 갖추고 있다.

비동기(asynchronous) IO는 동기 IO와 다르게 일반적으로 요청과 완료가 분리된다.

비동기 IO는 IO 요청 후 작업이 완료될 때까지 대기하지 않고 바로 반환한다.

해당 작업을 수행할 수 있든 없든 상관 없이 단순 요청만 하고 반환한다. 그리고 별도의 완료 통지 메커니즘을 갖는다.

예를 들어서 디스크에 비동기 쓰기 aio_write(disk_fd, "0123456789", 10); 함수를 호출한다고 가정하자. (실제 aio_write 함수는 struct aiocb를 인자로 받아야 하지만 이해를 위해 간략화한다.)

디스크 버퍼가 얼마나 남아있는지 상관 없다. 그냥 디스크에 이거 써줘 를 요청하고, 바로 반환한다.

이후에 별도의 함수들(aio_error, aio_return)을 통해서 작업이 진행중인지, 완료되었는지, 실패했는지, 최종적인 결과가 어떻게 되었는지 등을 알 수 있다. 원한다면 작업이 완료되었을 때 비동기적으로 완료 통지(signal이나 callback)를 받을 수도 있다.

이처럼 비동기 IO는 요청과 실제 동작 및 완료가 분리되어있기 때문에, 요청 후 완료 전까지 다른 작업들을 수행할 수 있다.

동기 IO에서는 블로킹/논블로킹 상관 없이 IO 요청 후 실제 작업이 완료되기 전까지는 다른 작업을 수행할 수 없었다. 즉, IO 요청부터 완료될 때까지는 해당 IO를 요청한 쓰레드가 CPU 연산을 사용할 수 없었다.

반면 비동기 IO는 요청 후 IO와 관련 없는 CPU 연산을 얼마든지 수행할 수 있다. 실제 작업은 백그라운드에서 커널과 디바이스가 열심히 처리해준다.

이러한 비동기 IO의 동작 방식 때문에 여러 개의 IO 요청이 있을 때, 요청과 완료의 순서가 동일하도록 보장되지 않는다.

aio_write(disk_fd, "01234", 5); // 실제 인자는 aiocb 객체를 넘겨야 함

aio_write(disk_fd, "56789", 5);

를 나눠서 호출했다면 "56789" 쓰기가 "01234"보다 먼저 완료될 수 있다.

어차피 커널은 먼저 요청한걸 먼저 처리하는 것이 아니라, 여러 요청들을 모아서 효율적으로 동작할 수 있도록 알아서 잘 처리한다. 커널에 "01234" 쓰기 요청과 "56789" 쓰기 요청이 (거의) 동시에 들어왔을 때 "56789" 를 먼저 쓰는 것이 효율적이라고 판단되면 그렇게 작업을 진행한다.

앗, 그렇다면 디스크에 "0123456789"가 써지는 것을 원했는데 "5678901234"가 써질 수 있다는 것일까?

당연히 이런 문제가 발생할 수 있기 때문에 애초에 비동기 IO는 보통 어디에 작성할지 오프셋을 지정하도록 되어있다.

이처럼 비동기 IO는 요청부터 완료까지의 동작들이 한 묶음으로 동기화되지 않는다.

결국 동기 IO와 비동기 IO의 가장 큰 차이는 'IO 수행 시작 이 후 완료되기 전까지 다른 작업을 할 수 있는지 여부' 와 '요청과 완료 순서가 동일한가' 이다.

'동기는 블로킹이고, 비동기는 논블로킹이다' 는 시스템 콜 레벨에서 아예 틀린 문장임을 알 수 있다.

시스템 콜에서는 블로킹 IO나 논블로킹 IO나 모두 동기 IO이고, 비동기 IO는 이와 아예 별도의 방식이라고 할 수 있다.

시스템콜 함수에 대응한다면 read/write 함수는 동기 IO, aio_read/aio_write 함수는 비동기 IO 로 분류한다. 그리고 동기 IO인 read/write 함수는 O_NONBLOCK 세팅 여부에 따라 블로킹과 논블로킹으로 분류한다.

하지만 시스템 콜이 아닌 특정언어/라이브러리/프레임워크 레벨에서는 블로킹/논블로킹 IO를 자체적으로 정의하기도 한다. 비동기 IO는 대부분의 분야 및 레벨에서 동일한 개념으로 이야기하지만, 유독 블로킹/논블로킹은 의미가 달라지기도 한다.

예를 들어 블로킹 IO를 'IO 요청에 의해서 쓰레드의 블로킹이 조금이라도 발생하는 IO' 라는 의미로 사용하고, 논블로킹 IO를 'IO 요청에 의해서 쓰레드의 블로킹이 아예 발생하지 않는 IO'라는 의미로 사용하기도 한다. 이 경우엔 보통 구조적으로 블로킹 IO가 동기 IO가 되고, 논블로킹 IO가 비동기 IO가 될 것이다. (이 개념을 시스템콜에 적용한다면 read/write 함수는 논블로킹 모드여도 쓰레드 블로킹이 발생하기 때문에 블로킹 IO가 된다.)

또 간혹 블로킹 IO는 '함수 호출 이 후 실제 IO 작업이 시작할 때까지 블로킹될 수 있는 IO' 라는 의미로 사용하고, 논블로킹 IO를 '함수 호출 이 후 실제 IO 작업이 시작할 때까지 블로킹되지 않는 IO' 라는 의미로 사용하기도 한다.

이 경우엔 동기 & 블로킹, 동기 & 논블로킹, 비동기 & 논블로킹 로 구분이 가능하며, 비동기 & 블로킹은 구조적으로 불가능하다. (굳이 그러한 라이브러리를 만들 수는 있으나 구조적으로 잘못된 설계다.)

결국 어느 레벨에서 이야기하는지에 따라 용어의 개념은 달라진다. 혼동을 피하기 위하여 언급을 피했지만, 커널 레벨에서는 결국 대부분의 IO가 비동기로 동작한다. 따라서 쓰레드 A와 쓰레드 B가 둘 다 write를 호출했을 때, 쓰레드 A가 먼저 호출했더라도 쓰레드 B의 write가 먼저 완료될 수도 있다.

아무튼 특정 언어나 라이브러리에서 용어를 따로 정의할 수는 있지만, 유저 어플리케이션이 IO 작업을 요청하기 위한 근간은 결국 시스템 콜이다. 시스템 콜 레벨에서는 언급한 바와 같이 블로킹/논블로킹은 동기 IO 내에서 구분하는 방식이고, 비동기 IO는 동기 IO와 아예 별도의 방식이다.

---

Reference

fcntl(2) (freebsd.org)

fcntl(2)

FreeBSD Manual Pages FCNTL(2) System Calls Manual FCNTL(2) NAME fcntl -- file control LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include int fcntl(int fd, int cmd, ...); DESCRIPTION The fcntl() system call provides for control over descriptors. The a

man.freebsd.org

Non-blocking  I/O;	if  no	data is	available to a read(2)
		    system call, or if a write(2) operation would  block,  the
		    read or write call returns -1 with the error EAGAIN.

aio(4) (freebsd.org)

aio(4)

FreeBSD Manual Pages AIO(4) Kernel Interfaces Manual AIO(4) NAME aio -- asynchronous I/O DESCRIPTION The aio facility provides system calls for asynchronous I/O. Asynchro- nous I/O operations are not completed synchronously by the calling thread. Instead,

man.freebsd.org

The aio facility	provides system	calls for asynchronous I/O.  Asynchro-
       nous  I/O  operations  are  not	completed synchronously	by the calling
       thread.	Instead, the calling thread invokes one	system call to request
       an asynchronous I/O operation.  The status of a	completed  request  is
       retrieved later via a separate system call.

Asynchronous I/O - Wikipedia

From Wikipedia, the free encyclopedia Form of input/output processing In computer science, asynchronous I/O (also non-sequential I/O) is a form of input/output processing that permits other processing to continue before the I/O operation has finished. A na

en.wikipedia.org

Forms of I/O and examples of POSIX functions:

	Blocking	Non-Blocking	Asynchronous
API	write, read	write, read + poll / select	aio_write, aio_read

병렬성(Parallelism)과 동시성(Concurrency)

pr0gr4m — Sun, 21 Jul 2024 16:21:25 +0900

concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the outcome. This allows for parallel execution of the concurrent units, which can significantly improve overall speed of the execution in multi-processor and multi-core systems. In more technical terms, concurrency refers to the decomposability of a program, algorithm, or problem into order-independent or partially-ordered components or units of computation.

Parallel computing is a type of computation in which many calculations or processes are carried out simultaneously.

parallelism and concurrency are two different things: a parallel program uses multiple CPU cores, each core performing a task independently. On the other hand, concurrency enables a program to deal with multiple tasks even on a single CPU core; the core switches between tasks (i.e. threads) without necessarily completing each one. A program can have both, neither or a combination of parallelism and concurrency characteristics.

Note that in computer science, parallelism and concurrency are two different things: a parallel program uses multiple CPU cores, each core performing a task independently. On the other hand, concurrency enables a program to deal with multiple tasks even on a single CPU core; the core switches between tasks (i.e. threads) without necessarily completing each one. A program can have both, neither of or a combination of parallelism and concurrency characteristics.

Concurrenty is a property of the program and parallel execution is a property of the machine.

Concurrency는 프로그램의 성질이고 parallel execution은 기계의 성질이다.

동일한 포인터 역참조 시 값이 다른 케이스

pr0gr4m — Fri, 6 Oct 2023 19:24:15 +0900

다음 코드의 결과를 예상해보자.

    int x = 1, y = 2;    // clang을 사용한다면 x와 y 선언 순서 변경
    int *px = &x + 1;
    int *py = &y;
    if (!memcmp(px, py, sizeof(*px))) {    // px와 py는 같은 주소를 참조함
        *px = 3;
        printf("x : %d, y : %d, *px : %d, *py : %d\n", x, y, *px, *py);
    }

오브젝트 x와 y가 메모리상에 연속되어있는 시스템에서는 당연히 다음과 같은 결과를 보일 것이다.

#1
x : 1, y : 3, *px : 3, *py : 3

하지만 이는 Undefined Behavior 코드로, 다음과 같은 결과를 만들어낼 수 있다.

#2
x : 1, y : 2, *px : 3, *py : 2

어째서 이런 결과가 가능할까?

표준 본문에서 역참조 연산에 대한 UB 언급은 다음과 같다 : If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
배열의 원소는 항상 연속적인 것이 보장된다. 따라서 int arr[2] = { 0, 1 }; 와 같은 코드가 있을 때 &arr[0] + 1 == &arr[1] 이 '보장' 된다.
int x = 1, y = 2; 라는 코드는 메모리 상에서 통상적으로 &x + 1 == &y 의 레이아웃을 가지게 된다. 하지만 언어 차원에서 이를 '보장'하지 않는다. 예를 들어, x는 스택 메모리에 y는 레지스터에 할당된 경우를 생각해보자.
해당 내용에 의해 컴파일러는 px가 참조하는 대상이 y라는 것을 '보장'할 필요가 없어진다. 따라서, 컴파일러는 px == &y 라는 가정하에 생기는 최적화 방어를 할 필요가 없어진다.
결국 현재 위 코드에서 포인터 px가 특정한 오브젝트를 참조하고 있다는 보장이 없기에, 역참조한 값을 lvalue로 사용했을 때 발생하는 side effect를 항상 발생할 필요가 없어진다.
따라서 if (!memcmp(px, py, sizeof(*px))) 에서 볼 수 있듯이, 두 포인터는 동일한 곳을 참조하는 포인터이지만, py는 y 오브젝트를 참조하고 있음이 보장되며, px는 y 오브젝트를 참조하고 있음이 보장되지 않는다.
그러므로 *px = 3; 이라는 코드는 실제로 px를 역참조하여 3을 대입하는 side effect를 발생시키지 않고, 상수 전파로 최적화가 가능해진다.
printf("x : %d, y : %d, *px : %d, *py : %d\n", x, y, *px, *py); 코드에서 *px 는 상수 전파로 인해 3을 바로 사용할 수 있게 된다.

위와 같은 흐름으로 동일한 주소를 참조하고 있는 포인터가 역참조 시 서로 다른 값이 나오게 된다.
실제로 위 코드를 gcc나 clang 컴파일러를 이용해서 -O0 으로 최적화 없이 컴파일하면 1번과 같은 결과가 나오지만, -O2 으로 최적화하면 2번과 같은 결과가 나오게 된다. (clang을 사용하는 경우 int y = 2, x = 1;와 같이 선언해야 한다.)

결론적으로 past to end of object 포인터가 또 다른 object를 참조한다고 보장되지 않는 경우 invalid 포인터로 취급하여 UB 동작을 발생시킨다. (past to end of object 참조는 UB가 아니지만, 해당 참조 포인터를 역참조하면 UB이다.)

그리고 이는 패딩 등의 이유로 구조체 내의 멤버 또한 마찬가지다.

struct T {
    int x, y;
};

struct T t;
// &t.x + 1이 t.y를 참조한다고 보장하지 않음

따라서, 제너럴한 자료 구조의 구현 시 past to end of object 포인터를 사용할때 유의가 필요하다.
(제너럴한 자료 구조는 https://pr0gr4m.tistory.com/entry/Linux-Kernel-5-Linked-List 참고)

Linux Kernel Network Commit #3

pr0gr4m — Wed, 25 Aug 2021 15:23:49 +0900

Netdev 트리의 net-next 브랜치 커밋

[v3,net-next] net: bridge: change return type of br_handle_ingress_vlan_tunnel - Patchwork (kernel.org)

[v3,net-next] net: bridge: change return type of br_handle_ingress_vlan_tunnel - Patchwork

patchwork.kernel.org

두 번째 커밋과 비슷하게, 현재 br_handle_ingress_vlan_tunnel() 함수는 모든 종료 경로에서 return 0;으로 끝난다.

처음에는 pair 함수 br_handle_egress_vlan_tunnel() 함수에서는 skb_vlan_pop()을 호출해서 해당 반환 값을 반환하는데,

ingress 함수에서는 skb_vlan_push() 함수를 호출하지 않고 __vlan_hwaccel_put_tag() 함수만 호출하고 return 0;으로 종료하는게 이상해 보였다.

따라서, __vlan_hwaccel_put_tag() 호출 대신 skb_vlan_push() 함수를 호출해서 반환값을 반환하도록 하는 패치를 보냈다.

이에 대해 메인테이너분이 다음과 같이 답을 주셨다.

This changes behaviour though, I don't like changing code just for the sake of it.

Perhaps the author had a reason to use hwaccel_put_tag instead.

Before we would just put hwaccel tag, now if there already is hwaccel tag we'll push it inside the skb and then push the new tag in hwaccel.

In fact I think you can even trigger the warning inside skb_vlan_push, so

대충 hwaccel tag 넣기 전에 이미 hwaccel tag가 있다면 skb에 해당 tag를 push하고, hwaccel에 새 tag를 push한다는 내용인데.. 여기서는 skb_vlan_push() 함수가 아니라 hwaccel put tag를 쓰는게 맞다는 이야기같다.

따라서 해당 패치는 포기하고, 대신 현재 함수가 항상 return 0;로 끝나므로 이 부분 cleanup을 수행하겠다고 메일 드렸더니 이 부분에 대해서는 긍정적으로 반응해주셨다.

그렇게 br_handle_ingress_vlan_tunnel() 함수의 return type을 void로 변경하고,

해당 함수를 호출하는 br_handle_frame() 함수에서도 cleanup을 수행했다.

이 전 두 커밋은 기능 Fix나 성능 최적화가 이루어지는 contribute이었던 것에 비해, 해당 커밋은 단순히 cleanup이기 때문에 큰 성과는 아닌 것 같다.

더군다나 해당 패치는 이 전 패치들과 달리 직접 찾은게 아니라 제보를 받은 내용이라.. 그래도 보낸 패치가 accepted 되는건 역시 기분이 좋긴 하다.

Linux Kernel Network Commit #2

pr0gr4m — Fri, 20 Aug 2021 00:54:43 +0900

BlueZ 트리의 bluetooth-next 브랜치에 커밋했다.

[v4] Bluetooth: Fix return value in hci_dev_do_close() - Patchwork (kernel.org)

[v4] Bluetooth: Fix return value in hci_dev_do_close() - Patchwork

patchwork.kernel.org

현재 hci_dev_do_close() 함수는 모든 종료 경로에서 return 0;으로 끝난다.

종료 루틴이 실패하면 에러 값을 반환해야 하는데, 어떤 상황에서도 0을 반환하는 상황이다.

기기 에러 상황에서 reset하는 경우, hci_error_reset 함수에서 이 함수를 호출하는데,

종료 동작이 정상적으로 수행되면 이어서 hci_dev_do_open() 함수를 호출하여 재시작하지만,

종료 동작이 비정상적으로 끝나면 hci_dev_do_open() 함수를 호출하지 않고 끝내야 한다.

또한, ioctl() 함수에서 종료 동작 수행 시에도 이 함수를 호출하는데,

종료가 제대로 수행되지 못했다면 에러값을 반환해줘야 한다.

따라서, 종료 과정에 에러가 생긴 경우 해당 에러 값을 반환하도록 수정해줘야 하는데..

문제는 hdev에 등록되는 모든 close 콜백은 단순히 return 0;으로 끝난다.

그렇다면 그냥 넘어가도 되는건가? 싶겠지만,

위쪽에 shutdown 콜백은 수행 중에 오류가 생길 수 있으며, 에러 값도 제대로 반환해준다.

그러므로 이 shutdown 콜백의 반환 값을 저장해뒀다가, 종료 시 반환하도록 코드를 수정해서 패치를 보냈다.

패치가 v4까지 되었는데, 실수한 점을 짚으면 다음과 같다.

v1 : bluetooth-next 브랜치가 아니라 net-next 브랜치에서 작업하였음 (블루투스 브랜치가 따로 있는지 몰랐음)

v2 : obsolete된 bluetooth-next 브랜치에서 작업하였음 (블루투스 브랜치는 세 개가 있으며, bluetooth group의 브랜치 외에는 obsolete 된 것을 몰랐음)

v3 : 여기서는 메인테이너분의 리뷰 메일을 받았는데 변수 이름을 ret이 아니라 err로 해달라고 요청해주셨음 (관련 메일 : LKML: Marcel Holtmann: Re: [PATCH v3] Bluetooth: Fix return value in hci_dev_do_close())

v4 : bluetooth-next 브랜치에 merge 됨

블루투스 내에서는 가장 코어라고 할 수 있는 부분인데, 이 또한 좋은 성과이다.

Linux Kernel 참고 사이트 추천

pr0gr4m — Tue, 27 Jul 2021 03:51:34 +0900

리눅스 커널을 분석하는데 있어 참고하기 좋은 사이트들을 소개한다.

좋은 사이트를 찾으면 지속적으로 업데이트 할 예정이다.

최초 글 작성 2021-07-27.

해외

1. Elixir Linux

Linux source code (v5.13.5) - Bootlin

elixir.bootlin.com

리눅스 커널 소스 코드를 버전별로 볼 수 있는 사이트이다.

심볼 검색 및 크로스 레퍼런스 기능을 제공한다.

커널 분석에는 vim + ctags + cscope + taglist 를 사용하는 것이 소위 말하는 국룰이었지만,

지금은 (인터넷이 연결되는 상황이라면) 엘릭서 사이트를 이용하는 것이 가장 편한 것 같다.

2. LWN

Welcome to LWN.net [LWN.net]

[Security] Posted Jul 26, 2021 15:13 UTC (Mon) by ris Security updates have been issued by Debian (aspell, intel-microcode, krb5, rabbitmq-server, and ruby-actionpack-page-caching), Fedora (chromium, containernetworking-plugins, containers-common, crun, fo

lwn.net

세상에서 가장 유명한 유닉스 계열 웹진이다.

유료 구독 시 최신 게시글을 볼 수 있고, 1주일이 지난 글들은 아카이브에서 볼 수 있다.

최신 동향과 기술들을 파악할 수 있다.

3. LKML

LKML.ORG - the Linux Kernel Mailing List Archive

lkml.org

리눅스 커널 개발을 위한 메일 아카이브 사이트이다.

패치, 토론, 발표 등 다양한 이야기가 오고간다.

리눅스 커널의 최신 동향을 가장 빠르게 볼 수 있다.

4. Linux Kernel Documentation

The Linux Kernel documentation — The Linux Kernel documentation

This is the top level of the kernel’s documentation tree. Kernel documentation, like the kernel itself, is very much a work in progress; that is especially true as we work to integrate our many scattered documents into a coherent whole. Please note that

www.kernel.org

리눅스 커널 공식 다큐먼트 사이트이다.

내용이 공신력 있지만, 부실하거나 오래된 내용의 문서도 존재한다.

그래도 처음 접하는 기술에 대해 가장 먼저 참고할만한 사이트이다.

국내

1. 문c 블로그

문c 블로그

최신 ARM 리눅스 5.x 커널 분석

jake.dothome.co.kr

사실상 지구에서 리눅스 커널에 대해 가장 자세히 분석해둔 사이트가 아닌가 싶다.

블로그 포스트 중 메모리 포스팅 할 때 굉장히 많이 참고한 사이트이다.

(여담으로, 블로그에 메모리 외에도 프로세스, 스케줄링, 인터럽트 등 다양한 내용에 대해 분석 포스팅을 해보고 싶었는데, 해당 내용들은 아무리 열심히 해도 문c 님 블로그의 하위호환밖에 되지 않을 것 같아서 포기했다.

그 후로 블로그에 직접 쓰는 커널 포스팅은 사실 전부 필자 본인이 나중에 참고하기 위하여 작성한 글이고,

다른 분들에게 도움이 되기 위한 포스트는 문c님 블로그와 겹치지 않는 내용으로 깃헙 페이지에 작성하고 있다.)

2. Arm Linux Kernel Hacks 블로그

Arm Linux Kernel Hacks (egloos.com)

Arm Linux Kernel Hacks

This blog contains Linux Kernel Analysis(4.x/5.x), Arm architecture and debugging skills for seminar and lecture.

rousalome.egloos.com

Austin Kim님의 커널 분석 블로그로, 어려운 내용들에 대해서도 쉽게 잘 설명해주신다.

해당 블로그의 내용들을 업그레이드하여 출간하신 '리눅스 커널의 구조와 원리' 책은 세상에서 커널에 본격적으로 입문하기 가장 좋은 자료라고 생각한다.

위 두 블로그가 한국어 블로그라는 것에 깊은 감사를 느낄 수 밖에 없다.

(커널 공부 시작하는 사람들이라면 누구나 공감할 수 밖에 없을 것이다.)

3. hyeyoo 블로그

Bonjour, tout le monde! (hyeyoo.com)

Bonjour, tout le monde!

공부를 하다보니 기록을 남기는게 좋을거같아 만들어버린 블로그

hyeyoo.com

얼마 전에 알게 된 블로그인데, 안타깝지만 블로그 주인이 최근에 군대를 간 것 같다.

최근에 커널 공부를 시작하여 포스팅중인 것 같은데, 정리를 굉장히 잘 하는 것 같다.

여기서 유일하게 나보다 어린 친구인데, 잘 다녀와서 꾸준히 분석 및 포스팅 했으면 좋겠다.

4. Lazenca TechNote

07.Linux Kernel exploitation techniques - TechNote - Lazenca.0x0

페이지 TechNote 02.TechNote 배너의 맨 끝으로 배너의 맨 처음으로 07.Linux Kernel exploitation techniques 메타 데이터의 끝으로 건너뛰기 Lazenca.0x0님이 작성, 10월 26, 2019에 최종 변경 메타 데이터의 시작으로

www.lazenca.net

여태까지 다른 사이트들은 당연하지만 전부 커널 분석 자체에 초점을 둔 사이트였다.

라젠카님의 테크노트의 경우 해킹/보안에 관련된 기술 블로그인데, 커널 익스플로잇 자료들 중에 가장 참고하기 좋은 것 같다.

익스플로잇 테크닉을 익히는 과정에서 커널 시스템에 대한 이해도를 좀 더 높일 수도 있다.

Linux Kernel Network Commit #1

pr0gr4m — Sat, 24 Jul 2021 01:14:08 +0900

netdev 트리에 ip6_forward() 함수와 mpls_forward() 함수에 커밋했다.

kernel/git/netdev/net.git - Netdev Group's networking tree

ipv6: decrease hop limit counter in ip6_forward()HEADmaster Decrease hop limit counter when deliver skb to ndp proxy. Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 1 files changed, 3 insertions, 2 </davem@davemloft.net></l4stpr0gr4m@gmail.com>

git.kernel.org

ip6_forward() 함수에서 hop_limit 카운터 체크 -> 온전성 검사 -> hop_limit 카운터 감소 순으로 작업을 수행한다.

온전성 검사 중에 NDP 프록시 체크 부분이 있는데, 패킷을 drop하는 다른 검사들과 달리 NDP 프록시라면 SKB를 로컬에 deliver해준다.

해당 과정에서 NDP 프록시 또한 hop이므로 hop_limit 감소가 필요한데, 해당 내용이 누락되어서 추가하였다.

ipv6: decrease hop limit counter in ip6_forward() · torvalds/linux@46c7655 (github.com)

ipv6: decrease hop limit counter in ip6_forward() · torvalds/linux@46c7655

Decrease hop limit counter when deliver skb to ndp proxy. Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net></davem@davemloft.net></l4stpr0gr4m@gmail.com>

github.com

kernel/git/netdev/net-next.git - Netdev Group's -next networking tree

mpls: defer ttl decrement in mpls_forward()HEADmaster Defer ttl decrement to optimize in tx_err case. There is no need to decrease ttl in the case of goto tx_err. Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com> Signed-off-by: David S. Miller <davem@dav< p=""> </davem@dav<></l4stpr0gr4m@gmail.com>

git.kernel.org

mpls_forward() 함수에서 포워딩 시 레이블의 ttl 값을 감소시킨다.

그런데, ip_forward() 함수나 ip6_forward()에서 수행하는 것처럼 ttl 값을 체크한 후 바로 감소할 필요 없이, 온전성 검사를 수행한 이 후 감소해도 무관한다.

온전성 검사를 통과하지 못하여 drop되는 패킷에 대해서는 ttl 감소를 수행하지 않는 것으로 최적화를 할 수 있다.

단, mpls_egress() 함수에서 감소된 ttl 값을 사용하기 때문에 해당 함수가 호출되기 전에 ttl 감소를 수행해줘야 한다.

따라서, 기존에 ttl을 바로 감소시키던 루틴을 온전성 검사 수행 후에 감소시키는 루틴으로 변경시켰다.

마이너 트리에만 커밋하거나, 메이저 트리에는 trivial 커밋만 하다가

메이저 트리에 의미 있는 커밋이 들어가 기분 좋은 성과이다.

[Linux Kernel] network (networking stack)

pr0gr4m — Wed, 14 Jul 2021 20:59:27 +0900

리눅스 커널 네트워킹 스택에 대해 설명합니다.

sk_buff, ICMP, IP, 라우팅 서브시스템, 이웃 서브시스템(ARP, NDISC), TCP, UDP, SCTP, netfilter 등에 대해 포스팅 중입니다.

블로그가 아닌 깃허브 페이지에 작성하였기 때문에 링크들을 첨부합니다.

※ 해당 포스트 내용들은 기본적으로 Linux Kernel Networking 서적을 레퍼런스로 하고 있습니다.

0-1. Linux Kernel Build

Linux Kernel Build - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel Build

해당 포스트는 Ubuntu 20.04 버전을 기준으로 리눅스 커널을 빌드하고 설치하는 방법을 설명합니다.

pr0gr4m.github.io

0-2. Debugging Filesystem

Linux Debugging FileSystem - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Debugging FileSystem

해당 포스트에서는 커스텀 디버깅 파일시스템을 통하여 커널 디버깅하는 방법을 설명합니다.

pr0gr4m.github.io

0-3. ftrace

Linux Ftrace - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Ftrace

해당 포스트에서는 기본적인 ftrace 사용법에 대하여 설명합니다. ftrace는 커널 내부 동작을 파악하기 위하여 사용하는 디버깅 도구입니다. 다음과 같은 기능들이 있습니다. dynamic kernel function traci

pr0gr4m.github.io

1. sk_buff 구조체

Linux Kernel SKB - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel SKB

해당 포스트에서는 sk_buff 구조체에 대하여 설명합니다.

pr0gr4m.github.io

2. ICMPv4

Linux Kernel ICMPv4 - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel ICMPv4

해당 포스트에서는 리눅스 커널의 ICMPv4 구현에 대해 설명합니다.

pr0gr4m.github.io

3. IPv4

Linux Kernel IPv4 - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel IPv4

해당 포스트에서는 리눅스 커널의 IPv4 구현에 대해 설명합니다.

pr0gr4m.github.io

4. IPv4 Routing Subsystem

Linux Kernel IPv4 Routing Subsystem - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel IPv4 Routing Subsystem

해당 포스트에서는 리눅스 커널의 IPv4 라우팅 서브시스템 구현에 대해 설명합니다.

pr0gr4m.github.io

5. Neighbour Subsystem

Linux Kernel Neighbour Subsystem - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel Neighbour Subsystem

해당 포스트에서는 리눅스 커널의 이웃 탐색 시스템과 ARP 프로토콜 구현에 대해 설명합니다.

pr0gr4m.github.io

6. IPv6

Linux Kernel IPv6 - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel IPv6

해당 포스트에서는 리눅스 커널의 IPv6 구현에 대해 설명합니다.

pr0gr4m.github.io

7. ICMPv6

Linux Kernel ICMPv6 - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel ICMPv6

해당 포스트에서는 리눅스 커널의 ICMPv6 구현에 대해 설명합니다.

pr0gr4m.github.io

8. Netfilter

Linux Kernel Netfilter - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel Netfilter

해당 포스트에서는 리눅스 커널의 넷필터에 대해 설명합니다. 넷필터 서브시스템은 네트워크 스택 내에서 패킷이 이동하는 여러 지점에 콜백을 등록하는 것을 비롯해 주소나 포트 변경, 패킷 dr

pr0gr4m.github.io

9. Socket, UDP, TCP

Linux Kernel Layer 4 Network - Linux Kernel Analysis (pr0gr4m.github.io)

Linux Kernel Layer 4 Network

해당 포스트는 리눅스 커널의 Layer 4 계층에 대하여 설명합니다.

pr0gr4m.github.io

리눅스 커널 책 리뷰 및 가이드

pr0gr4m — Wed, 22 Jul 2020 19:56:10 +0900

1. 디버깅을 통해 배우는 리눅스 커널의 구조와 원리

www.yes24.com/Product/Goods/90085976

디버깅을 통해 배우는 리눅스 커널의 구조와 원리 1

신입 리눅스 시스템 개발자부터 5년차 개발자가 실무를 하기 위해 알아야 할 리눅스 커널의 주요 서브시스템!실전 개발에서 신입 사원 옆에 친절한 선배 개발자가 앉아서 리눅스 커널에 대해 꼼

www.yes24.com

www.yes24.com/Product/Goods/90087307

디버깅을 통해 배우는 리눅스 커널의 구조와 원리 2

www.yes24.com

기본적인 커널 컨셉 설명, 구조체와 함수 설명, 커널 디버깅 설명을 쉽게 풀어쓴 책이다.

커널 공부를 본격적으로 시작하기 가장 좋은 책같다.

아주 깊은 내용을 세세하게 설명하지는 않는다.

여태까지 공부했던 커널 책중에 가장 가독성이 뛰어나다.

2. 코드로 알아보는 ARM 리눅스 커널

www.yes24.com/Product/Goods/60856943

코드로 알아보는 ARM 리눅스 커널

최신 ARM64 커널을 코드 레벨에서 상세히 분석하다!현업에서 커널 업무를 하고 있거나, 취미로 커널 분석을 시작했지만 방대한 양과 난해한 코드 때문에 어려움을 겪고 있는가? 시간이 부족하여 �

www.yes24.com

리눅스 커널 코드의 핵심부분을 세세하게 분석한 책이다.

아키텍처 종속적인 부분은 ARM 코드로 분석하는데, 많은 내용이 아키텍처 독립적이고 범용적이다.

솔직히 가독성이 좋지는 않다.

1번 책을 완독한 후 더 자세하게 분석한 자료가 필요하다면 해당 책을 공부하면 좋다.

3. 리눅스 커널 소스 해설 기초입문

www.yes24.com/Product/Goods/89174355

리눅스 커널 소스 해설 기초입문

저자가 리눅스 커널 소스를 분석한 내용을 바탕으로 이해하기 쉽게 구어체로 설명하는 형식으로 구성되어 있다. 이 책을 통해서 최신 리눅스 커널 소스를 컴파일/빌드/분석하는 방법을 단계별��

www.yes24.com

아예 리눅스 커널 자체를 처음 접하는 사람이 입문하기 좋은 책이다.

커널 설정, 빌드와 수정 등을 어떻게 하면 되는지와, 커널에서 대표적으로 사용하는 자료구조를 설명한다.

사실 그다지 깊은 내용을 다루지는 않는다.

4. DevOps와 SE를 위한 리눅스 커널 이야기

www.yes24.com/Product/Goods/44376723

DevOps와 SE를 위한 리눅스 커널 이야기

커널은 오랜 세월 기능이 추가되고 개선되어 오면서 완벽하게 이해하기 힘들 정도로 방대해졌다. 하지만 변하지 않는 기본 기능들이 있다. 이런 근간이 되는 기능에 대한 이해를 바탕으로 시스�

www.yes24.com

책 제목에서 볼 수 있는 것과 같이, 주로 SE를 위한 커널 컨셉과 설정들을 설명한다.

소스 코드를 분석하거나 수정하기 위한 책은 아니다.

리눅스 시스템을 조금 더 전문적으로 관리할 수 있는 지식을 쌓을 수 있다.

5. 리눅스 커널 프로그래밍

www.yes24.com/Product/Goods/19660111

리눅스 커널 프로그래밍

이 책은 커널을 과감히 뜯어고쳐가면서 다양한 실습을 하는 데 집중하고 있다. 눈으로 보고, 머릿 속으로 생각하는 것이 아니라 손가락을 바삐 움직이면서 커널을 이해하는 것을 목표로 하고 있

www.yes24.com

2.4 - 2.6 버전 커널을 실습하며 익힐 수 있는 책이다. (절판되었다.)

깊은 내용을 세세하게 설명하지는 않지만, 커널 수정 및 모듈 프로그래밍 실습을 진행하며 이해도를 높일 수 있다.

커널 4,5버전과는 맞지 않는 내용이 대부분이지만, 해당 내용들을 최신 커널에 맞춰 업데이트해가며 실습하면 이해도를 더욱 높일 수 있다.

6. 리눅스 커널 네트워킹

www.yes24.com/Product/Goods/31918354

리눅스 커널 네트워킹

『리눅스 커널 네트워킹』은 최신의 리눅스 네트워킹 서브 시스템을 다루는 책이다. 리눅스 네트워킹 서브 시스템이 기초적이고, 안정적이지만 수많은 프로토콜과 기술이 녹아들어 있는 네트��

www.yes24.com

커널 네트워크 부분을 상세하게 설명한 책이다.

1,2번 책이 네트워크 부분을 다루지는 않는데, 이 책을 공부하면서 해당 부분을 커버할 수 있다.

7. 리눅스 커널 HACKS

www.yes24.com/Product/Goods/12474141

리눅스 커널 HACKS

인터넷상에는 리눅스에 관한 정보가 넘쳐나고 있지만, 대단히 복잡하게 진화한 리눅스 커널을 능숙하게 사용하거나 리눅스 커널 개발에 참가하는 데 필요한 정보는 충분히 얻을 수 없는 현실에

www.yes24.com

리눅스 커널에 있는 컨셉들을 설명하고 어떻게 시스템을 최적화하는지 설명한 책이다.

절판된 책이며 2.6버전 커널이기에 커널 4,5버전과 일부 맞지 않을 수는 있다.

하지만 수록된 테크닉들은 전반적인 시스템 세팅 능력 향상에 도움이 된다.

8. 리눅스 커널 IN A NUTSHELL

www.yes24.com/Product/Goods/3224540

리눅스 커널 IN A NUTSHELL

리눅스 커널이 무료로 사용할 수 있는 운영체제라 할지라도 이를 어떻게 활용하는지에 따라 발휘할 수 있는 성능은 천차만별이라고 말하면서 커널 소스를 보배로 변화시킬 수 있는 기본적인 사

www.yes24.com

커널 권위자 그렉옹의 레퍼런스북이다.

마찬가지로 구버전 커널 내용이긴 하지만, 원래 커널에 어떤 개념들이 있었나 살펴보기 좋다.

7번 책과 병행하면 시너지효과가 있다.

9. Linux Kernel Development

www.yes24.com/Product/Goods/3124201

Love: Linux Kernel Development _p3

www.yes24.com

리눅스 커널의 전반적인 내용을 설명한다.

과거 공부할만한 자료가 없었을땐 입문하기 좋은 책이었지만,

현재는 국내에 1번같은 서적도 있고 해당 서적 내용이 마찬가지로 2.6 기준이라 그다지 추천하진 않는다.

단, 커널이 아니라 OS 공부에 입문하려고 하는데 공룡책은 싫고 리눅스 기준으로 공부하고 싶다 하면 해당 책을 강추한다.

10. Understading the Linux Kernel

www.yes24.com/Product/Goods/1583489

Understanding the Linux Kernel

In order to thoroughly understand what makes Linux tick and why it works so well on a wide variety of systems, you need to delve deep into the heart of the kernel. The kernel handles all interactions ...

www.yes24.com

9번과 약간 비슷한 양상이긴 하지만 좀 더 깊이있는 내용을 설명한다.

커널의 많은 핵심 개념들, 구조체, 함수 등을 설명하는데 마찬가지로 out-of-date지만, 내용이 좋아서 추천할만하다.

1,2번 책이 커널 자체에 집중해있다면 해당 책은 좀 더 넓은 OS 컨셉으로 시작해서 점차 리눅스 커널 내용으로 좁혀들어간다.

11. Linux Device Drivers

www.yes24.com/Product/Goods/1461176

Linux Device Drivers

This book, a classic entering its third edition, is a must-read for anyone who wants to support computer peripherals under the Linux operating system, wants to run new hardware under Linux, or is simp...

www.yes24.com

해외 사이트들을 보면 이 책을 완독하기 전까지 커널 프로그래밍을 하지 말아라 라는 문구가 있을 정도의 바이블이다.

아쉽게도 그렉옹이 레딧에 4판은 계획에 없다고 밝혔다.

예제들이 마찬가지로 obsolete된 내용들이 많아 잘 되지 않지만,

깃헙에 예제 up-to-date 프로젝트들이 꽤나 있다. (https://github.com/martinezjavier/ldd3)

디바이스 드라이버 제작뿐만이 아니라 전반적인 커널 프로그래밍에 있어 바이블이 되는 책이다.

개인적으로 목적에 따른 학습 커리큘럼은 아래와 같이 추천한다.

(물론 리눅스 환경과 리눅스 시스템 프로그래밍에 익숙하다는 전제가 깔려있다.)

시스템 최적화를 위한 커널 학습 : 4 -> 7 -> 8

리눅스 커널 분석 및 연구 : 3(선택) -> 1 -> 10 -> 2 -> 6

리눅스 커널 프로그래밍 : 5 -> 1 -> 11

p.s. 위 절판된 책들은 대부분 도서관에서 빌려볼 수 있습니다.

[Linux Kernel] spinlock

pr0gr4m — Fri, 10 Jul 2020 09:33:45 +0900

arm 리눅스 커널의 spin lock 구현부를 보면 다음과 같다.

typedef struct {
	union {
		u32 slock;
		struct __raw_tickets {
#ifdef __ARMEB__
			u16 next;
			u16 owner;
#else
			u16 owner;
			u16 next;
#endif
		} tickets;
	};
} arch_spinlock_t;

static inline void arch_spin_lock(arch_spinlock_t *lock)
{
	unsigned long tmp;
	u32 newval;
	arch_spinlock_t lockval;
 
	prefetchw(&lock->slock);
	__asm__ __volatile__(
"1:	ldrex	%0, [%3]\n"
"	add	%1, %0, %4\n"
"	strex	%2, %1, [%3]\n"
"	teq	%2, #0\n"
"	bne	1b"
	: "=&r" (lockval), "=&r" (newval), "=&r" (tmp)
	: "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
	: "cc");
 
	while (lockval.tickets.next != lockval.tickets.owner) {
		wfe();
		lockval.tickets.owner = READ_ONCE(lock->tickets.owner);
	}
 
	smp_mb();
}

arch_spinlock_t 타입의 락 변수 lock의 tickets을 보면 next와 owner로 구성되어 있는데,

next == owner이면 해당 스핀락은 점유되지 않은 상태이고,

next가 owner보다 크다면 현재 점유되고 있는 상태이다.

여기서 arch_spin_lock 코드를 보면 인라인 어셈블리 코드에서 lock의 next를 1 증가시키고

이 후 while문에서 기존 lock의 next 값(1 증가시키기 전)과 owner 값을 비교하여 둘이 같으면 함수를 종료한다.

(owner 값은 busy-waiting이 끝날 수 있도록 while문 내에서 READ_ONCE를 통해 계속 최신 값을 업데이트한다.)

즉, next = owner = 1인 상황에서 spin_lock을 호출하면

1) next = 2, owner = 1이 됨

2) 기존 next와 owner가 1이므로 함수 종료

가 된다.

이 상태에서 unlock하지 않고 (next = 2, owner = 1) 다른 프로세스가 다시 한번 spin_lock을 호출하면

1) next = 3, owner = 1이 됨

2) 기존 next와 owner가 같지 않으므로 while문 반복

2-1) lock ticket의 owner값을 읽음

2-2) 먼저 락을 획득한 프로세스가 unlock하여 owner값이 2가 되면 기존 next와 owner값이 같아져서 while문 탈출

3) 함수 종료

가 된다.

여기서 체크 -> 증가 순서가 아닌, 증가 -> 체크를 하는 것에 의아할 수 있다.

선 증가 후 체크라면 여러개의 프로세스가 동시에 점유되어있는 스핀락을 잠그려고 시도하면 버그가 일어나지 않을까 생각할 수 있다.

예를 들어, next = 2, owner = 1인 상태에서 A와 B가 동시에 lock을 시도한다고 하면

1) A가 next를 3으로 증가시킴

2) B가 next를 4로 증가시킴

3) 기존 태스크가 unlock함

4) 기존 next는 2이며 owner는 2로 업데이트되어 A와 B가 동시에 함수를 빠져나감

5) A와 B가 동시에 lock을 획득해버렸음

같은 상황이 나올 수 있다고 생각할 수 있다.

하지만 이는 strex라는 exclusive monitor instruction에 의해 방지된다.

인라인 어셈블리 내용을 조금 자세히 살펴보면 다음과 같다.

__asm__ __volatile__(
"1: ldrex %0, [%3]\n"
" add %1, %0, %4\n"
" strex %2, %1, [%3]\n"
" teq %2, #0\n"
" bne 1b"
: "=&r" (lockval), "=&r" (newval), "=&r" (tmp)
: "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
: "cc");

%0, %1, %2, %3, %4는 차례대로 lockval, newval, tmp, &lock->slock, 1 << TICKET_SHIFT가 된다.

2번 라인에서 lock의 ticket 값을 lockval에 로드한다.

3번 라인에서 lockval + (1 << TICKET_SHIFT) 값을 newval에 저장한다.

4번 라인에서 lock의 ticket 값을 newval 값으로 업데이트한다.

여기서 lock의 ticket값을 자신만 업데이트하였다면 exclusive monitor status가 변경되지 않아 tmp가 0으로 업데이트된다. 만약 다른 누군가가 lock의 ticket값을 건드렸다면, exclusive monitor status가 변경되어 tmp가 1이 된다.

5번 라인에서 tmp값이 0인지 확인한다.

6번 라인에서 tmp값이 0이 아니라면 1번 레이블로 돌아가서 처음부터 다시 수행한다.

따라서 위 시나리오의 1번과 2번에서 A와 B가 동시에 next를 증가시켜 next가 4가 될 수 없다.

STREX 명령어에 대해 더 자세히 알고싶다면 다음 링크를 참고한다.

아무튼 arm상에서 스핀락의 구현은 위와 같다.

(참고로 x86/amd64상에서는 스핀락이 struct qspinlock으로 구현되어있다.

lock/unlock 함수들의 구현은 mutex와 상당히 유사하다.)