Date: Fri, 25 Oct 2019 13:24:19 -0400 From: Dheeraj Kandula <dkandula@gmail.com> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: soisconnected. Message-ID: <CA%2BqNgxTW6F8FPAVu0VRW-hViLcVuBT4_wgBbYtudqPhS=Rx9=g@mail.gmail.com> In-Reply-To: <20191025161537.GB67949@raichu> References: <CA%2BqNgxRPq0mU268-_F_ZRJG3S%2Bmp-pDWg550DwyALjMDiWYzQQ@mail.gmail.com> <20191025161537.GB67949@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Mark for the clarification. Dheeraj On Fri, Oct 25, 2019 at 12:15 PM Mark Johnston <markj@freebsd.org> wrote: > 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?CA%2BqNgxTW6F8FPAVu0VRW-hViLcVuBT4_wgBbYtudqPhS=Rx9=g>