요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
=======================
IRQ-flags state tracing
=======================
:Author: started by Ingo Molnar <[email protected]>
The "irq-flags tracing" feature "traces" hardirq and softirq state, in
that it gives interested subsystems an opportunity to be notified of
every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that
happens in the kernel.
CONFIG_TRACE_IRQFLAGS_SUPPORT is needed for CONFIG_PROVE_SPIN_LOCKING
and CONFIG_PROVE_RW_LOCKING to be offered by the generic lock debugging
code. Otherwise only CONFIG_PROVE_MUTEX_LOCKING and
CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these
are locking APIs that are not used in IRQ context. (the one exception
for rwsems is worked around)
Architecture support for this is certainly not in the "trivial"
category, because lots of lowlevel assembly code deal with irq-flags
state changes. But an architecture can be irq-flags-tracing enabled in a
rather straightforward and risk-free manner.
Architectures that want to support this need to do a couple of
code-organizational changes first:
- add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file
and then a couple of functional changes are needed as well to implement
irq-flags-tracing support:
- in lowlevel entry code add (build-conditional) calls to the
trace_hardirqs_off()/trace_hardirqs_on() functions. The lock validator
closely guards whether the 'real' irq-flags matches the 'virtual'
irq-flags state, and complains loudly (and turns itself off) if the
two do not match. Usually most of the time for arch support for
irq-flags-tracing is spent in this state: look at the lockdep
complaint, try to figure out the assembly code we did not cover yet,
fix and repeat. Once the system has booted up and works without a
lockdep complaint in the irq-flags-tracing functions arch support is
complete.
- if the architecture has non-maskable interrupts then those need to be
excluded from the irq-tracing [and lock validation] mechanism via
lockdep_off()/lockdep_on().
In general there is no risk from having an incomplete irq-flags-tracing
implementation in an architecture: lockdep will detect that and will
turn itself off. I.e. the lock validator will still be reliable. There
should be no crashes due to irq-tracing bugs. (except if the assembly
changes break other code by modifying conditions or registers that
shouldn't be)
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
문서 정보
1-6IRQ-flags 상태 추적 (IRQ-flags state tracing)
저자: Ingo Molnar <[email protected]>가 문서를 시작했습니다.
hardirq와 softirq 상태 추적
7-11"irq-flags tracing" 기능은 hardirq와 softirq 상태를 추적합니다. 즉 커널에서 일어나는 모든 `hardirqs-off`/`hardirqs-on`, `softirqs-off`/`softirqs-on` 이벤트를 관련 subsystem이 통지받을 기회를 제공합니다.
잠금 디버깅 구성과의 관계
12-18generic lock debugging 코드가 `CONFIG_PROVE_SPIN_LOCKING`과 `CONFIG_PROVE_RW_LOCKING`을 제공하려면 `CONFIG_TRACE_IRQFLAGS_SUPPORT`가 필요합니다. 이 옵션이 없으면 해당 아키텍처에는 IRQ context에서 사용하지 않는 잠금 API인 `CONFIG_PROVE_MUTEX_LOCKING`과 `CONFIG_PROVE_RWSEM_LOCKING`만 제공됩니다. rwsem의 한 가지 예외는 별도로 우회 처리됩니다.
아키텍처 지원의 난이도
19-23많은 저수준 assembly 코드가 irq-flags 상태 변경을 다루므로 아키텍처 지원은 결코 단순하지 않습니다. 그래도 비교적 직관적이고 위험이 적은 절차로 아키텍처에 irq-flags tracing을 활성화할 수 있습니다.
코드 구성 변경
24-31지원하려는 아키텍처는 먼저 코드 구성을 바꿔야 합니다.
- 아키텍처 수준 Kconfig 파일에 `TRACE_IRQFLAGS_SUPPORT`를 추가하고 활성화합니다.
그다음 irq-flags tracing을 구현하기 위한 기능 변경이 필요합니다.
저수준 진입 코드와 NMI 처리
32-45- 저수준 진입 코드에 빌드 조건부 `trace_hardirqs_off()`와 `trace_hardirqs_on()` 호출을 추가합니다. lock validator는 실제 irq-flags와 가상 irq-flags 상태가 일치하는지 엄격히 검사하며, 다르면 강한 경고를 내고 스스로 비활성화합니다. 보통 아키텍처 지원 작업은 lockdep 경고를 확인하고 아직 다루지 않은 assembly 코드를 찾아 수정하는 과정을 반복하는 데 대부분의 시간을 씁니다. 시스템이 부팅되고 irq-flags tracing 함수에서 lockdep 경고 없이 동작하면 지원이 완료된 것입니다.
- 아키텍처에 non-maskable interrupt가 있다면 `lockdep_off()`와 `lockdep_on()`을 사용하여 해당 인터럽트를 irq tracing 및 lock validation 메커니즘에서 제외해야 합니다.
불완전한 구현의 안전성
46-52일반적으로 아키텍처의 irq-flags tracing 구현이 불완전해도 위험하지 않습니다. lockdep이 이를 감지하고 스스로 비활성화하므로 lock validator의 결과는 계속 신뢰할 수 있습니다. irq tracing 버그 때문에 시스템이 중단되어서는 안 됩니다. 다만 assembly 변경이 보존해야 할 condition 또는 register를 수정하여 다른 코드를 깨뜨린 경우는 예외입니다.
요약과 해설
irqflags-tracing.rst:1-52IRQ-flags tracing은 hardirq와 softirq가 켜지고 꺼지는 모든 전환을 추적하여 lock validator가 실제 인터럽트 상태와 내부 모델의 상태를 비교할 수 있게 합니다.
아키텍처는 Kconfig 지원 표시와 저수준 진입 코드의 `trace_hardirqs_off/on()` 호출을 함께 구현해야 합니다. NMI처럼 일반 IRQ 추적 모델에 들어오면 안 되는 경로는 `lockdep_off/on()`으로 제외합니다.
상태 전환을 빠뜨리면 lockdep이 불일치를 발견하고 자신을 끄므로 잘못된 잠금 진단을 계속 내지는 않습니다. 실제 위험은 추적 호출을 넣는 assembly 수정이 다른 register나 condition을 손상할 때 발생합니다.