On 4/28/25 15:56, Stefano Garzarella wrote: > On Thu, Apr 24, 2025 at 01:24:59PM +0200, Michal Luczaj wrote: >> On 4/24/25 10:36, Stefano Garzarella wrote: >>> On Thu, 24 Apr 2025 at 09:53, Michal Luczaj <m...@rbox.co> wrote: >>>> On 4/24/25 09:28, Stefano Garzarella wrote: > > [...] > >>>> You're right, it was me who was confused. VMCI and Hyper-V have their own >>>> vsock_transport::release callbacks that do not call >>>> virtio_transport_wait_close(). >>>> >>>> So VMCI and Hyper-V never lingered anyway? >>> >>> I think so. >>> >>> Indeed I was happy with v1, since I think this should be supported by >>> the vsock core and should not depend on the transport. >>> But we can do also later. >> >> OK, for now let me fix this nonsense in comment and commit message. > > Thanks! > >> >> But I'll wait for your opinion on [1] (drop, squash, change order of >> patches?) before posting v3. > > I'm fine with a second patch to fix the indentation and the order looks > fine. > > BTW I'm thinking if it makes sense to go back on moving the lingering in > the core. I mean, if `unsent_bytes` is implemented, support linger, if > not, don't support it, like now. > > That said, this should be implemented in another patch (or eventually > another series if you prefer), so my idea is the following split: > - use unsent_bytes() just in virtio > - move linger support in af_vsock.c (depending on transports > implementing unsent_bytes()) > - implement unsent_bytes() in other transports (in the future) > > WDYT?
Sure, makes sense. Even though I'm not certain I understand "use unsent_bytes() just in virtio" part. Anyway, we can carry the discussion to v3: https://lore.kernel.org/netdev/20250430-vsock-linger-v3-0-ddbe73b53...@rbox.co/ Note that I took the liberty to assume unsent_bytes() is always there for loopback/virtio transports. Check for NULL is introduced when the code is moved to core. By the end of the series it changes nothing, but I hope it's a tiny bit more sensible. Thanks, Michal
