sss_client: Use initgr mmap cache in client code Resolves: https://fedorahosted.org/sssd/ticket/2485 Reviewed-by: Michal Židek <mzidek@redhat.com>

sss_client: Fix race condition in memory cache Thread safe initialisation was fixed in ticket #2380, but there is still race condition in reinitialisation. If caches is invalidated with command sss_cache -U (-G or -E) then client code will need to reinitialize fast memory cache. Let say we have two threads. The 1st thread find out that memory cache should be reinitialized; therefore the fast memory cached is unmapped and context destroyed. In the same time, 2nd thread tried to check header of memory cache whether it is initialized and valid. As a result of previously unmapped memory the 2nd thread access out of bound memory (SEGFAULT). The destroying of fast memory cache cannot be done any time. We need to be sure that there isn't any other thread which uses mmaped memory. The new counter of active threads was added for this purpose. The state of fast memory cache was converted from boolean to three value state (UNINITIALIZED, INITIALIZED, RECYCLED) UNINITIALIZED - the fast memory cache need to be initialized. - if there is a problem with initialisation the state will not change - after successful initialisation, the state will change to INITIALIZED INITIALIZED - if the cahe was invalidated or there is any other problem was detected in memory cache header the state will change to RECYCLED and memory cache IS NOT destroyed. RECYCLED - nothing will be done is there are any active threads which may use the data from mmaped memory - if there aren't active threads the fast memory cahe is destroyed and state is changed to UNINITIALIZED. https://fedorahosted.org/sssd/ticket/2445 Reviewed-by: Michal Židek <mzidek@redhat.com>

mmap_cache: Use two chains for hash collision. struct sss_mc_rec had two hash members (hash1 and hash2) but only one next member. This was a big problem in case of higher probability of hash collision. structure sss_mc_rec will have two next members (next1, next2) with this patch. next1 is related to hash1 and next2 is related to hash1. Iterating over chains is changed, because we need to choose right next pointer. Right next pointer will be chosen after comparing record hashes. This behaviour is wrapped in function sss_mc_next_slot_with_hash. Adding new record to chain is also changed. The situation is very similar to iterating. We need to choose right next pointer (next1 or next2). Right next pointer will be chosen after comparing record hashes. Adding reference to next slot is wrapped in function sss_mc_chain_slot_to_record_with_hash Size of structure sss_mc_rec was increased from 32 bytes to 40 bytes. Resolves: https://fedorahosted.org/sssd/ticket/2049

Fix errors reported by rpmlint

sss_client: shared memory cache group map support

sss_client: shared memory cache passwd map support

sss_client: Add common shared memory cache utils