On 05/22/2013 12:01 AM, Bernhard Voelker wrote:
> I found this one while testing the new nap() code on FAT
> (as a non-root user).
>
> WDYT?
That makes sense.
EPERM is not tested/generated in the replacements,
so adding that avoidance would have no impact
on the test coverage.
I added a Changel
I am trying to fix a bug in libvirt where a child process deadlocked
because it called initgroups() in between fork and exec when the parent
was multithreaded; it turns out that looking up group membership
information requires a mutex, but if some other thread in the parent
owns that mutex at the t
It's fine with me to relicense that as LGPLv2+.
Because I actually managed to hit deadlock in libvirt's child
process due to glibc's mutex use in user database lookup, I
figured it is worth documenting the issue for others to be
aware of when writing a privileged multithreaded parent app
that spawns child processes owned by non-privileged ids.
On 05/22/2013 06:49 PM, Eric Blake wrote:
> I am trying to fix a bug in libvirt where a child process deadlocked
> because it called initgroups() in between fork and exec when the parent
> was multithreaded; it turns out that looking up group membership
> information requires a mutex, but if some o
Eric Blake wrote:
> I am trying to fix a bug in libvirt where a child process deadlocked
> because it called initgroups() in between fork and exec when the parent
> was multithreaded; it turns out that looking up group membership
> information requires a mutex, but if some other thread in the paren
On 2013-05-22 Eric Blake wrote:
> Since getgrouplist is implemented in glibc as LGPLv2+, is there any
> objection to relicensing the following modules as LGPLv2+?
[...]
> getgroups [LGPLv3+] => *Jim, *Eric, Bruno, Paul
> getugroups [GPLv3+] => *Jim, Eric, Paul, Bruno, Lasse
> mgetgroups [GPLv3+] =>
