linux-kernel - Re: question on tty open and close

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 28 Mar 2007 09:37:19 -0500
From:	"Kilau, Scott" <Scott_Kilau@...i.com>
To:	<alan@...rguk.ukuu.org.uk>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: question on tty open and close

> > > > > So we have a file that's closed although open() never
succeeded?
> > > > 
> > > > That's correct! It's been a pain in my butt for years.
> > > 
> > > How did you deal with that proctological issue?
> > 
> > Just make sure the close() handles the situation properly. It makes
> > reference counting...  fun.
> > 
> > The serial driver has always handled it like this.
> 
> I'm also not aware of any reason other than history, which means if
> someone cares to double check the other drivers there really shouldn't
be
> an obstacle to "fixing" this behaviour.
> 
> Unless anyone knows different ?

Hi Alan!

>From our (Digi's) drivers history, I believe you tried "fixing" it back
in the Red Hat 7.1 days. =)

Sadly, our drivers still carry this legacy fix around.

    o Red Hat 7.1 -- Kernel Compatibility Issues
         Some 2.4 kernel-based distributions (Red Hat 7.1 included) have
a patch
         applied to them which modifies the behavior of Linux when an
open of
         a serial port is canceled (for instance, if an application is
waiting
         for the carrier signal and a user hits CTRL-C to kill the
application)
        
         With this behavior change, the device driver is unable to
cleanup its
         internal data structures and the sane functioning of the driver
is
         compromised.  The classic symptom of this problem is that the
command
         "lsmod", which (among other things) will return a count of the
         applications using the device driver, will return a non-zero
value
         even if all applications associated with the serial ports
         are killed.   
            
         Unfortunately, it is impossible (from within the device driver)
to
         determine which behavior is implemented in the running kernel.
         However, Digi now provides a workaround to allow customers with
this
         problem to change the Digi behavior to be compatible with these
         "patched" kernels.


I know backwards compatibility in the kernel isn't a concern at all,
which has been made abundantly clear, (ie, stable_api_nonsense.txt),
but this will impact *all* out of tree serial drivers.

Just wanted to toss this out there.
Scott Kilau
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/