Closed Bug 126518 Opened 23 years ago Closed 23 years ago

thread safety and slot->tokenHashTable

Categories

(NSS :: Libraries, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED INVALID

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?
Priority: -- → P1
Target Milestone: --- → 3.4
Bug invalid. The hashtable is protected by slot->objectLock. No changes are necessary.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
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?
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.