On Mon, Feb 11, 2019 at 08:55:33AM -0700, Jonathan Corbet wrote:
> On Thu, 7 Feb 2019 11:45:40 -0700
> Jens Axboe <[email protected]> wrote:
>
> > > OK, braindump time:
> >
> > [snip]
> >
> > This is great info, and I think it belongs in Documentation/ somewhere.
> > Not sure I've ever seen such a good and detailed dump of this before.
>
> I suspect I might be able to make something like that happen :) Stay
> tuned.
There are several typos I see in there (e.g. in
* struct file instances A and B being AF_UNIX sockets.
* A is a listener
* B is an established connection, with the other end
yet to be accepted on A
* the only references to A and B are in an SCM_RIGHTS
datagram sent over by A.
the last line should be "datagram sent over by B", of course - you can't
send anything over a listener socket, to start with).
Another thing is this:
* references cannot be extracted from SCM_RIGHTS datagrams
while the garbage collector is running (achieved by having
unix_notinflight() done before references out of SCM_RIGHTS)
* removal of SCM_RIGHTS associated with a socket can't
be done without a reference to that socket _outside_ of any
SCM_RIGHTS (automatically true).
That's worse than a typo - that's an actual bug (see the subthread
with Miklos). Correct version would be
* any references extracted from SCM_RIGHTS during the
garbage collector run will not be actually used until the end
of garbage collection. For normal recvmsg() it is guaranteed
by having unix_notinflight() called between the extraction of
scm_fp_list from the packet and doing anything else with the
references extracted. For MSG_PEEK recvmsg() it's actually
broken and lacks synchronization; Miklos has proposed to grab
and release unix_gc_lock in those, between scm_fp_dup() and
doing anything else with the references copied.
If you turn that thing into a coherent text, I'd appreciate a chance
to take a look at the result and see if anything else needs to be
corrected...
