This bug was initially created as a copy of Bug #1678421 I am copying this bug because the customer requested us to refile the bug against RHEL 7. If clone returns EPERM the stack is deallocated. After clone is successful, glibc might return EPERM if it fails to scheduling policies and/or attributes. On the later case, the thread stack is not released (no call to __deallocate_stack). User wants to know a defined behaviour when pthread_create returns EPERM. If the kernel returns EPERM for the clone call, all data is deallocated? If glibc returns EPERM on subsequent syscalls it would need to create the thread detached and explicitly call pthread_detach?
(In reply to Andrew Mike from comment #0) > This bug was initially created as a copy of Bug #1678421 > > I am copying this bug because the customer requested > us to refile the bug against RHEL 7. > > If clone returns EPERM the stack is deallocated. After clone is > successful, glibc might return EPERM if it fails to scheduling policies > and/or attributes. On the later case, the thread stack is not released > (no call to __deallocate_stack). > > User wants to know a defined behaviour when pthread_create returns EPERM. > > If the kernel returns EPERM for the clone call, all data is deallocated? Yes, if the clone system call fails, we deallocate the previously allocated resources in the current implementation. > If glibc returns EPERM on subsequent syscalls it would need to create the > thread detached and explicitly call pthread_detach? No, if the start routine never runs, pthread_detach would be the wrong thing to do because it does not report the caller of pthread_create. Something like this approach is needed, but needs implementation upstream and careful review there: <https://sourceware.org/bugzilla/show_bug.cgi?id=19511#c4>
Red Hat Enterprise Linux 7 is entering Maintenance Phase Support 1 this year and only Urgent priority bug fixes will be considered. This issue is not urgent and we are moving this to Red Hat Enterprise Linux 8 for further consideration.
The core fix is this: commit 02189e8fb00c3c7f4e67476e21011a22c5dee707 Author: Adhemerval Zanella <adhemerval.zanella> Date: Fri May 21 14:19:23 2021 -0300 nptl: Deallocate the thread stack on setup failure (BZ #19511) But given of the amount of development that went into 2.34, I doubt it will apply cleanly to our 2.28-based tree.
This fix needs a number of backports that significantly increase the risk of regressions, making it unsuitable for RHEL-8.