Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Dec 2012 13:49:38 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Richard Sharpe <rsharpe@richardsharpe.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Possible obscure socket leak when system under load and listener is slow to accept
Message-ID:  <CAJ-Vmok2R2mfwno%2BZ%2BsSzukCNDyjh78BrXLJua3WfOp0R%2BLLHQ@mail.gmail.com>
In-Reply-To: <1354990425.6752.10.camel@localhost.localdomain>
References:  <1354990425.6752.10.camel@localhost.localdomain>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

If this is a real leak, please file a PR so it doesn't get lost.
*cough* let me rephrase that - so the eager PR beavers can keep
chasing it iup.

But, wow. Nice catch!



Adrian


On 8 December 2012 10:13, Richard Sharpe <rsharpe@richardsharpe.com> wrote:
> Hi folks,
>
> Our QA group (at xxx) using Samba and smbtorture has been seeing a
> lot of cases where accept returns ECONNABORTED because the system load
> is high and Samba has a large listen backlog.
>
> Every now and then we get a crash in smbd or in winbindd and winbindd
> complains of too many open files in the system.
>
> In looking at kern_accept, it seems to me that FreeBSD can leak a socket
> when kern_accept calls soaccept on it but gets ECONNABORTED. This error
> is the only error returned from tcp_usr_accept.
>
> It seems like the socket taken off so_comp is never freed in this case
> and that there has been a call on soref on it as well, so that something
> like the following is needed in the error path:
>
> ==== //some-path/freebsd/sys/kern/uipc_syscalls.c#1
> - /home/rsharpe/dev-src/packages/freebsd/sys/kern/uipc_syscalls.c ====
> @@ -433,6 +433,14 @@
>                  */
>                 if (name)
>                         *namelen = 0;
> +               /*
> +                * We need to close the socket we unlinked
> +                * so we do not leak it.
> +                */
> +               ACCEPT_LOCK();
> +               SOCK_LOCK(so);
> +               soclose(so);
>                 goto noconnection;
>         }
>         if (sa == NULL) {
>
> I think an soclose is needed at this point because soisconnected has
> been called on the socket.
>
> Do you think this analysis is reasonable?
>
> We are using FreeBSD 8.0 but it seems the same is true for 9.0. However,
> maybe I am wrong since I am not sure if the fdclose call would free the
> socket, but a quick look suggested that it doesn't.
>
>  I would appreciate your feedback.
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok2R2mfwno%2BZ%2BsSzukCNDyjh78BrXLJua3WfOp0R%2BLLHQ>