netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: dean@arctic.org
Cc: rick.jones2@hp.com, herbert@gondor.apana.org.au, netdev@vger.kernel.org
Subject: Re: why would EPIPE cause socket port to change?
Date: Tue, 23 Jan 2007 21:11:40 -0800 (PST)	[thread overview]
Message-ID: <20070123.211140.74746965.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0701231140320.21464@twinlark.arctic.org>

From: dean gaudet <dean@arctic.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?


  reply	other threads:[~2007-01-24  5:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-23  4:01 why would EPIPE cause socket port to change? dean gaudet
2007-01-23  5:44 ` Herbert Xu
2007-01-23 11:10   ` Michael Tokarev
2007-01-23 11:12     ` Herbert Xu
2007-01-23 11:15       ` Michael Tokarev
2007-01-23 11:18         ` Herbert Xu
2007-01-23 18:22   ` Rick Jones
2007-01-23 20:11     ` dean gaudet
2007-01-24  5:11       ` David Miller [this message]
2007-01-24  6:09         ` dean gaudet
2007-01-23 20:26   ` Stephen Hemminger
2007-01-24  5:58     ` Herbert Xu
2007-01-24  6:30       ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070123.211140.74746965.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=dean@arctic.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).