gh-127081: lock non-re-entrant *pwent calls
#132748
Conversation
The libc setpwent, getpwent, and endpwent functions are not thread-safe. Protect them with mutexs in free-threading builds.
*pwent calls
There was a problem hiding this comment.
We need a critical section here. Py_CLEAR and Py_DECREF are re-entrant (as in, they can invoke the eval loop), so a mutex is prone to lock-ordering or re-entrancy deadlocks.
|
Actually, sorry, we need to fix subinterpreter thread-safety here too. We can't do that with a critical section. Could you adjust the mutex to go over solely the libc calls? |
Hmm, yeah, good point. I guess we can just defer the decrefs until exit. |
…ility of re-entrancy.
Modules/pwdmodule.c
Outdated
| Py_ssize_t n = PyList_Size(d); | ||
| for (Py_ssize_t i = 0; i < n; ++i) { | ||
| PyObject *entry = PyList_GetItem(d, i); | ||
| Py_DECREF(entry); | ||
| } |
There was a problem hiding this comment.
| Py_ssize_t n = PyList_Size(d); | |
| for (Py_ssize_t i = 0; i < n; ++i) { | |
| PyObject *entry = PyList_GetItem(d, i); | |
| Py_DECREF(entry); | |
| } | |
| Py_ssize_t n = PyList_GET_SIZE(d); | |
| while (--n >= 0) { | |
| Py_DECREF(PyList_GET_ITEM(d, n)); | |
| } |
There was a problem hiding this comment.
This change broke GIL builds, as they use the limited API only, which does not include those functions. Unfortunately I was using a free-threading build, so didn't notice initially. I'll switch back to using the ones available in the limited API, but keep the better loop construct.
The libc setpwent, getpwent, and endpwent functions are not thread-safe. Protect them with mutexs in free-threading builds.