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]
Message-ID: <335DD0B75189FB428E5C32680089FB9F012DCE77@mtk-sms-mail01.digi.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ