idmapper collision fix

The threads that lookup by name or id use the read lock. If they don't
find an entry, then they release the read lock, acquire the write lock
and then add the entry. So it is possible that multiple threads may fail
to find an entry at one point and they all try to add. In this case, we
will be trying to insert same name,id mapping. It is also possible that
name got a different id or an id got a different name causing us to find
an existing entry when we are trying to add an entry! So collison
warning log message is incorrect!

Removed the collision warning log message. Re-arranged the code to make
it a bit more readable. Also added in_uidtree boolean field in struct
cache_user to avoid removing a node entry without actually inserting one
before!

Reported-by: John Dorfner <dorfner@us.ibm.com>
Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Verify the node we find in the hash arrays

Verify that the node we find in uid_cache and gid_cache arrays is in
fact what we need.

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Acked-by: Suhrud Patankar <supatank@in.ibm.com>
Fix incorrect use of atomic_[store/fetch]_uint64_t

atomic_store_uint64_t and atomic_fetch_uint64_t were used in idmapper
cache and supplementary groups cache code to store a pointer!  Replaced
those calls with atomic_store_voidptr and atomic_fetch_voidptr
respectively.

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Acked-by: Suhrud Patankar <supatank@in.ibm.com>