Linux 6.18 KASAN·ftrace 문서

커널 오류 로그에서 원인과 결과를 구분합니다

KASAN 보고, fault 주소, stack trace와 ftrace의 시간을 서로 다른 증거로 읽습니다.

마지막으로 멈춘 함수가 최초 원인인 것은 아닙니다

잘못된 포인터를 구조체에 저장한 뒤 한참 지나 다른 함수가 그 값을 읽다가 fault가 날 수 있습니다. 따라서 현재 PC의 함수만 고치면 앞선 메모리 손상을 놓칠 수 있습니다. 부팅부터 발생 직전까지의 첫 경고, allocator 보고, 종료·재사용 경로를 함께 봐야 합니다.

로그의 정보알 수 있는 것그것만으로 단정할 수 없는 것
PC / RIP예외·보고 시점의 명령 위치그 함수가 최초로 메모리를 망가뜨렸다는 결론
LR / return address연결된 호출·복귀 위치의 단서전체 call stack이 완전하고 손상되지 않았다는 보장
fault address실패한 접근 주소의 단서항상 코드 실행 주소와 같은 값이라는 결론
stack trace해당 시점의 호출 경로 단서모든 CPU에서 앞서 일어난 이벤트의 시간 순서

symbol을 풀 때에는 실제 사용한 vmlinux·module·빌드 설정과 맞춰야 합니다. 최적화·inlining·KASLR·module 적재 주소를 고려하지 않고 다른 빌드의 주소를 소스 줄에 대입하면 잘못된 위치를 지목할 수 있습니다. 커널 오류 위치 조사

CONFIG 이름이 선택하는 검사 범위도 읽습니다

#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
    /* 이 빌드에서 stack 검사와 관련된 코드가 포함됩니다. */
#endif

이 예에서 CONFIG_KASAN은 커널의 메모리 오류 검사 기능 설정이고 CONFIG_KASAN_STACK은 해당 빌드의 stack instrumentation 관련 설정입니다. 두 매크로가 정의됐는지는 전처리 단계의 판단입니다. CPU가 실행 중 현재 stack이 안전한지 이 #if로 검사하는 것이 아닙니다. v6.18.37에서 KASAN_STACK은 KASAN_GENERIC 또는 KASAN_SW_TAGS에 의존합니다. hardware tag 방식의 지원 범위와 별도로 읽어야 합니다.

KASAN에는 generic, software tag, hardware tag 방식이 있고 지원 아키텍처·메모리 영역·비용이 다릅니다. ARM64의 hardware tag 방식은 MTE 지원을 사용합니다. “KASAN을 켰으므로 모든 메모리와 모든 접근을 같은 방식으로 검사한다”고 읽으면 안 됩니다. KASAN mode와 지원 범위 KASAN_STACK의 설정 조건

보고에서 찾을 부분읽는 방법
오류 종류와 접근 크기범위 밖 접근인지 해제 후 접근인지, read인지 write인지부터 구분합니다.
잘못된 접근의 stack오류가 드러난 소비 경로를 봅니다.
할당·해제 stack그 객체를 누가 만들고 언제 수명을 끝냈는지 봅니다.
객체 내부 offset정상 객체 경계와 잘못 접근한 위치를 비교합니다.

ftrace는 시간 관계를 좁히는 도구입니다

한 번의 요청이 오래 걸리는 원인을 추적하는 예
  1. 요청 제출

    요청 번호와 시점을 기록합니다.

    queue에 들어간 시점을 확인합니다.

  2. 실행 시작

    worker·thread가 실제 CPU에서 시작한 시점을 봅니다.

    작업 중 대기 구간을 확인합니다.

  3. 장치 또는 상대의 완료

    interrupt·callback·reply 시점과 연결합니다.

    소비자가 결과를 받는 시점을 확인합니다.

  4. 응답

    전체 latency를 계산하고 어느 구간이 긴지 나눕니다.

화살표는 한 요청의 인과 관계입니다. trace의 모든 줄이 서로 같은 요청이라는 뜻은 아니므로 식별자·CPU·task 정보를 함께 봅니다.

현대 Linux에서는 tracefs를 통해 tracing 인터페이스를 제공하며 보통 /sys/kernel/tracing을 사용합니다. 예전 글의 /sys/kernel/debug/tracing 경로도 구성에 따라 보이지만 debugfs 하나만 외워 모든 시스템에 적용하지 않습니다. trace 설정과 기록은 성능에 영향을 줄 수 있으므로 필요한 event·filter·구간으로 범위를 좁혀야 합니다. ftrace와 tracefs

재현 조건과 증거를 함께 남깁니다

  • kernel commit·설정·toolchain과 사용한 firmware 버전을 기록합니다.
  • 최초 오류 로그와 뒤따르는 오류를 시간 순서로 보존합니다.
  • 정상 경로와 실패 경로의 요청·응답·취소·remove 순서를 비교합니다.
  • KASAN·lockdep·ftrace 등 도구가 검출한 사실과 원인 추정을 나누어 적습니다.
  • 수정 후에는 같은 재현 조건에서 원래 오류와 종료·timeout 경로까지 확인합니다.

보고에 함수 이름이 있다는 이유로 코드를 지우거나 delay를 넣는 것으로 끝내지 않습니다. 어떤 상태가 먼저 준비돼야 하고 누가 그 상태의 수명을 끝내는지 설명할 수 있어야 합니다.