vgone() calling VOP_CLOSE() -> blocked threads?

[Ed Schouten]

Hello Bruce,

* Bruce Evans <brde at optusnet.com.au> wrote:
> On Wed, 19 Mar 2008, Ed Schouten wrote:
>
>> I just changed my TTY code to perform some garbage collecting on TTY's.
>> It now only performs a device cleanup when si_threadcount == 1 and
>> TF_OPENED is unset. Unfortunately, I'm checking for these conditions in
>> all the cdev ops, which is quite expensive.
>>
>> It does the trick, but if someone has a better idea, I'm willing to
>> implement it.
>
> When does si_threadcount go to 0 -- can it be 1 due to something other
> than a cdev op holding a reference?

It would probably reach 0, but because the thread calling the close
routine is also taken into account, it will be 1.

> If revoke() is the only problem, and if non-cdev ops can hold a
> reference, then it might work to acquire a reference at the time of
> the revoke.  Hold this reference in some process (could even be in
> userland), and consider releasing it some time later (and later again
> if the synchronization hasn't completed).  While this reference is
> held, si_refcount cannot go to 0, so it is only necessary to check
> si_threadcount == 1 when considering releasing this reference.

Because I'm not really sure about si_threadcount's locking and don't
want to rely on undocumented tricks too much, I just introduced a
t_threadcnt, which is adjusted when entering/leaving one of the cdev
ops. This makes it a lot easier to lock as well.

It should be waterproof w.r.t. referencing the TTY, but won't protect it
against any open/close races yet.

> New opens on the device probably need to be blocked while the state is
> unsynchronized -- otherwise too many states are possible.

Fortunately, the close() path doesn't block yet, but I was thinking
about adding flags, which should be set when entering tricky parts of
the TTY layer, such as line discipline changing and device opening and
closing.

For now, the current solution should suffice. I'm more worried about
getting uart(4) to work right now. ;-)

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://g-rave.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080319/9e57a305/attachment.pgp