• Deepa Dinamani's avatar
    sock: Make sock->sk_stamp thread-safe · 3a0ed3e9
    Deepa Dinamani authored
    Al Viro mentioned (Message-ID
    <20170626041334.GZ10672@ZenIV.linux.org.uk>)
    that there is probably a race condition
    lurking in accesses of sk_stamp on 32-bit machines.
    
    sock->sk_stamp is of type ktime_t which is always an s64.
    On a 32 bit architecture, we might run into situations of
    unsafe access as the access to the field becomes non atomic.
    
    Use seqlocks for synchronization.
    This allows us to avoid using spinlocks for readers as
    readers do not need mutual exclusion.
    
    Another approach to solve this is to require sk_lock for all
    modifications of the timestamps. The current approach allows
    for timestamps to have their own lock: sk_stamp_lock.
    This allows for the patch to not compete with already
    existing critical sections, and side effects are limited
    to the paths in the patch.
    
    The addition of the new field maintains the data locality
    optimizations from
    commit 9115e8cd ("net: reorganize struct sock for better data
    locality")
    
    Note that all the instances of the sk_stamp accesses
    are either through the ioctl or the syscall recvmsg.
    Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    3a0ed3e9
sock.c 82.4 KB