libthr pshared: correct a bug in allocation
When __thr_pshared_offpage() is called for allocation, it must not use the cached offpage for the key. Instead, the cached offpage must be unmapped and removed from the cache, if any. It is legitimate for the user code to unmap the shared lock object without destroying it, and then mapping something over the freed VA to carry another shared lock. In this case the cached offpage must be un-cached. PR: 269277 Reported by: rau8344@gmail.com Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D38345
This commit is contained in:
parent
3cf37d1251
commit
25c862ae50
@ -232,11 +232,16 @@ __thr_pshared_offpage(void *key, int doalloc)
|
||||
int fd, ins_done;
|
||||
|
||||
curthread = _get_curthread();
|
||||
pshared_rlock(curthread);
|
||||
res = pshared_lookup(key);
|
||||
pshared_unlock(curthread);
|
||||
if (res != NULL)
|
||||
return (res);
|
||||
if (doalloc) {
|
||||
pshared_destroy(curthread, key);
|
||||
res = NULL;
|
||||
} else {
|
||||
pshared_rlock(curthread);
|
||||
res = pshared_lookup(key);
|
||||
pshared_unlock(curthread);
|
||||
if (res != NULL)
|
||||
return (res);
|
||||
}
|
||||
fd = _umtx_op(NULL, UMTX_OP_SHM, doalloc ? UMTX_SHM_CREAT :
|
||||
UMTX_SHM_LOOKUP, key, NULL);
|
||||
if (fd == -1)
|
||||
|
Loading…
Reference in New Issue
Block a user