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

On Thu, 11 Jul 2024 11:30:52 +1000
David Gibson <david(a)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(a)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(a)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