Re: [PATCH v7 21/27] udp: Handle "spliced" datagrams with per-flow sockets

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 11 Jul 2024 11:30:52 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Wed, Jul 10, 2024 at 07:13:26PM +0200, Stefano Brivio wrote:
> > On Wed, 10 Jul 2024 10:23:14 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Wed, Jul 10, 2024 at 12:32:33AM +0200, Stefano Brivio wrote:  
> > > > On Fri,  5 Jul 2024 12:07:18 +1000
> > > > David Gibson <david@gibson.dropbear.id.au> wrote:  
> [snip]
> > > > > +		uflow->s[INISIDE] = fcntl(s_ini, F_DUPFD_CLOEXEC, 0);    
> > > > 
> > > > There's one aspect of this I don't understand: if s_ini is closed while
> > > > checking for bound ports (is it? I didn't really reach the end of this
> > > > series), aren't duplicates also closed?
> > > > 
> > > > That is, the documentation of dup2(2), which should be the same for
> > > > this purpose, states that the duplicate inherits "file status flags",
> > > > which I would assume also includes the fact that a socket is closed. I
> > > > didn't test that though.    
> > > 
> > > I don't believe so.  My understanding is that dup() (and the rest)
> > > make a new fd referencing the same underlying file object, yes.  But
> > > AIUI, close() just closes one fd - the underlying object is only
> > > closed only when all fds are gone.  
> > 
> > Ah, probably, yes.
> >   
> > > > If duplicates are closed, I guess an alternative solution could be to
> > > > introduce some kind of reference counting for sockets... somewhere.    
> > > 
> > > .. in other words, I believe the kernel does the reference counting.
> > > 
> > > I should verify this though, I'll try to come up with something new
> > > for doc/platform-requirements.  
> > 
> > I didn't really find the time to sketch this but I guess the easiest
> > way to check this behaviour is to have a TCP connection between a
> > socket pair, with one socket having two descriptors, then closing one
> > descriptor and check if the peer socket sees a closed connection
> > (recv() returning 0 or similar).  
> 
> So.. yes, this would check whether close() on a non-last fd for a
> socket triggers socket closing actions, but that's much stricter than
> what we actually need here.  I would, for example, expect shutdown()
> on a TCP socket to affect all dups - and I don't actually know if a
> close() on one dup might trigger that.
> 
> But we're dealing with UDP here, so there's no "on wire" effect of a
> close.

Right, that's why I was thinking of using a TCP socket. On the other
hand it's a bit silly to test something slightly different to
indirectly check the hypothesis.

> So all we actually need to check is:
>    1. Open a "listening" udp socket
>    2. Dup it
>    3. Close a dup
>    4. Can the remaining dup still receive datagrams?

...sounds much better, yes.

-- 
Stefano