lkml.org 
[lkml]   [2017]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectPossible race in hysdn.ko
    Date
    Hello.

    While searching for races in the Linux kernel I've come across
    "drivers/isdn/hysdn/hysdn.ko" module. Here is a question that I came up
    with while analysing results. Lines are given using the info from Linux
    v4.12.

    In hysdn_proclog.c file in put_log_buffer function a non-standard type
    of synchronization is employed. It uses pd->del_lock as some kind of
    semaphore (hysdn_proclog.c: lines 129 and 143). Consider the following
    case:

    Thread 1: Thread 2:
    hysdn_log_write
    -> hysdn_add_log
    -> put_log_buffer
    spin_lock() hysdn_conf_open
    i = pd->del_lock++ -> hysdn_add_log
    spin_unlock() -> put_log_buffer
    if (!i) <delete-loop> spin_lock()
    pd->del_lock-- i = pd->del_lock++
    spin_unlock()
    if (!i) <delete-loop>
    pd->del_lock--

    <delete-loop> - the loop that deletes unused buffer entries
    (hysdn_proclog.c: lines 134-142).
    pd->del_lock-- is not an atomic operation and is executed without any
    locks. Thus it may interfere in the increment process of pd->del_lock in
    another thread. There may be cases that lead to the inability of any
    thread going through the <delete-loop>.

    I see several possible solutions to this problem:
    1) move the <delete-loop> under the spin_lock and delete
    pd->del_lock synchronization;
    2) wrap pd->del_lock-- with spin_lock protection.

    What do you think should be done about it?

    Thank you for your time.

    \
     
     \ /
      Last update: 2017-07-27 18:19    [W:2.907 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site