Messages in this thread | | | Date | Sat, 22 Dec 2018 15:03:33 -0800 (PST) | Subject | Re: [PATCH] sock: Make sock->sk_tstamp thread-safe | From | David Miller <> |
| |
From: Deepa Dinamani <deepa.kernel@gmail.com> Date: Fri, 21 Dec 2018 12:27:33 -0800
> Al Viro mentioned that there is probably a race condition > lurking in accesses of sk_tstamp on 32-bit machines. > > sock->sk_tstamp 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_tstamp_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 9115e8cd2a0c ("net: reorganize struct sock for better data > locality") > > Note that all the instances of the sk_tstamp accesses > are either through the ioctl or the syscall recvmsg. > > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Since, regardless of whether this is the final approach we will take, it seems that sunrpc needs to be added to this patch.
So I'm definitely waiting for a new version.
Thanks.
| |