Date: Tue, 15 May 2001 18:28:29 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: jhb@FreeBSD.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@FreeBSD.org Subject: RE: select(2) converted to use a condition variable, and optimis Message-ID: <200105150928.f4F9STP74281@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: In your message of "Wed, 09 May 2001 19:20:07 %2B0900" <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> References: <200105081026.f48AQgP75260@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.010508082155.jhb@FreeBSD.org> <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 09 May 2001 19:20:07 +0900, Seigo Tanimura <tanimura> said: Seigo> On Tue, 08 May 2001 08:21:55 -0700 (PDT), Seigo> John Baldwin <jhb@FreeBSD.org> said: John> On 08-May-01 Seigo Tanimura wrote: >>> Here is another issue. PROC_LOCK may block to acquire a process lock, >>> during which an event of interest may occur or the remaining time of >>> select(2)/poll(2) may run out. Thus if the remaining time runs out >>> during locking a process, we should first rescan file descriptors to >>> avoid missing an event, followed by returning the result. John> Hmmm. Actually, can the nb_poll, ncp_poll, pollscan, or selscan functions call John> tsleep/msleep? If they don't, then we are just better off holding proc lock John> while we call them rather than releasing it just to call that function and John> acquiring it later. Then we don't have to work around the race you describe. Seigo> Poling functions called via fo_poll in a file descriptor should not Seigo> call msleep(9) in theory. Seigo> That does not, however, necessarily imply that we can scan file Seigo> descriptors with holding a process lock. Another process can release a Seigo> reference to a file descriptor via closef() during polling the Seigo> descriptor by calling its fo_poll. In this case, fdrop() subsequent to Seigo> the call of fo_poll may result the reference count of the descriptor Seigo> to be zero. Another issue that turned out just now is lock order reversal in selrecord(), where a process attempts to lock allproc sx while locking the process itself. You might see something like this in your dmesg: > lock order reversal > 1st 0xc7b9c31c process lock @ ../../kern/sys_generic.c:776 > 2nd 0xc0438800 allproc @ ../../kern/kern_proc.c:146 As it is essential in this case to lock allproc and check whether another process is waiting for an event, the only one option is to back out the change of scanning file descriptors with holding a process lock. -- Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105150928.f4F9STP74281>