netdev - Re: [RFC] coallocating struct socket and struct socket

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

Date:   Thu, 21 Feb 2019 14:38:34 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     netdev@...r.kernel.org
Subject: Re: [RFC] coallocating struct socket and struct socket_wq

On Thu, Feb 21, 2019 at 08:15:23AM +0000, Al Viro wrote:
> 	All instances of struct socket are embedded into some
> bigger structure - most into struct socket_alloc (with struct inode
> following struct socket), some into struct tun_file or struct
> tap_queue.
> 
> 	In the last two cases the corresponding struct socket_wq
> (the one whose address goes into socket->wq) is in the same
> containing structure, right after struct socket.
> 
> 	In case of struct socket_alloc, we allocate struct
> socket_wq separately and set socket->wq before anyone sees
> either (in sock_alloc_inode()).  In sock_destroy_inode()
> they are both freed (struct sock_alloc immediately,
> struct socket_wq - RCU-delayed).
> 
> 	AFAICS, nothing ever reassigns socket->wq.  Could we
> simply embed struct socket_wq into struct socket?  RCU delay
> is not an issue - net/socket.c is non-modular, so call_rcu()-based
> variant freeing both together is not horrible.  sock_alloc_inode()
> would be simplified, tun/tap uses would simply lose the separate
> socket_wq members.
> 
> 	The only problem I see here is ____cacheline_aligned_in_smp
> we have on struct socket_wq.  Could we simply make it the first
> field in struct socket?  Without lockdep they are reasonably small -
> on amd64 socket_wq is 64 bytes, while the rest of struct socket is
> 48 (and pointer to wq would obviously disappear).
> 
> 	Or is there something subtle I'm missing here?

Put it another way, what was the reason for "net: sock_def_readable()
and friends RCU conversion" not to put RCU delay into freeing of
struct socket itself?  Separating the write-often fields from
mostly read-only ones?  I hadn't been able to find in archives
the discussion from back in 2010, unfortunately ;-/