Jeff Law says in bugzilla:
"Based on just reading the code, I wonder if a one thread is mucking up
hst_map_handle.mapped behind the back of nscd_get_mapping.
nscd_get_nl_timestamp doesn't bother to grab the hst_map_handle lock and
into nscd_get_mapping which could potentially change hst_map_handle.mapped
If this occurs after another thread had passed the NO_MAPPING check in
nscd_get_map_ref, but hasn't yet hit the atomic_decrement_val in
nscd_get_mapping then it could cause the failure mode reported in this
(and several others across various distros, upstream kde and possibly
I agree with his analysis and cleaned up the patch submission (added
copyright header and ChangeLog entry).
This patch has been tested in openSUSE and Fedora.
Ok to commit? Andreas
2012-05-14 Jeff Law<firstname.lastname@example.org>
* nscd/nscd_gethst_r.c (__nscd_get_nl_timestamp): Add locking to
code changing __hst_map_handle.map.
diff --git a/nscd/nscd_gethst_r.c b/nscd/nscd_gethst_r.c
index c1661f8..36c4bb3 100644
@@ -1,5 +1,4 @@
-/* Copyright (C) 1998-2005, 2006, 2007, 2008, 2009, 2011
- Free Software Foundation, Inc.
+/* Copyright (C) 1998-2012 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Ulrich Drepper<email@example.com>, 1998.
@@ -100,9 +99,27 @@ libc_freeres_fn (hst_map_free)
+ uint32_t retval;
if (__nss_not_use_nscd_hosts != 0)
+ int cnt = 0;
+ /* __nscd_get_mapping can change hst_map_handle.mapped to NO_MAPPING.
+ However, __nscd_get_mapping assumes the prior value was not NO_MAPPING.
+ Thus we have to acquire the lock to prevent this thread from changing
+ hst_map_handle.mapped to NO_MAPPING while another thread is inside
+ __nscd_get_mapping. */
+ while (__builtin_expect
+ (atomic_compare_and_exchange_val_acq (&__hst_map_handle.lock,
+ 1, 0) != 0, 0))
+ /* XXX Best number of rounds? */
+ if (__builtin_expect (++cnt> 5, 0))
+ return 0;
+ atomic_delay ();