netdev - Re: [PATCH net-next v2 2/2] unix: Show number of pending scm files of receive queue in fdinfo

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-next>] [day] [month] [year] [list]

Message-ID: <2c18fad07d0e303557185aa760ba37688191eaa3.camel@redhat.com>
Date:   Mon, 24 Feb 2020 11:15:02 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Kirill Tkhai <ktkhai@...tuozzo.com>, netdev@...r.kernel.org
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH net-next v2 2/2] unix: Show number of pending scm files
 of receive queue in fdinfo

Hi,

On Mon, 2019-12-09 at 10:03 +0000, Kirill Tkhai wrote:
> diff --git a/include/net/af_unix.h b/include/net/af_unix.h
> index 3426d6dacc45..17e10fba2152 100644
> --- a/include/net/af_unix.h
> +++ b/include/net/af_unix.h
> @@ -41,6 +41,10 @@ struct unix_skb_parms {
>  	u32			consumed;
>  } __randomize_layout;
>  
> +struct scm_stat {
> +	u32 nr_fds;
> +};
> +

I'd like to drop the 'destructor' argument from
__skb_try_recv_datagram() and friends - that will both clean-up the
datagram code a bit and will avoid an indirect call in fast-path.

unix_dgram_recvmsg() needs special care: with the proposed change
scm_stat_del() will be called explicitly after _skb_try_recv_datagram()
while 'nr_fds' must to be updated under the receive queue lock.

Any of the following should work:
- change 'nr_fds' to an atomic type, and drop all lockdep stuff
- acquire again the receive queue spinlock before calling
scm_stat_del(), ev doing that only 'if UNIXCB(skb).fp'
- open code a variant of __skb_try_recv_datagram() which will take care
of scm_stat_del() under the receive queue lock.

Do you have any preferences? If you don't plan to add more fields to
'struct scm_stat' I would go for the first option.

Thanks!

Paolo