DMA 버퍼는 누가 읽고 쓰고 있습니까?

주소 세 개를 같은 숫자로 생각하면 안 됩니다

드라이버의 void *buf는 CPU가 사용하는 가상 주소입니다. 장치에 넘길 dma_addr_t dma는 장치가 사용하는 DMA 주소입니다. 같은 RAM을 가리켜도 두 값은 다를 수 있습니다. IOMMU가 있으면 DMA 주소에서 물리 주소로 변환하고, 그 밖의 플랫폼에서는 버스의 주소 변환이나 bounce buffer가 관여할 수 있습니다. RAM 용량이 4 GiB라고 해서 물리 주소가 반드시 0부터 4 GiB 직전까지 연속이라는 뜻도 아닙니다.

따라서 virt_to_phys(buf)를 계산해 장치 레지스터에 쓰는 방식으로 DMA API를 대신하지 않습니다. ioremap()은 CPU가 MMIO 레지스터에 접근할 매핑을 만드는 함수입니다. DMA 버퍼를 장치에 등록하는 함수가 아닙니다. CPU 주소와 DMA 주소 SWIOTLB의 bounce buffer

송신 버퍼 하나의 수명을 따라갑니다

아래는 동작 순서를 설명하는 의사 코드입니다. start_tx()와 wait_tx_finished()는 실제 커널 API가 아니라 보드의 드라이버가 구현해야 할 부분입니다. 이 경로가 반환할 버퍼는 DMA API에 적합한 메모리에서 확보했고 장치의 DMA mask도 설정했다고 가정합니다. 매핑 이후에는 전송이 정상 완료되는 경로를 보여 줍니다.

fill_packet(buf, size);
dma = dma_map_single(dev, buf, size, DMA_TO_DEVICE);
if (dma_mapping_error(dev, dma)) {
    release_packet(buf);
    return -EIO;
}
start_tx(dma, size);
wait_tx_finished();
dma_unmap_single(dev, dma, size, DMA_TO_DEVICE);
release_packet(buf);

이 예제는 CPU와 장치가 같은 streaming 버퍼를 동시에 고쳐 쓰지 않게 구성했습니다. 실제 드라이버는 완료 인터럽트, 취소, timeout, 장치 제거 때에도 이 수명이 깨지지 않게 해야 합니다. DMA API의 매핑·동기화 규칙

매핑을 유지하면서 버퍼를 재사용할 수도 있습니다

Streaming은 “한 번만 전송할 수 있는 메모리”라는 뜻이 아닙니다. 매핑을 유지하고 적절히 동기화해 여러 번 사용할 수도 있습니다. Coherent도 “CPU가 읽을 때 장치 작업이 이미 끝나 있다”는 뜻이 아닙니다. cache 일관성과 작업 완료는 서로 다른 조건입니다.

Coherent여도 순서와 완료 확인은 필요합니다

장치가 descriptor의 valid 비트를 보고 일을 시작한다면, 주소와 길이를 먼저 보게 하고 valid를 마지막에 보게 해야 합니다. Coherent 메모리는 cache 관리를 생략할 수 있게 해 주지만, 드라이버가 원하는 여러 메모리 접근의 순서를 모두 대신 정해 주지는 않습니다. dma_wmb() 같은 barrier와 MMIO 접근자 사용 여부는 descriptor·장치 규약을 따라야 합니다. DMA와 MMIO의 ordering

Framebuffer DMA에는 영상 형식 계약이 추가됩니다

AMD Video Framebuffer Read/Write는 일반 DMAEngine descriptor 외에 영상의 메모리 형식을 알아야 합니다. 아래 내용은 linux-xlnx 고정 커밋 235bd5e49f53의 구현을 읽은 사례입니다. 모든 DMA 컨트롤러나 IP 버전에 적용하는 설정법은 아닙니다.

xilinx_xdma_v4l2_config() 또는 xilinx_xdma_drm_config()가 FourCC에 대응하는 형식을 선택합니다. 헤더 계약은 dma_async_issue_pending() 전에 호출하도록 요구하며, 실제 xilinx_frmbuf_dma_prep_interleaved()도 vid_fmt가 없으면 실패합니다. 따라서 이 구현에서는 descriptor 준비 전에 형식을 정해야 합니다. 설정 함수는 void이므로 호출했다는 사실만으로 요청 형식의 지원·적용 성공을 판정하지 않습니다.

선형 두-plane 전송에서는 첫 chroma 주소를 첫 plane 주소에 numf × stride와 방향별 src_icg 또는 dst_icg를 더해 계산합니다. 예를 들어 1,080행, 행 데이터 1,920바이트, 행 padding 128바이트, plane 간격 0이면 chroma 시작은 첫 DMA 주소보다 2,211,840바이트 뒤입니다. 이 계산은 전체 할당 크기나 모든 픽셀 형식의 규칙을 대신하지 않습니다.

callback의 시점과 버퍼 완료는 구별합니다

일반 완료 경로는 active descriptor의 cookie를 완료하고 done_list에 넣은 뒤 cleanup에서 callback을 실행합니다. 그러나 자동 재시작 모드는 staged descriptor를 따로 두며, EARLY_CALLBACK이나 EARLY_CALLBACK_START_DESC는 더 이른 알림을 선택할 수 있습니다. 특히 후자는 주소 레지스터를 쓰기 전에도 callback을 부릅니다. 모드와 callback 계약을 확인하지 않고 그 알림을 CPU의 버퍼 재사용 허가로 해석하지 않습니다. 위의 DMA 매핑·동기화·소유권 조건도 그대로 필요합니다.

V4L2 버퍼 흐름과 DMAEngine client 계약은 별도로 읽습니다. 이 절은 고정 소스의 설명이며 FPGA 전송·영상 출력·cache 동기화를 실기기에서 시험한 결과가 아닙니다.

접근 권한과 fd 수명

DMA 주소가 올바르다는 사실은 프로세스가 그 드라이버나 버퍼에 접근해도 된다는 허가가 아닙니다. 먼저 노드의 존재, 디렉터리 목록 조회, 해당 주체의 open, 열린 fd에서 허용되는 작업을 구분합니다. Android의 Unix 권한과 SELinux domain별 정책은 서로 다른 판단 요소입니다. root 권한이 있다고 SELinux의 강제 접근 통제가 없어지는 것도 아닙니다. AOSP의 SELinux 설명

Project Zero의 2024년 조사는 특정 기기에서 디렉터리를 열람할 수 없어도 알려진 노드의 경로에는 접근할 수 있는 경우와, 허용된 서비스가 fd를 전달하는 별도 접근 경로를 설명합니다. 이는 조사 대상 기기·정책의 사례이지 현재 모든 Android 기기의 권한표가 아닙니다. open 성공이나 fd 수신만으로 임의의 ioctl·mmap까지 모두 허용됐다고 판단하지 않습니다.

Linux v6.18.37의 dma_buf_get(fd)는 fget()으로 file 참조를 얻고 dma-buf 파일인지 검사합니다. dma_buf_put()은 해당 file에 fput()을 적용합니다. fd 번호, struct file, struct dma_buf, 장치 attachment와 DMA mapping은 같은 객체가 아닙니다. 다른 참조가 남아 있다면 한 fd를 닫는 것만으로 버퍼 수명이 끝났다고 볼 수 없습니다.

일반적인 importer의 사용 종료는 장치의 버퍼 사용이 끝난 뒤 mapping을 정리하고 dma_buf_detach()를 호출한 다음, 얻어 둔 참조를 dma_buf_put()으로 반환하는 식으로 각 성공한 단계와 짝을 맞춥니다. 실패·취소·동시 접근 경로도 같은 수명 조건을 지켜야 합니다. 참조 계수는 앞서 설명한 DMA 완료 확인과 CPU cache 동기화를 대신하지 않습니다. 기본 수명 계약 · get/put 구현

FD_CLOEXEC는 exec로 새 프로그램을 실행할 때 fd가 의도치 않게 남는 것을 막는 조건입니다. fork 직후 fd를 자동으로 닫는 옵션은 아닙니다. 생성과 별도의 fcntl() 사이에는 다른 스레드의 exec와 경쟁할 틈이 있으므로, dma-buf 문서는 fd 생성 API가 O_CLOEXEC를 원자적으로 지정할 수 있어야 한다고 설명합니다. 이것만으로 이미 전달한 fd의 사용 권한이나 모든 참조를 회수하는 것은 아닙니다. dma-buf userspace 계약

일반 fd 전달 원리는 SCM_RIGHTS의 file 참조 설명, 장치 접근 정책은 HAL의 권한 구분과 연결해 읽습니다. 위 Linux API를 과거 벤더 드라이버의 특정 결함과 같은 구현으로 취급하지 않습니다. 이 절은 방어적 소스·권한 모델 설명이며, 실제 기기 접근·취약점 재현이나 정책 변경을 수행한 결과가 아닙니다.

이어서 읽기

• DMA와 IOMMU 기존 분석
• 펌웨어와 공유하는 메모리

Coherent라는 계약이 항상 uncached라는 뜻은 아닙니다

dma_alloc_coherent()의 핵심은 CPU와 장치 사이의 가시성 계약입니다. 모든 아키텍처에서 반드시 uncached 매핑을 만들거나 set_memory_uc()를 호출한다는 뜻은 아닙니다. 하드웨어 일관성 지원과 플랫폼 구현에 따라 달라지므로 드라이버가 특정 CPU의 캐시 명령이나 내부 구현을 일반 규칙으로 대신하지 않습니다.

Streaming mapping은 최초 map과 마지막 unmap이 소유권 전환에 필요한 처리를 포함합니다. 매핑을 유지한 채 CPU가 다시 버퍼를 만질 때는 장치 완료를 먼저 확인하고 해당 방향·범위의 dma_sync_*_for_cpu() 계약을 따릅니다. 장치에 다시 넘길 때는 dma_sync_*_for_device()가 대응합니다. coherent 플랫폼에서 일부 sync가 별도 캐시 명령을 내지 않더라도 공통 API의 의미가 사라지는 것은 아닙니다.

캐시 가시성, descriptor 게시 순서, DMA 완료는 서로 다른 조건입니다. 앞의 barrier와 소유권 절차가 여전히 필요합니다. 기준: Linux Dynamic DMA mapping Guide. 특정 CPU에서 모든 map이 cache flush라는 주장이나 실제 장치 측정은 포함하지 않습니다.

English summary. Coherent is an API visibility contract, not a universal uncached-memory implementation. Streaming reuse must respect CPU/device ownership and sync rules. Cache visibility does not replace publication barriers or completion checks.