Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c

[Al Borchers]

Maciej, Ted --

Maciej's patch to tty_io.c from lkml 2/22/01

  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/1049.html

has been incorporated in RH 7.1's kernel (for example) but not in the
main 2.4.x kernels.

This presents two different interfaces for serial drivers, and it is
awkward to detect and support both interfaces.  The change breaks some
drivers from Digi International, for example.

In Maciej's patch, if a driver open is interrupted the driver close
IS NOT called.  In the 2.4.x series the close IS called.

A serial driver needs to know whether close is going to be called or
not after an interrupted open, so it can do clean up--like DEC_MOD_USE_COUNT--
appropriately.

Suppose the driver open calls INC_MOD_USE_COUNT, sleeps for the port to get
carrier, then gets interrupted.  If the open calls DEC_MOD_USE_COUNT after
the interrupt, the use count will be right under Maciej's patch but too low on
2.4.x.  If the open does not call DEC_MOD_USE_COUNT after an interrupt, instead
deferring that for the close, then the use count will be too high under
Maciej's patch, but right under 2.4.x.  This is particularly a problem if there
is another outstanding open on the port--in that case you can end up with zero
use count (and a closed port!) while the port is open or a non-zero use count
when no one has the port open. 

Personally, I think Maciej's patch is correct and interrupted opens should
clean up after themselves--however, this is a different interface than presented
by the tty subsystem up to now, and will require changes in some serial drivers.

Ted can you get this patch in the kernel or ban it as interface breaking
heresy?  It would be much nicer for us device driver writers to have just
one interface to support.

Thanks,
-- Al Borchers, Peter Berger

PS. James Puzzo at Digi first pointed out this problem to us.