Re: recvmsg() "short receive" after FIONREAD

On Sat, Sep 11, 2021 at 11:15:12AM +0300, Andriy Gapon wrote:
> On 10/09/2021 22:40, Andriy Gapon wrote:
> > On 10/09/2021 22:38, Andriy Gapon wrote:
> >> On 10/09/2021 22:35, Mark Johnston wrote:
> >>> Indeed, I suspect that this is the problem.  Note that for
> >>> kevent(EVFILT_READ) we subtract the number of control message bytes from
> >>> the returned value, see filt_soread().  I wonder if FIONREAD should do
> >>> the same thing.
> >>
> >> Thank you for the suggestion.
> >> I think that it is a reasonable expectation that FIONREAD returns a number of 
> >> bytes that can be actually read.
> >> I'll look at filt_soread().
> > 
> > kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl;
> > Is this it?
> > Looks simple enough for a quick test :)
> 
> 
> Works perfectly.
> Should I just commit it or is a larger discussion needed?

I think the semantic change is ok.  Did you change FIONREAD to lock the
sockbuf?  I think it would be necessary to avoid races with pulseaudio:
sb_acc is modified before sb_ctl, so there could be windows where
sbavail(sb) - sb->sb_ctl gives a larger.

And, it is not really safe to lock the sockbuf itself, since it may be
overwritten by a listen(2) call.  SOCK_RECVBUF_LOCK(so) should be used
instead.