Closed
Bug 126518
Opened 23 years ago
Closed 23 years ago
thread safety and slot->tokenHashTable
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
INVALID
3.4
People
(Reporter: bugz, Assigned: rrelyea)
Details
While debugging SSL errors, I noticed that slot->tokenHashTable is a global
hashtable, not protected by a lock, that uses PL_HashTableLookup() instead of
PL_HashTableLookupConst().
I'm also concerned about other aspects of that table. Can it be accessed by
multiple threads simultaneously? If so, there will be problems. It stores a
SECItem which is freed upon removal. This would cause problems in another
thread that had accessed the same SECItem.
But I can't tell if this table is protected at a higher level by the PKCS#11
threading model. Bob, is that the case?
Updated•23 years ago
|
Priority: -- → P1
Target Milestone: --- → 3.4
Reporter | ||
Comment 1•23 years ago
|
||
Bug invalid. The hashtable is protected by slot->objectLock. No changes are
necessary.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 2•23 years ago
|
||
Kirk,
Can you confirm that slot->tokenHashTable is protected by
slot->objectLock? If so, could you document this in the
comment before struct PK11SlotStr in lib/softoken/pkcs11i.h?
Comment 3•23 years ago
|
||
Ok, I've added mention of tokenIDCount and tokeHashTable:
/*
* slots (have sessions and objects)
*
* The array of sessionLock's protect the session hash table (head[])
* as well as the reference count of session objects in that bucket
* (head[]->refCount), objectLock protects all elements of the token
* object hash table (tokObjects[], tokenIDCount, and tokenHashTable),
* and slotLock protects the remaining protected elements:
* password, isLoggedIn, ssoLoggedIn, sessionIDCount, sessionCount,
* and rwSessionCount.
*/
struct PK11SlotStr {
You need to log in
before you can comment on or make changes to this bug.
Description
•