netdev - Re: [PATCH net-next] sock: avoid dirtying sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1490881940.24891.66.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Thu, 30 Mar 2017 06:52:20 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next] sock: avoid dirtying sk_stamp, if possible

On Thu, 2017-03-30 at 14:03 +0200, Paolo Abeni wrote:
> sock_recv_ts_and_drops() unconditionally set sk->sk_stamp for
> every packet, even if the SOCK_TIMESTAMP flag is not set in the
> related socket.
> If selinux is enabled, this cause a cache miss for every packet
> since sk->sk_stamp and sk->sk_security share the same cacheline.
> With this change sk_stamp is set only if the SOCK_TIMESTAMP
> flag is set, and is cleared for the first packet, so that the user
> perceived behavior is unchanged.
> 
> This gives up to 5% speed-up under udp-flood with small packets.
> 
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
> ---
>  include/net/sock.h | 5 ++++-
>  net/core/sock.c    | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/sock.h b/include/net/sock.h
> index cb241a0..8e53158 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2239,6 +2239,7 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
>  void __sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
>  			      struct sk_buff *skb);
>  
> +#define SK_DEFAULT_STAMP (-1L * NSEC_PER_SEC)
>  static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
>  					  struct sk_buff *skb)
>  {
> @@ -2249,8 +2250,10 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
>  
>  	if (sk->sk_flags & FLAGS_TS_OR_DROPS || sk->sk_tsflags & TSFLAGS_ANY)
>  		__sock_recv_ts_and_drops(msg, sk, skb);
> -	else
> +	else if (unlikely(sk->sk_flags & SOCK_TIMESTAMP))
>  		sk->sk_stamp = skb->tstamp;
> +	else if (unlikely(sk->sk_stamp == SK_DEFAULT_STAMP))
> +		sk->sk_stamp = 0;
>  }
>  

This looks very nice, but why using 0 here instead of skb->tstamp ?

This might give some regression on applications reading their first
socket timestamp in some contexts.

What about 

if (sk->sk_flags & FLAGS_TS_OR_DROPS || sk->sk_tsflags & TSFLAGS_ANY)
	__sock_recv_ts_and_drops(msg, sk, skb);
else if (unlikely(sk->sk_flags & SOCK_TIMESTAMP ||
                  sk->sk_stamp == SK_DEFAULT_STAMP))
	sk->sk_stamp = skb->tstamp;