code cat

출처: virtual linux manager by Mel Gorman

memory 는 bank로 나뉘어짐
bank는 node라고 불리며,
node는 struct pglist_data로 표현됨.(UMA일때도 마찬가지)

pglist_data는 pg_data_t로 참조된다. 
시스템의 모든 node는 NULL로 끝나는 pgdata_list 이라는 리스트로 관리된다.
그리고 각 node는 pg_data_t->node_next로 다른 node와 연결된다.

UMA의 경우 contig_page_data라는 하나의 pg_data_t 구조체를 사용한다.(노드가 하나 이니까)

각 node는 'zone' 이라 불리는 여러개의 블록으로 나뉜다.

zone은 struct zone_struct 이라는 구조체로 정의되며, zone_t로 사용자정의된다.

zone의 종류에는,
ZONE_DMA 
ZONE_NORMAL
ZONE_HIGHMEM
(ZONE_MOVEABLE)
이 있다.
 
신경써야 할 부분은 ZONE_NORMAL이다.  ZONE_HIGHMEM은 ZONE_NORMAL의 상위 위쪽 부분이다.

시스템의 메모리는 page frame이라는 고정된 chunk들로 이루어져 있다.
각각의 physical page frame들은 struct page라는 구조체로 표현되며,
이 모든 구조체들은 mem_map이라는 배열에 저장된다.
(mem_map은 보통 ZONE_NORMAL 시작부분이나 지정된 커널 로딩 영역 뒤에 저장된다)

2.1 Nodes
리눅스는 page를 할당할 때, node-local alloocation policy를 사용해서
현재 실행 중인 CPU에서 가장 가까운 node의 메모리를 할당한다.

pg_data_t, 즉 pglist_data는 다음가 같이 정의되어 있다.
struct pglist_data { zone_t node_zones[MAX_NR_ZONES]; zonelist_t node_zonelists[GFP_ZONEMASK+1]; int nr_zones; struct page *node_mem_map; unsigned long *valid_addr_bitmap; struct bootmem_data *bdata; unsigned long node_start_paddr; unsigned long node_start_mapnr; unsigned long node_size; int node_id; struct pglist_data *node_next; } pg_data_t;

node_zones	ZONE_HIGHMEM, ZONE_NORMAL_ZNOE_DMA가 있다.
node_zonelists	zone들이 할당되는 순서를 가지고 있다.  free_area_init_core()에 호출 된 mm/page_alloc.c의 build_zonelists()가  순서를 정한다.
nr_zones	zones의 갯수
valid_addr_bitmap	메모리 node에 있는 "holes" 에 대한 비트맵
bdata	boot memory allocator
node_start_paddr	node의 시작 주소(physical)   Page Frame Number(PFN)에 기록하는게 좋다.   PFN은 physicla memory의 index이며, page-sized unit 단위로 세어진다. PFN 은 (page_phys_addr >> PAGE_SHIFT) 로 손쉽게 정의될 수 있다.
node_start_mapnr	전역 mem_map안의 page offset.    free_area_init_core()에서 mem_map과 지역적 mem_map사이의 페이지 개수로 계산됨
node_size	zone안의 총 page 수
node_id	node ID (NID).  0부터 시작함
node_next	위에서 말한 node list의 다음 node를 가리킴

             
앞서 말했듯이, 시스템의 모든 node들은 pgdat_list라는 리스트에서 관리되며, init_bootmem_core()에 의해 이 리스트에 추가된다.

2.2 Zones

각 zone들은 struct zone_struct으로 구성된다. (linux/mmzone.h 참조)

내용은 다음과 같다.

typedef struct zone_struct { spinlock_t lock; unsigned long free_pages; unsigned long pages_min, pages_low, pages_high; int need_balance; free_area_t free_area[MAX_ORDER]; wait_queue_head_t * wait_table; unsigned long wait_table_size; unsigned long wait_table_shift; struct pglist_data *zone_pgdat; struct page *zone_mem_map; unsigned long zone_start_paddr; unsigned long zone_start_mapnr; char *name; unsigned long size; } zone_t;

lock	zone을 보호하는 spinlock
free_pages	zone에 존재하는 free page
pages_min,   page_low, pages_high
zone_pgdata	pg_data_t 를 가리킨다.
zone_mem_map	전역 mem_map
zone_start_paddr	node_start_paddr와 유사
zone_start_mapnr	node_start_mapnr와 유사
name	zone 이름, "DMA", "NORMAL", "HighMem"
size	pages단위로 표현된 zone의 사이즈

 

2.2.1 Zone Watermarks

시스템에 남아있는 메모리가 적을 경우, kswapd라는 pageout 데몬이 실행되어 page들을 free하기 시작한다.  만약 메모리를 많이 회수해야 한다면, kswapd 데몬은 동기적으로 메모리를 free 한다.(이 방식은 direct-reclaim이라고 불리기도 한다.)

각 zoned은 세가지의 watermark를 가지고 있는데, 이들은 각각 다음과 같다.

pages_low	free page의 수가 pages_low에 이르면, kswapd가 buddy allocator에 의해 깨어나서 page들을 free한다
pages_min	pages_min에 이르면, buddy allocator는 kswapd를 동기화적으로 돌린다.
pages_high	page_high에 이르면 kswapd는 다시 sleep으로 돌아간다.

pages_min은 free_area_init_core()에서 메모리 초기화 과정에서 page 단위로 표현된 zone의 크기로 표현되어 계산된다.

2.2.2 Calculating the size of Zones

각 zone의 크기는 setup_memory()에서 계산된다.

PFN은 pages단위로 세어진 실제 메모리 맵(physical memory map)안의 오프셋이다.

min_low_pfn은 첫번째 PFN이며, _end 다음의 첫번째 페이지에 위치한다.  min_low_pfn은 나중에 쓰일 boot memory allocator를 위해 mm/bootmem.c 에 file scope 변수로 지정되어 있다.

unsigned long min_low_pfn;

unsigned long max_low_pfn;

unsigned long max_pfn;

마지막 페이지 프레임인 max_pfn 은 아키텍쳐 의존적으로 계산된다.  x86의 경우 find_max_pfn()으로 e820 map을  통해 가장 높은 값을 갖는 페이지 프레임을 읽는다. (e820은 BIOS를 통해 얻어지는 테이블이며, 어떤 physicla memory가 있는지, 예약되어 있는지등을 알려준다)  

max_low_pfn은 (x86의 경우) find_max_low_pfn()을 통해 계산되며, 이는 ZONE_NORMAL의 끝을 표시한다.

	ZONE
_end
min_low_pfn	first page
	pages ...
max_low_pfn	end of ZONE_NORMAL     <- kernel/userspace split point

2.2.3 Zone Wait Queue Table

(생략)

 

2.3 Zone Initialization

zone 들은 kernel page table 이 paginig_init()에 의해 완전히 세팅되고 나면 초기화 된다.  페이지 테이블 초기화에 대해서는 3.6을 참조하자.

아키텍쳐마다 방식에는 다르겠지만, 기본적으로 UMA 일 경우, free_area_init()에 보낼 매개변수를, NUMA일 경우, free_area_init_node()에 보낼 매게변수를 결정한다.  이 매게변수들은 다음과 같다.

nid	초기화 될 zone을 가지고 있는 NODE의 NODE id
pgdat	초기화되는 node의 pg_data_t이며, UMA의 경우 contig_page_data이다.
pmap	free_area_init_core()에 의해 지정되며, local mem_map의 시작부분을 가리킨다. NUMA는 mem_map을 PAGE_OFFSET에 시작하는 가상 배열로 생각하기 때문에 무시하며, UMA의 경우 pmap은 global mem_map을 가리킨다.
zone_sizes	각 zone의 크기를 담고 있는 배열
zone_start_paddr	첫번째 zone의 시작 실제 주소(starting physical address)
zone_holes	zones에 있는 메모리 홀의 총 사이즈를 담고 있는 배열

free_area_init_core()는 각 zone_t의 내용을 연관성이 있는 정보로 채우는 역활 및 mem_map 배열 할당을 한다.  현 상황에서는 어떤 페이지가 free인지는 알 수 없으며, boot memory allocator의 작업이 끝날 때 까지는 알 수 없다.

 

2.4 Initializing mem_map

mem_map은 시스템 초기화 과정에서 생성된다.

NUMA의 경우, global mem_map이 PAGE_OFFSET에서 시작하는 가상 배열로 취급되며, 각 node 마다 free_area_init_node()를 호출하여 이 가상 배열을 할당한다.  

UMA의 경우, free_area_init()이 contig_page_data를 node로, global mem_map을 local mem_map으로 동일하게 취급한다.

locla mem_map은 free_area_init_core()에 의해 할당되며, 이를 위한 배열은 boot memory allocator가 alloc_bootmem_node()를 호출하여 할당한다.  UMA의 경우, 이렇게 할당된 메모리는, 위에서 말한 거 처럼, global mem_map이 되나, NUMA의 경우 조금 다르다.  NUMA는 local mem_map을 각 node의 고유한 메모리에서 할당하며, global mem_map의 경우 따로 할당되지는 않으나, (가상 배열로 취급되는)PAGE_OFFSET으로 설정된다.  local map은 pg_data_t->node_mem_map에 저장된다.

node에 존재하는 각 zone들은  가상 mem_map의 주소를 zone_t->zone_mem_map에 저장한다.  이 외의 작업에서는 mem_map을 실제 배열로 취급한다.

 

2.5 Pages

모든 시스템의 physical page frame은 struct page를 가지고 있다.

      

안드로이드 일을 하다보면 안드로이드에서 필요로 하는 ramdisk.img 쪽에 대한 디버깅이 필요할 때가 있다.  이럴 때는, 간단하게, 다음과 같이 하자.

1. 우선 ramdisk.img를 자신의 리눅스 환경으로 카피해 오고 백업을 만들자.
cp ramdisk.img  ramdisk.img.back
mkdir mytemp
cd mytemp

2. ramdisk.img를 풀자.
gunzip -c ../ramdisk.img | cpio -i

3. 디버깅을 하던 파일을 바꾸던 필요한 작업을 하자.

4. 다시 ramdisk.img로 패킹하자.
find . | cpio -o -H newc | gzip > ../ramdisk.img

mkbootimg로 아마 다시 패킹해야 할 텐데, mkbootimg 치면 사용법 나오니 그건 알아서 하자.

예전에 ext4파일 시스템 굽기에 대해서 적은 글에 대해서 지금와서 생각해보니 나름대로 용도가 있겠지만, 그 당시에 필요했던 용도로 쓰기엔 매우 불편한 방법이었다.

그래서 더 쉬운 방법이 생각났는데, 그거슨..


/dev/sda1 등으로 되어있는 디바이스 파일을 통째로 덤프를 떠서 bin파일로 만든 뒤에 이를 mount시키면 되는 것이다.
덤프를 뜨는 방법은 뭐 간단히 cat을 써도 되고, 프로그램을 하나 만들어서 읽어써 쓰는 작업을 해도 되겠다.

실제로 해보니 너무 간단히 되어 버려서 허탈했다.
그러나 위에서 말했듯이, dd를 사용해서 쓰는 방법도 나름 쓸모가 있다. 예를 들면 원하는 크기의 ext4파일 시스템을 빈 상태로 설정해 준다던가.. 어쨌든 알아두면 유용하게 쓰일 일이 있다.

쉘 스크립트가 오동작을 하거나 이해하기 힘든 동작을 보일 때, 디버깅을 하려면 다음과 같이 하면 매우 편하다.

보통 쉘의 시작 부분은 #!/bin/sh로 되어 있는데, 이는 스크립트가 어떤 쉘에서 동작하는지를 정하는 매직코드이다.

그래서 위와 같이 하면, 쉘 코드가 한줄 한줄 실행되는 걸 볼 수 있어 디버깅하기에 좋다.

출처: Secure Coding in C and C++

Linux 의 기본 바이너리 포맷은 ELF(Executable and Linking Format)이다.  ELF는 원래 UNIX System Laboratories(USL)에 의해 ABI(Application Binary Interface)의 일환으로 개발되었다.

ELF 파일의 프로세스 공간은 GOT(Global Offset Table)을 포함하고 있는데, 이 GOT는 절대 주소값을 가지고 있다.  이렇게 절대 주소값을 가지고 있을 경우, 코드 영역의 위치여부나 공유여부에 상관없이 사용 할 수 있게 된다.

실제 테이블의 내용이나 형태는 프로세서의 종류에 따라 다를 수 있지만,   기본적으로 GOT는 다이나믹 링킹 프로세스를 지원하는데 있다.

프로그램에 의해 사용되는 모든 라이브러리 함수는 GOT에 실제 함수의 주소를 가진 엔트리를 가지고 있으며, 이는 라이브러리가 쉽게 프로세스 메모리 안에서 재배치될 수 있게 한다.  프로그램이 실제로 함수를 처음으로 사용하기 전까지는, GOT의 엔트리에는 RTL(RunTime Linker)의 주소를 가지고 있다.  만약 프로그램에 의해 함수가 호출되면, RTL에게 제어는 넘어가며, 함수의 실제 주소가 GOT에 등록된다.  차후의 함수 호출은 RTL을 거칠 필요 없이 GOT를 통해서 호출된다.

GOT 엔트리의 주소는 EFL 파일의 고정된 위치에 있고, 결과적으로 모든 실행 프로세스 이미지들에게 공통적인 주소에 있게 된다.  GOT 엔트리의 위치를 알려면, 'objdump' 커맨드를 사용하여 확인 할 수 있다.