Date: Sun, 16 Jul 2000 12:20:02 -0700 (PDT) From: "Chris McClellen" <chrismcc@mindspring.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/19871 Message-ID: <200007161920.MAA68177@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/19871; it has been noted by GNATS.
From: "Chris McClellen" <chrismcc@mindspring.com>
To: <bug-followup@freebsd.org>
Cc:
Subject: Re: kern/19871
Date: Sun, 16 Jul 2000 15:16:23 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_001D_01BFEF38.CDC7E5A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
I think I have found the select problem. I've attached
a patch to this email against 5.0-current.
Before I explain what is happening, just know that the patch
is trivial and may break the HELL out of things -- I have
_not_ analyzed the impact. I ran the test in the PR and
it no longer complains. However, I have not really tested
anything else; even if the patch is bogus, I can still
explain the problem below:
fifo_open (miscfs/fifofs/fifo_vnops.c) looks like it has a 2 stage
open.
Stage 1 creates read/write sockets, and sets the read socket
state to SS_CANTRCVMORE. However, it does _not_ set
SS_CANTSENDMORE on the write socket... dont know why.
Stage 2 figures out if you want read/write or both.
When you open for READING, it clears SS_CANTSENDMORE.
when you open for WRITING, it clears SS_CANTRCVMORE.
It would seem that fifos say "you cant recv if you dont
have any writers, and you cant send if you dont have any
readers."
Well thats the problem -- select() eventually calls soreadable(), which
will return true if SS_CANTRCVMORE is set. If you look in fifo_open
you'll see its always set until a writer is opened -- thus causing
select() to always return immediatly until there is a writer, even
though there is nothing to read.
(When writer is created, the SS_CANTRCVMORE gets cleared, so now
soreadble will no longer return a false positive).
Since SO_CANTSENDMORE is not set when a writer is open, I figure
select() will work just fine on a write-only open. So, you can
probably guess the patch -- get rid of SS_CANTRCVMORE on the
initial open. I dont know why its there -- and I dont know why
the same isnt done for the write socket.
Patch is attached, against 5.0-current. Like I said, it may be bogus
but at least someone may have enough info now to do a real fix.
Here's the patch inline (its attached because I am almost
certain that including it in the email will f it up). Its
included inline so people dont have to get the attachment:
*** miscfs/fifofs/fifo_vnops.c.orig Sun Jul 16 14:47:03 2000
--- miscfs/fifofs/fifo_vnops.c Sun Jul 16 14:47:23 2000
***************
*** 202,208 ****
}
fip->fi_readers = fip->fi_writers = 0;
wso->so_snd.sb_lowat = PIPE_BUF;
- rso->so_state |= SS_CANTRCVMORE;
}
if (ap->a_mode & FREAD) {
fip->fi_readers++;
--- 202,207 ----
------=_NextPart_000_001D_01BFEF38.CDC7E5A0
Content-Type: application/octet-stream;
name="patch.fifo"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="patch.fifo"
*** miscfs/fifofs/fifo_vnops.c.orig Sun Jul 16 14:47:03 2000=0A=
--- miscfs/fifofs/fifo_vnops.c Sun Jul 16 14:47:23 2000=0A=
***************=0A=
*** 202,208 ****=0A=
}=0A=
fip->fi_readers =3D fip->fi_writers =3D 0;=0A=
wso->so_snd.sb_lowat =3D PIPE_BUF;=0A=
- rso->so_state |=3D SS_CANTRCVMORE;=0A=
}=0A=
if (ap->a_mode & FREAD) {=0A=
fip->fi_readers++;=0A=
--- 202,207 ----=0A=
------=_NextPart_000_001D_01BFEF38.CDC7E5A0--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007161920.MAA68177>