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 <[EMAIL PROTECTED]> 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to