Seems I munged the kernel list address on the first attempt
to get this out...
--------------B11A0864564A79652B927111
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mozilla-Status2: 00000000
Message-ID: <37974FFF.E5BFF9EA@pangalactic.org>
Date: Thu, 22 Jul 1999 11:08:15 -0600
From: Rob Riggs <rob@pangalactic.org>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-ac12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.rutger.edu, linux-gcc@vger.rutgers.edu
Subject: processes stuck in skb_recv_datagram
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
This problem was previously mentioned:
http://www.tux.org/hypermail/linux-kernel/1999week27/0326.html
http://www.tux.org/hypermail/linux-kernel/1999week26/0796.html
Multiple threads calling gethostbyname_r() (and using DNS
to resolve) ends up with threads stuck in skb_recv_datagram.
This occurs under kernels up to 2.3.10 and 2.2.10ac12 with
glibc-2.1.1 and glibc-2.0.7. Under 2.0 kernels (including
2.0.37) it causes multiple oopses.
Python and C code to illustrate this problem are available:
ftp://ftp.pangalactic.org/pub/outgoing/pytest
ftp://ftp.pangalactic.org/pub/outgoing/thrtest.c
I've received only one comment on this problem. Alan
Cox did suggest that the oops in 2.0 kernels had been
fixed under 2.0.37, but it has not.
I've posted this again to the kernel-list to note that the
problem still occurs under the latest AC release. I've also
directed it to the linux-gcc list since the problem under
2.2 and 2.3 may well be in glibc and not related to the
kernel oopses under 2.0, as was my first impression.
Any comments or suggestions will be greatly appreciated.
-- Rob Riggs Technical Staff Tummy.com, Ltd. http://www.tummy.com/--------------B11A0864564A79652B927111--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/