Re: kern/60782: SIGIO says socket ready for send before send does

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60782; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: mlelstv%serpens.de@localhost (Michael van Elst)
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/60782: SIGIO says socket ready for send before send does
Date: Thu, 24 Sep 2026 22:31:40 +0000

 > Date: Thu, 24 Sep 2026 21:17:18 -0000 (UTC)
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > 
 > Sending SIGIO and waking up a blocked writer is done at the same time,
 > but a blocked writer just blocks again without noticable issue.
 
 I think the basic issue is that the wakeup path in recv(2) that leads
 to SIGIO is simply not conditional on anything about the buffer state.
 I bet nobody noticed this because it doesn't cause an actual return
 from poll -- just another pass through polscan or whatever, which
 might hurt performance but doesn't hurt correctness.
 
 Perhaps sorwakeup/sowwakeup should just check soreadable/sowritable
 before calling sowakeup.
 
 > poll(2) checks sbspace(sb) >= sb->sb_lowat. So it signals a writable
 > descriptor at a different time. If sbspace(sb) > 0 a send smaller
 > than sb_lowat may even succeed when, according to poll(2) it's not
 > yet possible.
 > 
 > 
 > Maybe changing the test in sbspace to:
 > 
 > 	if (sb->sb_hiwat <= sb->sb_cc)
 > 		return 0;
 > 	if (sb->sb_mbmax <= sb->sb_mbcnt) 
 > 		return 1;
 > 
 > already helps.
 
 Why would changing sbspace affect this?  I think it is not used
 anywhere in the decision of whether to send SIGIO or not.  (But maybe
 I missed something -- I only took a cursory skim at this part while
 lifting the SIGIO rock and finding a whole colony of bugs under it!)