In my mind, a port was only open after my open() handler returns
success.  I guess that's wrong, and I should increment my use counter
unconditionally each time my open() handler is called.

Probably - and remember to allow for hangup.

customers are running kernels recent enough to have those helpers. I
suppose I could look into writing compatibility versions compatible
with the range of kernels I have to support.

It's actually pretty independant of the underlying tty code so may well
backport quite easily although it does touch on the refcounting stuff a
bit I guess.

The problem is how to make a driver written that way work for somebody
running a 2.4 kernel (or even a not-very-recent 2.6 kernel).  Yes, I
have a few customers running 2.4 kernels, and lots of customers
running older 2.6 kernels.  I _might_ be able to convince management
it's time to drop support for 2.4, but there's no way I can abandon
customers using 2.6 kernels.

For 2.4 I think you are on your own, but there are also no 2.4 kernels
without security holes so I tend to think of 2.4 as mostly dead.

In the 2.6 case the tty_port code depends upon the tty layer refcounting,
and the tty layer refcounting fixes exploitable races in tty hangup.

At a certainly point you may actually be best supporting both setups as
two driver variants. One for the kernels with old style lock_kernel
assumptions and the like, one for those where tty_port appears and we
relax the rest of the rules dramatically.

Alan