카테고리 보관물: Personal projects

XCode에서 OpenCL 개발환경 설정과 간단한 디바이스 정보 출력 예제

  1. XCode에서 새로운 프로젝트를 생성하고 macOS의 Command Line Tool을 선택한다.
  2. Project를 선택하고 ‘Build Phases’ -> ‘Link Binary With Libraries’에서 더하기(+)를 선택한 후 OpenCL framework을 선택한다.

아래의 예제 코드는 OpenCL programming by example의 2장에 나오는 내용을 약간 변경한 것으로 AMD 라데온 Pro 455와 Intel HD graphics 530두 개의 GPU가 달린 2016년 맥북프로에서 실행하면 다음과 같은 결과가 출력된다.

Number of platforms: 1
3 devices found in platform0
	Name: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
	Type: 2
	Image support: 1
	Vendor: Intel
	Driver ver.: 1.1
	Device ver.: OpenCL 1.2 
	Compute units: 8
	Max clock: 2700 MHz
		Denorms: 1
		INF and quiet NaNs: 1
		Round to nearest: 1
		Round to zero: 1
		Round to INF: 1
		FMA: 1

	Name: Intel(R) HD Graphics 530
	Type: 4
	Image support: 1
	Vendor: Intel Inc.
	Driver ver.: 1.2(Aug 31 2020 22:26:30)
	Device ver.: OpenCL 1.2 
	Compute units: 24
	Max clock: 1050 MHz
		Denorms: 1
		INF and quiet NaNs: 1
		Round to nearest: 1
		Round to zero: 1
		Round to INF: 1
		FMA: 1

	Name: AMD Radeon Pro 455 Compute Engine
	Type: 4
	Image support: 1
	Vendor: AMD
	Driver ver.: 1.2 (Sep 11 2020 22:04:49)
	Device ver.: OpenCL 1.2 
	Compute units: 12
	Max clock: 855 MHz
		Denorms: 1
		INF and quiet NaNs: 1
		Round to nearest: 1
		Round to zero: 1
		Round to INF: 1
		FMA: 1

Program ended with exit code: 0

Docker로 OpenGrok 설치

잘 쓰고 있던 OpenGrok 서버가 갑자기 맛이 가는 바람에 부랴부랴 대안을 찾아야 했는데 마땅한 서버가 없어서 로컬 머신에 Docker로 설치하는 방법을 찾아 보았다. 여기 소개된 내용은 Docker Hub에서 자세한 설명을 찾을 수 있다.

Docker가 설치되어 있다면 command창에서 다음의 명령으로 OpenGrok docker를 pull한다.

docker pull opengrok/docker

Pulling이 끝나면 목적에 소스와 indexing결과가 저장될 공간을 만들어 준다. src에는 분석할 소스를 넣고 bin에는 편의를 위한 스크립트를 넣을 예정이다.

mkdir -p ~/opengrok/bin
mkdir -p ~/opengrok/src
mkdir -p ~/opengrok/etc
mkdir -p ~/opengrok/data

이제, 8080 port에 접속 설정을 하고 위에서 만든 volume들을 docker에 마운트 시켜준다. Git server에 접근하기 위해 키 관련 설정을 해주어야 하는데, 귀찮아서 그냥 .ssh 디렉토리를 마운트 시켜 주었다.

docker run -d \
    --name opengrok \
    -p 8080:8080/tcp \
    -v ~/opengrok/bin/:/opengrok/bin/ \
    -v ~/opengrok/src/:/opengrok/src/ \
    -v ~/opengrok/etc/:/opengrok/etc/ \
    -v ~/opengrok/data/:/opengrok/data/ \
    -v ~/.ssh:/root/.ssh \
    opengrok/docker:latest

이제 해당 서버의 콘솔을 열고 인덱싱 명령을 수행하면 된다. GUI가 없다면 다음의 명령으로 실행 중인 docker에 접속할 수 있다.

docker exec -it <docker_container_id> bash

서버에 접속한 후 인덱싱을 수행하는 명령어는 다음과 같다.

export OPENGROK_DIR=/opengrok
java \
    -Djava.util.logging.config.file=$OPENGROK_DIR/etc/logging.properties \
    -jar $OPENGROK_DIR/lib/opengrok.jar \
    -c /usr/local/bin/ctags \
    -s $OPENGROK_DIR/src -d $OPENGROK_DIR/data -H -P -S -G \
    -W $OPENGROK_DIR/etc/configuration.xml -U http://localhost:8080/

인덱싱이 끝나면 웹브라우져에서 http://localhost:8080으로 접속하면 된다.

위의 인덱싱 명령어가 너무 길어서 입력하기 힘들기 때문에 source code를 업데이트하고 인덱싱 하는 과정을 묶어서 다음과 같이 스크립트로 만들고 ~/opengrok/bin 안에 넣어 두면 편리하게 사용할 수 있다.

Linux에서 메모리 포인터의 유효성 검증

Windows에서와 달리 Linux환경에서는 딱히 포인터의 유효성을 검증할 수 있는 system call이 없다. 이 포스팅은 Linux환경에서 이와 유사한 기능을 구현하기 위해 “정보의 바다”에서 찾은 내용들을 정리해 둔 것이다.

1. _etext를 이용하는 방법

첫번째 방법은 Define and use a pointer validation function 이라는 위키문서에서 가져온 것인데 컴파일러가 생성하는 text 영역의 시작점을 이용해서 포인터 값이 이를 침범 하는지 여부를 검사하고 유효성을 판단한다. 하지만 위 링크의 커멘트에도 나와 있듯이 시스템에 따라 동작하지 않을 수도 있으므로 reliable 한 구현이라 볼 수는 없다.

bool isValidPointer_ET(void *ptr) {
    extern const char _etext;
    return (ptr != nullptr) && ((const char*)ptr > &_etext);
}

2. msync()를 이용하는 방법

Checking whether a pointer is valid in Linux라는 블로그 포스트에 소개된 방법으로 매핑된 메모리 공간을 동기화 할 때 쓰는 msync() 시스템 콜을 호출 하면서 유효하지 않은 page 시작 주소를 넘겨 주면 0이 아닌 음수 값을 반환하는 것을 이용하는 방법이다. (이 경우 errno에 ENOMEM이 설정된다)

#include <sys/mman.h>
#include <unistd.h>

bool isValidPointer_MS(void *ptr) {
    const size_t pageSize = sysconf(_SC_PAGESIZE);
    void *basePtr = (void *)((((size_t)ptr) / pageSize) * pageSize);
    return msync(basePtr, pageSize, MS_SYNC) == 0;
}

3. mincore()를 이용하는 방법

Stackoverflow에 올려진 Testing pointers for validity (C/C++)라는 질문에 대한 답변에 있는 아이디어 중 하나인데 메모리 페이지의 swap 상태를 확인해서 반환해 주는 mincore()을 이용하는 방법이다. 해당 답변에는 다른 아이디어 들도 있으니 필요에 따라 참고.

#include <sys/mman.h>
#include <unistd.h>

bool isValidPointer_MC(void *ptr) {
    unsigned char vec = 0;
    const size_t pageSize = sysconf(_SC_PAGESIZE);
    void *basePtr = (void *)((((size_t)ptr) / pageSize) * pageSize);
    int ret = mincore(basePtr, pageSize, &vec);
    return (ret == 0 && ((vec & 0x1) == 0x1));
}

시험 결과와 결론

위의 함수들에 대해 Linux환경에서 전역 변수 포인터, 지역 변수 포인터, 널 포인터, 널 포인터는 아니지만 명백하게 무효한 포인터(0x04 같은), 동적 할당된 공간에 대한 유효성 여부는 잘 동작한다.

하지만, 이미 해제된 포인터나 할당되지 않은 heap 공간 내의 임의 주소에 대해서는 제대로 유효성 여부를 판단하지 못하고, 주소 범위가 유효 하다면 포인터 역시 유효 하다고 판단하는 오류가 세가지 구현 모두에 있다.

    // 해제된 heap공간에 대한 유효성 여부 확인. 모두 실패함.
    unsigned int* dynamicVar = new unsigned int[100];
    delete[] dynamicVar;
    EXPECT_FALSE(isValidPointer_ET(dynamicVar));
    EXPECT_FALSE(isValidPointer_MS(dynamicVar));
    EXPECT_FALSE(isValidPointer_MC(dynamicVar));


    // 할당 되지 않은 Heap공간 내의 임의 포인터에 대한 유효성 확인. 모두 실패함.
    unsigned int* dynamicUnallocVar = dynamicVar + 100;
    EXPECT_FALSE(isValidPointer_ET(dynamicUnallocVar));
    EXPECT_FALSE(isValidPointer_MS(dynamicUnallocVar));
    EXPECT_FALSE(isValidPointer_MC(dynamicUnallocVar)); 

즉, 위의 구현 들은 주어진 포인터가 유효한 메모리 공간내에 속하는지는 확인할 수 있어도, 동적 할당 영역의 메모리 포인터가 실제 read/write 가능한 상태인지 여부는 정확히 반환 할 수 없다.

시험에 사용한 code는 여기에 붙여 둔다.

연관 컨테이너에 find_if()를 쓴다구요?

연관 컨테이너는 데이터를 추가 할 때 내부에 hash table이나 tree 구조를 유지해서 많은 원소가 삽입 되더라도 원하는 값을 빠른 속도로 검색 하는것이 가능하도록 해준다.

어떤 key가 주어 졌을 때 이것이 정확히 원하는 값이 아니 더 라도 특정한 범위에 들면 해당 Block을 반환하는 코딩을 하고 있었는데, 생각보다 map이나 set 같은 연관 컨테이너에 find_if()로 조건을 주는 코드 레퍼런스들이 많았다. 예를 들면 다음과 같이 주어진 set에 대해 find_if()로 모든 원소들을 돌면서 주어진 key가 들어 갈 수 있는 Block 찾는 것과 같은 경우이다.

find_if(
  s.begin(), s.end(),
  [findKey](const Block* el) {
    return findKey >= el->blkBase \
      && findKey < (el->blkBase + el->blkSize); });

주어진 원소의 수가 얼마 없다면 이런 종류의 코드가 별 무리가 없겠지만, 원소의 수가 많아지면 두드러지는 성능 차이를 보인다. 다음은 이와 같이 find_if()로 모든 원소들을 방문해 가며 range에 속하는지 검사하는 코드를 vector, map, set에 대해서 10만개의 원소로 돌린 것인데, 오히려 vector에 비해 map과 set이 각각 4배에서 6배 정도의 느린 검색 성능을 보여 준다.

[Vector]
100000 items pushed to vector.
Insertion: 13ms
Searching: 28879ms

[Map]
100000 items pushed to map.
Insertion: 63ms
Searching: 120259ms

[Set]
100000 items pushed to set.
Insertion: 60ms
Searching: 193998ms

연관 컨테이너 들은 원소를 추가할 때 효율적인 검색을 위한 부가적인 동작을 수행해야 하므로 insertion에 시간이 조금 더 걸리는 건 그렇다 쳐도, 원소의 수에 따라 선형적으로 검색 시간이 증가하는 vector에 비해 4배에서 6배 정도의 검색 시간이 더 드는 결과는 연관 컨테이너에 대해 find_if()를 들이 대는 자체가 현명한 생각인가 하는 의구심이 들게 한다. 즉, find_if()를 사용하면 주어진 컨테이너의 구조에 맞게 효율적으로 iteration을 해 주고 그런거 없다. 적어도 g++(v7.5.0)에서는.

그렇다면 이 경우 처럼, C++에서 특정한 값이 아니라 주어진 키가 범위에 드는지 검사하고 싶은 경우는 어떻게 해야 할까? Java의 Navigatable* 만큼은 세부적이진 않지만 C++의 map과 set 모두 주어진 key에서 가장 가까운 값을 반환하는 lower_bound() / upper_bound()를 제공한다. 이를 이용해서 다음과 같이 반환된 객체에 대해서만 추가로 검사를 해서 범위에 드는지 확인하면 보다 효율적으로 구현할 수 있다.

auto re = s.lower_bound(&findBlk);
auto el = *re;
if (re != s.end()
    && (findKey >= el->blkBase && findKey < (el->blkBase + el->blkSize))) {
}

이렇게 find_if()로 모든 원소들을 방문하는 것이 아닌, lower_bound()로 반환 받은 결과만 검사하는 방법으로 위와 같은 10만개의 원소에 대해 돌려보면 기대했던 바와 같이 vector보다 훨씬 좋은 연관 컨테이너의 검색 속도를 볼 수 있다.

[Vector]
100000 items pushed to vector.
Insertion: 13ms
Searching: 29765ms

[Map]
100000 items pushed to map.
Insertion: 62ms
Searching: 35ms

[Set]
100000 items pushed to set.
Insertion: 62ms
Searching: 36ms

시험에 사용한 전체 코드는 GitHub Gist에 붙여둔다.

Lightsail Ubuntu 20.04 업그레이드 후 ssh 접속 불가 현상

Lightsail의 이미지를 Ubuntu 20.04 LTS로 업그레이드 한 후 web 환경에서 SSH 접속이 되지 않아서 또 망했다며 머리를 쥐어 뜯고 있는데, 우연히, 당연히 안 될 거라고 생각했던 터미널 프로그램을 통한 SSH 접속은 또 되는 기현상을 발견했다. 이 대로도 나쁘진 않지만 좀 찜찜 하기도 하고 해서 좀 더 찾아 보았다.

접속 오류가 발생할 때의 로그를 보면 다음과 같은데,

$ cat /var/log/auth.log|tail
...
sshd[4528]: userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]
...

이 문제의 해결책에 대해 아주 자세히 설명된 Use RSA CA Certificates with OpenSSH 8.2에 따르면, (Ubuntu 20.04에 포함된) OpenSSH 8.2 부터는 보안 문제로 SHA-1 기반인 ssh-rsa가 기본 CA signature 항목에서 빠지면서 이러한 문제가 발생하게 된다고 한다. 해결 방법은 CASignatureAlgorithms에 ssh-rsa를 지원하도록 명시하는 것이다.

$ cat /etc/ssh/sshd_config|tail
...
# Use RSA CA cert.
# https://ibug.io/blog/2020/04/ssh-8.2-rsa-ca/
CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

위의 링크에서 제안하는 대로 sshd_config 파일에 CASignatureAlgorithms 항목을 위와 같이 추가 하고 sshd service를 재 실행 하고나니, web 환경 SSH가 잘 동작하게 되었다. 물론, 터미널도 그대로 잘 된다.