Re: recvmsg() "short receive" after FIONREAD
- Reply: Andriy Gapon : "Re: recvmsg() "short receive" after FIONREAD"
- In reply to: Andriy Gapon : "Re: recvmsg() "short receive" after FIONREAD"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 11 Sep 2021 14:28:11 UTC
On 11/09/2021 17:16, Andriy Gapon wrote: > On 11/09/2021 17:13, Mark Johnston wrote: >> 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. > > I didn't think about the locking, so I didn't add it. > My current patch is trivial: > @@ -210,7 +210,7 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct > ucred *active_cred, > if (SOLISTENING(so)) { > error = EINVAL; > } else { > - *(int *)data = sbavail(&so->so_rcv); > + *(int *)data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > } > break; > > Let me try adding the lock. By the way, soo_stat() seems to be another good example to follow. -- Andriy Gapon