Hi, 

glibc 2.9 uses a different way to implement getaddrinfo() which
triggers a race condition in most (if not all) Netfilter
firewalls that use connection tracking. glibc does nothing wrong
per se, it just triggers the condition. (technical details here:
http://marc.info/?l=linux-netdev&m=123304473331445)

Since glibc 2.9 fires off two udp packets (a query for the A
record and one for the AAAA record), a race condition is
triggered in Netfilter (see URL). This has been acknowledged by
several people and I can reproduce it (relatively) reliably in
our LAN with all Gentoo boxes that have 2.9.

Why am I bringing this up here? Well, I figure that eventually,
2.9 (or some other version with equivalent code) will become
stable and we'll get lots of bug reports from people who run into
this. Since they can not simply backdate to 2.7 for various
reasons *and* they might be unable to fix a packetfilter (because
it might not be their own), this might become very ugly.

The Kernel/Netfilter devs (probably) are aware now of the issue
since I mailed them - but it's not all that easy to fix. On top
of that, even if it was fixed in (say) 2.6.28.3 and 2.6.29, this
does not mean that it's deployed out there and it might be very
hard for our users to get some firewall guy to update their
kernel when this is perceived as glibc's or our fault (plus the
widespread "ricer" cliché about Gentoo users; I've gotten an
idiotic reply to that effect already).

I don't have any experience with glibc upstream but pestering
them about this out of the blue might only cause a flame war
between kernel and glibc folks. Thus, I'm asking you, my fellow
devs (and the glibc and kernel teams specifically), what you
think is the best idea/course of action.

Regards,
Tobias
(Blackb|rd)
-- 
printk("Cool stuff's happening!\n")
        linux-2.4.3/fs/jffs/intrep.c