From: Deepa Dinamani deepa.kernel@gmail.com Date: Thu, 27 Dec 2018 18:55:09 -0800
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 9115e8cd2a0c ("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: Deepa Dinamani deepa.kernel@gmail.com
Ok, I'm fine with this, so applied and queued up for -stable.
I will note in passing that there are several 32-bit architectures that have 64-bit loads. Sparc is one such case. And they would not need these changes.
But I don't think it's practical or worthwhile to add that level of consideration into your changes. I'd rather the commit stay as simple as possible.
Thanks!