Comment 20 for bug 216358

Well, I don't really can test it either, so it would have to be tested by others.

I don't really understand, how this race between AIO and setresuid would affect the result of setresuid.
Seems it's fix the result of the (Asynchronous IO), not of setresuid.

But I have an even much bigger problem with this.
My understanding of the problem (which could well be wrong), is that Linux have effective user ID by thread,
rather than by process (this is one of the big guess I make that are often wrong).
But POSIX works with uid on process rather than threads (yes, an other guess).

So, glibc guys, think that they should change effective uid of other threads of the process to respect the POSIX standard.
Which does make sense to me (even if it may cause problems like race condition with AIO, and maybe other stuff).

Now, my really big problem with all this, is that glibc seems to have made a big error.
They seems to think that setresuid is a syscall in the POSIX standards, and setreuid is not.
After all, they seems to have made setresuid ('being smart' about changing other threads of the process).
But it is reverse, as far as I know: setresuid is not part of any POSIX standard, but setreuid is.
Need to find back the pdf where I have read that.

Now, what would seems like a better patch for me, would be to simply make a loop to retry 3 to 5 times,
the setresuid or setreuid, when the result is EAGAIN, which does means after all, "can not do your requested
operation now, please try again".