Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Oct 2019 12:15:37 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        Dheeraj Kandula <dkandula@gmail.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: soisconnected.
Message-ID:  <20191025161537.GB67949@raichu>
In-Reply-To: <CA%2BqNgxRPq0mU268-_F_ZRJG3S%2Bmp-pDWg550DwyALjMDiWYzQQ@mail.gmail.com>
References:  <CA%2BqNgxRPq0mU268-_F_ZRJG3S%2Bmp-pDWg550DwyALjMDiWYzQQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 25, 2019 at 11:36:53AM -0400, Dheeraj Kandula wrote:
> Hi Mark,
>        I am trying to understand the purpose of certain code in
> soisconnected.

+freebsd-net

> 1. When an upcall returns SO_ISCONNECTED, the sockbuf's lock is unlocked
> and then soisconnected is invoked. This is done in order to avoid a lock
> order reversal as SOCK_LOCK is grabbed at the beginning of soisconnected.
> Isn't it?

Note, it is SU_ISCONNECTED, not SO_ISCONNECTED.

Yes, I believe that is true.  The socket lock comes first in the lock
order.

> 2. When an upcall returns SO_ISCONNECTED, the receive socket buffer's
> upcall on the "so" socket is cleared. The upcall that is cleared is the
> accept filter upcall that is set in soisconnected in the "else" part on
> line 3849 of release head in file uipc_socket.c. I am not sure why we do
> this. Even if it is set, the solisten_wakeup is called on the head socket
> which is a listen socket and not the "so" socket in soisconnected. Is this
> a remnant from old code?

Once the accept filter has accepted the connection by returning
SU_ISCONNECTED, it has no more work to do, so we should clear the
upcall.  Otherwise it would be invoked each time the socket buffer
receives new data, but the accept filter's purpose is only to identify
valid requests.

The listening socket upcall is not used by accept filters.  It is used
by callers of solisten_upcall_set(), of which there are several in the
tree.

> 3. When an upcall returns SU_OK in the same "else" code block, the receive
> socket buffer's upcall is not cleared. Is it fine to have this set when the
> function soisconnected returns. I think the answer to question 2 above will
> answer this too.

Yes.  Note that if the accept filter returns SU_ISCONNECTED, we goto
again, which moves the receive socket from the listening socket's
incomplete list to the complete list, which allows the new socket to
be returned to userspace.  Otherwise, if the filter returns SU_OK, it
means that the filter needs to see more data before determining whether
to accept the connection.  When more data arrives in the receive buffer,
sowakeup() will be called, and the accept filter upcall will be called
again.  If it returns SU_ISCONNECTED, we then call soisconnected()
again, which will migrate the receive socket to so_comp.

Actually, it is kind of strange that the second call to soisconnected()
will call the accept filter again.  I guess there is no other convenient
place to clear SO_ACCEPTFILTER.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191025161537.GB67949>