Yea, this looks appropriate.
Could you submit a patch to gerrithub?
This will need backporting to 2.4 also I think.
Thanks
Frank
From: sriram patil [mailto:[email protected]]
Sent: Tuesday, February 14, 2017 7:43 AM
To: [email protected]
Subject: [Nfs-ganesha-devel] Deadlock when dealing with ht_unconfirmed_client_id
Hi,
There seems to be a deadlock between
nfs4_op_setclientid/nfs4_op_setclientid_confirm and reap_hash_table.
nfs4_op_setclientid takes the lock on client_record->cr_mutex first and then
goes ahead and takes a read-write lock on the hash table partition as part of
nfs_set_client_id_insert or remove_unconfirmed_client_id.
However, the order is reversed in reap_hash_table. Here's the code snippet
191 if (client_rec != NULL)
192 inc_client_record_ref(client_rec);
193 PTHREAD_MUTEX_unlock(&client_id->cid_mutex);
194 if (client_rec != NULL)
195 PTHREAD_MUTEX_lock(&client_rec->cr_mutex);
196
197 PTHREAD_RWLOCK_unlock(&ht_reap->partitions[i].lock);
198 nfs_client_id_expire(client_id, false);
As we can see, it takes lock on cr_mutex on line 195 and releases the lock on
hash table partition on line 197.
Can we do the ht partition unlock before taking lock on cr_mutex?
Thanks,
Sriram
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
