Date: Sat, 11 Sep 2021 17:28:11 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Johnston <markj@freebsd.org> Cc: "net@FreeBSD.org" <net@freebsd.org>, hackers@freebsd.org Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: <4499e2b0-d1e7-5bee-519c-783fb930fc06@FreeBSD.org> In-Reply-To: <fcf10f8a-1672-4a21-c64b-55044cac81c5@FreeBSD.org> References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <YTuznrhho4qGXqu8@nuc> <cdd2328e-e6aa-f0fc-a77a-adae03759f18@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> <b309f8a5-c550-905b-4340-0b7005ea6fe3@FreeBSD.org> <YTy5kRl0kDl495Po@nuc> <fcf10f8a-1672-4a21-c64b-55044cac81c5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4499e2b0-d1e7-5bee-519c-783fb930fc06>