On Tue, 20 May 2025 at 11:01, Stefano Garzarella <sgarz...@redhat.com> wrote: > > On Tue, 20 May 2025 at 10:54, Stefano Garzarella <sgarz...@redhat.com> wrote: > > > > On Mon, May 12, 2025 at 02:23:12PM +0200, Michal Luczaj wrote: > > >On 5/7/25 10:26, Stefano Garzarella wrote: > > >> On Wed, 7 May 2025 at 00:47, Michal Luczaj <m...@rbox.co> wrote: > > >>> > > >>> On 5/6/25 11:46, Stefano Garzarella wrote: > > >>>> On Tue, 6 May 2025 at 11:43, Stefano Garzarella <sgarz...@redhat.com> > > >>>> wrote: > > >>>>> > > >>>>> On Thu, May 01, 2025 at 10:05:24AM +0200, Michal Luczaj wrote: > > >>>>>> There was an issue with SO_LINGER: instead of blocking until all > > >>>>>> queued > > >>>>>> messages for the socket have been successfully sent (or the linger > > >>>>>> timeout > > >>>>>> has been reached), close() would block until packets were handled by > > >>>>>> the > > >>>>>> peer. > > >>>>> > > >>>>> This is a new behaviour that only new kernels will follow, so I think > > >>>>> it is better to add a new test instead of extending a pre-existing > > >>>>> test > > >>>>> that we described as "SOCK_STREAM SO_LINGER null-ptr-deref". > > >>>>> > > >>>>> The old test should continue to check the null-ptr-deref also for old > > >>>>> kernels, while the new test will check the new behaviour, so we can > > >>>>> skip > > >>>>> the new test while testing an old kernel. > > >>> > > >>> Right, I'll split it. > > >>> > > >>>> I also saw that we don't have any test to verify that actually the > > >>>> lingering is working, should we add it since we are touching it? > > >>> > > >>> Yeah, I agree we should. Do you have any suggestion how this could be > > >>> done > > >>> reliably? > > >> > > >> Can we play with SO_VM_SOCKETS_BUFFER_SIZE like in credit-update tests? > > >> > > >> One peer can set it (e.g. to 1k), accept the connection, but without > > >> read anything. The other peer can set the linger timeout, send more > > >> bytes than the buffer size set by the receiver. > > >> At this point the extra bytes should stay on the sender socket buffer, > > >> so we can do the close() and it should time out, and we can check if > > >> it happens. > > >> > > >> WDYT? > > > > > >Haven't we discussed this approach in [1]? I've reported that I can't make > > > > Sorry, I forgot. What was the conclusion? Why this can't work? > > > > >it work. But maybe I'm misunderstanding something, please see the code > > >below. > > > > What I should check in the code below? > > Okay, I see the send() is blocking (please next time explain better > the issue, etc.) > > I don't want to block this series, so feel free to investigate that > later if we have a way to test it. If I'll find some time, I'll try to > check if we have a way.
I've tried to take a look, and no, there's no easy way except to somehow slow down the receiver, but I don't think we have a reliable way to do that, so I can't think of anything for now. Let's skip it (I'll try to remember ;-) Thanks, Stefano
