[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070123.211140.74746965.davem@davemloft.net>
Date: Tue, 23 Jan 2007 21:11:40 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: dean@...tic.org
Cc: rick.jones2@...com, herbert@...dor.apana.org.au,
netdev@...r.kernel.org
Subject: Re: why would EPIPE cause socket port to change?
From: dean gaudet <dean@...tic.org>
Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST)
> libnss-ldap has some code which attempts to determine if its private
> socket has been trampled on in between calls to the library... and to do
> this it caches getsockname/getpeername results and compares them every
> time the library is re-entered... and when there's a mismatch it leaks a
> socket (eventually crashing nscd if you're using that). i've been trying
> to band-aid over the problem:
>
> http://bugzilla.padl.com/show_bug.cgi?id=304
> http://bugzilla.padl.com/show_bug.cgi?id=305
>
> but i'm probably going to need to approach it from another direction --
> make libnss-ldap monitor the ldap library results so it knows when there's
> been a read/write error so that it stops doing this
> getsockname/getpeername thing after the error has occured.
Please do not write programs in this way. getsockname/getpeername
were never meant to be used in that way, and it's hella inefficient
to keep checking the socket like that to boot.
I really don't see you gaining anything by making this check every
time the user calls into the library.
If the application mucks with the communications channel socket, so
what, it's his application that will go tits up.
Is there some tricky interaction between nscd and something like
libnss-ldap that makes this tom-foolery necessary?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists