drivers/staging/rtl8723bs 드라이버쪽을 최근에 기웃기웃 보고있다.
그러던 중
race contition 해결 패치
void expire_timeout_chk(struct adapter *padapter)
{
struct list_head *phead, *plist, *tmp;
u8 updated = false;
struct sta_info *psta = NULL;
struct sta_priv *pstapriv = &padapter->stapriv;
u8 chk_alive_num = 0;
char chk_alive_list[NUM_STA];
int i;
spin_lock_bh(&pstapriv->auth_list_lock);
phead = &pstapriv->auth_list;
/* check auth_queue */
list_for_each_safe(plist, tmp, phead) {
psta = list_entry(plist, struct sta_info, auth_list);
if (psta->expire_to > 0) {
psta->expire_to--;
if (psta->expire_to == 0) {
list_del_init(&psta->auth_list);
pstapriv->auth_list_cnt--;
spin_unlock_bh(&pstapriv->auth_list_lock);
rtw_free_stainfo(padapter, psta);
spin_lock_bh(&pstapriv->auth_list_lock);
}
}
}
spin_unlock_bh(&pstapriv->auth_list_lock);
psta = NULL;
해당 코드를 발견하게 되었는데,
여기서 주의깊게 본 부분은,
24~28 줄 사이의 부분이다.
- spin_unlock_bh(&pstapriv->auth_list_lock);
- rtw_free_stainfo(padapter, psta);
- spin_lock_bh(&pstapriv->auth_list_lock);
이 코드에서는, 연결리스트를 순회하는 도중에,
스핀락을 unlock한다음, free stainfo (아마도 자원 해제)를 하고,
다시 락을 건다.
그리고 이 행동을 loop를 반복하면서 한다. (list_for_each_safe)
그렇다면 여기서 약간의 문제의식을 가지게되는데,
만약, '잠깐 unlock을 해서 free stainfo를 하는 도중에 다른 코드에서 자원에 접근한다면??'
명백히 문제가 생길것...

따라서 코드를 다음과 같이 변경했다.
기존의, 루프 내부에서 락을 풀고 자원해제하고 다시 락을 거는 코드를 지워버렸다.
그대신,
자원해제를 할 것들을 다른 리스트로 옮긴 후,
따로 free하는 방향으로 정했다.
이 과정에서, Dan Carpenter에게 리뷰를 받았고,
처음엔, list_for_each_safe를 사용했다가, list_for_each_entry_safe로 교체했다.
(Reviewed-by: Dan Carpenter)
https://lore.kernel.org/linux-staging/20260131171153.3729458-1-s9430939@naver.com/
race condition 해결 패치2
drivers/most/video 코드에서도 비슷한 패턴을 발견했다.


이렇게 수정했다.
이것도 원래는 flist_for_each_entry_safe로 하나하나 로컬 리스트로 옮기던 행위를,
list_replace_init으로 한번에 옮기는 방식을 사용했다.
(Reviewed-by: Dan Carpenter)
https://lore.kernel.org/linux-staging/aYMS_9xQ4LGgMS-j@stanley.mountain/T/#t
'Linux > start_contribute()' 카테고리의 다른 글
| 커널 기여 근황 (0) | 2026.01.27 |
|---|---|
| 리눅스 커널 2번째 기여: 수동 메모리 정렬 연산 PTR_ALIGN으로 최적화 (2) | 2026.01.12 |
| 첫 리눅스 커널 기여 (4) | 2025.12.22 |