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