Hi all, I may have stumbled upon a bug (or is it a feature?). First off though, I am reporting this based on my recollection - so my description might not be 100% accurate (this happened about two months ago). Since I don't have time to set up a verification scenario, I figured I'd just report this and let some else do the grunt work (thank you) or just not worry about it.
The problem (on a SLES9 - which is something like 2.6.5 plus SuSE patches) was that a file descriptor, once put into a UNIX domain socket would not be considered by the kernel when the according resource was being closed. If the handle was taken "out of the UDS" after the resource already has been closed than the handle appeared to represent a resource that was no longer valid. What that would do if you actually used the handle is entirely left untested. Essentially what I observed was that the handle represented a TCP hashtable entry that was no longer allocated in the kernel, but was nevertheless "given" to the process. Technically speaking: "lsof" reported a socket identifier not listed in /proc/net/tcp anymore (this was double and triple checked at the time because it seemed so odd). The process now appeared to have a handle to a TCP connection which was no longer established. My assumption here is that the handle would actually match the next connection that has the same TCP identity (IP addresses/ports) and might "work" with that connection. jp -- Jürgen Pabel, CISSP Akkaya Consulting GmbH Eupener Straße 137 50933 Köln Telefon: +49 221 9473007 Telefax: +49 221 4911970 Mobil: +49 160 8806134 E-Mail: [EMAIL PROTECTED] Internet: http://www.akkaya.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
