[리눅스커널] 프로세스 별로 파일 디스크립터(파일 객체)는 어떻게 관리하나?
Post
원문 보기 →[리눅스커널] 프로세스 별로 파일 디스크립터(파일 객체)는 어떻게 관리하나?
아래 포스팅을 읽은 방문자님께서 댓글로 남겨 주신 질문에 대답하려고 합니다. [리눅스커널][가상파일시스템] 파일 객체: write 연산 세부 동작 분석 질문 서로 다른 프로세스에서 f1파일을 열었으니 fd가 가르키는 시스템 파일 테이블의 파일이 다를텐데어떻게 내용이 삭제되거나 섞이지도 않는지 알수 있을까요? 답신 사실 이 부분은 커널을 디버깅해봐야 알 수 있는 내용입니다. 커널 디버깅 툴 중 많이 사용되는 크래시 유틸리티로 이 내용을 확인해보겠습니다. 다음은 프로세스가 저장하고 있는 파일 디스크립터 목록을 출력해주는 'files 1' 명령어를 입력한 결과입니다. crash> files 1PID: 1 TASK: cf930f40 CPU: 0 COMMAND: "systemd"ROO
Related Posts
3 posts리눅스 커널, 드디어 6.0 버전대 시대로 진입
며칠 지난 소식이지만, 새로운 10월의 시작과 함께 하듯이 10월 2일 리눅스 커널의 6.0 릴리즈가 등장했습니다. 기존 안정 버전 5.19 버전대에서 6.0 대에서 한 번에 올라왔지만, 메이저 버전업에 기대하는 천지개벽 같은 요소는 그리 없습니다. 버전을 6.0으로 올린 것도 5.19에서 5.20으로 가기에는 서브 버전이 좀 숫자가 크다... 고 해서 올린 의미 정도이니까요. 하지만 지속적으로 진행 중인 변화의 폭 자체는 그리 작지 않습니다. 이번 커널 6.0에서도 최신 하드웨어들에 대한 지원들이 추가되었습니다. 프로세서에서는 3세대 제온 스케일러블 ''아이스 레이크''나 AMD 라이젠 쓰레드리퍼, AMD 에픽 프로세서 등에서의 성능 최적화 등이 적용되었고, 인텔의 차세대 프로세서가 될 4세대 제온 스케일러
[리눅스커널] IPI(Inter Processor Interrupt) Call 요청 루틴(하이 레벨 뷰)
IPI(Inter Processor Interrupt)의 약자로 지정한 CPU 코어를 타겟으로 인터럽트(소프트웨어적)를 유발하는 매커니즘입니다. 이번 포스트에서는 리눅스 커널에서 IPI Call을 요청하는 루틴을 리뷰하겠습니다. IPI Call은 아키텍처에 의존적으로 처리되므로 하이 레벨과 로우 레벨로 코드가 구현돼 있습니다. * High Level 코드 위치 kernel/sched/core.c kernel/smp.c kernel/irq/ipi.c * Low Level (Arm 아키텍처) 코드 위치 arch/arm64/kernel/smp.c drivers/irqchip/irq-gic-v3.c IPI Call 요청 루틴(하이 레벨) 아래 함수는 Qualcomm Watchdog
[커널크래시] 인터럽트 컨텍스트에서 wake_up_interruptible 대신 wake_up_locked 사용
인터럽트 컨텍스트에서 슬립을 지원하는 커널 함수를 호출하면 어떻게 동작할까요? 커널 패닉이 유발됩니다.이번에는 인터럽트 컨텍스트에서 발생한 커널 패닉 이슈를 소개합니다. 먼저 커널 로그를 소개합니다. [1.538173] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:973[1.577234] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/3[1.578316] Preemption disabled at:[1.597859] CPU: 3 PID: 0 Comm: swapper/3 [1.617377] Hardware name: rpi[1.6
![[CV] [Comi] 'ファイブスター物語'(더 파이브 스타 스토리즈) 19권. 연재분에서 벌어지는 '검성 대 검성'](https://img.zoomtrend.com/2026/06/06/1780766083-ECB2ABEB93B1EC9EA5EB8DB0ECBD94EC8AA4.jpg)