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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 25 Feb 2020 11:07:51 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     Paolo Abeni <pabeni@...hat.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 24.02.2020 13:15, Paolo Abeni wrote:
> 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.

The first option looks the best in my opinion.

Kirill