On Sat, Dec 22, 2018 at 11:31 PM Eric Dumazet wrote:
>
>
>
> On 12/21/2018 12:27 PM, Deepa Dinamani wrote:
> > 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.
> > O
On 12/21/2018 12:27 PM, Deepa Dinamani wrote:
> 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 ac
From: Deepa Dinamani
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
On 12/21/18, Deepa Dinamani wrote:
> diff --git a/include/net/sock.h b/include/net/sock.h
> index fe58aec00d09..2cb641606533 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2311,8 +2313,11 @@ sock_recv_timestamp(struct msghdr *msg, struct sock
> *sk, struct sk_buff *skb)
>
> Are we actually worried about concurrent writers here? I thought the
> only problem was a race between writer and reader, which would mean
> that we could solve it using only a seqcount_t which is cheaper to
> update than a seqlock_t.
I considered using just the seqcount_t. But, I think we do ca
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 seql
