Wang Hai wrote on Thu, Nov 24, 2022 at 04:10:05PM +0800:
> Both p9_fd_create_tcp() and p9_fd_create_unix() will call
> p9_socket_open(). If the creation of p9_trans_fd fails,
> p9_fd_create_tcp() and p9_fd_create_unix() will return an
> error directly instead of releasing the cscoket, which will
(typo, socket or csocket -- I'll fix this on applying)
> result in a socket leak.
>
> This patch adds sock_release() to fix the leak issue.
Thanks, it looks good to me.
A bit confusing that sock_alloc_files() calls sock_release() itself on
failure, but that means this one's safe at least...
> Fixes: 6b18662e239a ("9p connect fixes")
(the leak was present before that commit so I guess that's not really
correct -- but it might help figure out up to which point stable folks
will be able to backport so I guess it's useful either way)
--
Dominique
On Thu, Nov 24, 2022 at 06:15:54PM +0900, [email protected] wrote:
> Wang Hai wrote on Thu, Nov 24, 2022 at 04:10:05PM +0800:
> > Both p9_fd_create_tcp() and p9_fd_create_unix() will call
> > p9_socket_open(). If the creation of p9_trans_fd fails,
> > p9_fd_create_tcp() and p9_fd_create_unix() will return an
> > error directly instead of releasing the cscoket, which will
>
> (typo, socket or csocket -- I'll fix this on applying)
>
> > result in a socket leak.
> >
> > This patch adds sock_release() to fix the leak issue.
>
> Thanks, it looks good to me.
> A bit confusing that sock_alloc_files() calls sock_release() itself on
> failure, but that means this one's safe at least...
sock_alloc_file() unconditionally consumes socket reference;
either it is transferred to new struct file it returns, or
it's dropped. Makes for simpler logics in callers...
FWIW,
ACKed-by: Al Viro <[email protected]>
on the leak fix.