Bug 1370630

Created attachment 1194457 [details]
Quick test patch

Description of problem:

A client when working with RHEL7 to validate it for their environment found that they had processes getting stuck due to getaddrinfo() calls spinning.

Version-Release number of selected component (if applicable):
glibc-2.17-106.el7_2.8

How reproducible:
Always

Steps to Reproduce:
1. Enable the use of 'db' files in nsswitch
2. Make 'db' files
3. Run something that does a query, say 'rpcinfo -p localhost'

Actual results:

[root@ivanova ~]# grep services /etc/nsswitch.conf | grep -v '^#'
services:   db files sss
[root@ivanova ~]# cd /var/db/
[root@ivanova db]# make
services... done.
[root@ivanova db]# rpcinfo -p localhost
<hang>

For info:
<strace>
[root@ivanova db]# strace rpcinfo -p localhost
....
read(3, "rt\nsafetynetp      40000/tcp    "..., 4096) = 4096
read(3, "   45678/tcp               # EBA"..., 4096) = 2645
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7f08ae571000, 4096)            = 0
open("/var/db/services.db", O_RDONLY|O_CLOEXEC) = 3
read(3, "\1\6\21\335\2\0\0\0`\0\0\0\0\0\0\0\304I\4\0\0\0\0\0\334\177\10\0\0\0\0\0", 32) = 32
mmap(NULL, 557020, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f08ae4d6000
close(3)
<hang>
</strace>

<ltrace>
[root@ivanova db]# ltrace rpcinfo -p localhost
[root@ivanova db]# ltrace rpcinfo -p localhost
__libc_start_main(0x7fc84409a830, 3, 0x7fff23af8608, 0x7fc84409dab0 <unfinished ...>
getopt(3, 0x7fff23af8608, "a:bdlmn:pstT:u")          = 112
getopt(3, 0x7fff23af8608, "a:bdlmn:pstT:u")          = -1
inet_addr("localhost")                               = 0xffffffff
__rpc_getconfip(0x7fc84409e27e, 0x7fff23af96fa, 0xffffffffffffc817, 0) = 0x7fc84534e440
getaddrinfo("localhost", "rpcbind", 0x7fff23af8350, 0x7fff23af8348
<hang>
</ltrace>

Expected results:
Works.

Additional info:
I did a test build with the upstream patch from:

https://sourceware.org/bugzilla/show_bug.cgi?id=14498

Included and the operation worked properly. The client who reported this (with their own maps, not the default that I'm using) ran their internal tests with the patched build and their issue was cleared up as well.

The quick patch that I used is attached for reference, though it's just a copy of the upstream diff applied to our tree.