[Bug 219947] New: Undocumented EAGAIN behavior for clone/pthread_create

[Bug 219947] New: Undocumented EAGAIN behavior for clone/pthread_create

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219947

            Bug ID: 219947
           Summary: Undocumented EAGAIN behavior for clone/pthread_create
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: man-pages
          Assignee: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: lennart.kramer@wibu.com
        Regression: No

Currently, when a clone() is called with CLONE_FS (as is the case with
pthread_create), and concurrently in another thread, an execve() syscall is in
progress, the clone() call may return early with an EAGAIN error.

I think the corresponding location in the kernel returning EAGAIN is in
kernel/fork.c inside copy_fs.

The man pages currently only document cases of resource exhaustion (and a
SCHED_DEADLINE case which most people won't care about) under EAGAIN, in which
case aborting the process is reasonable, but in this case it can result in the
process exiting before the execve() syscall finishes.
This is nonsensical as the thread calling clone() was about to be deleted
anyway.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219947] Undocumented EAGAIN behavior for clone/pthread_create

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219947

Carlos O'Donell (carlos@redhat.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos@redhat.com

--- Comment #1 from Carlos O'Donell (carlos@redhat.com) ---
Error number EGAIN is the best error return code for this scenario, from among
those that pthread_create() can return.

The in-progress execve() could fail, at which point pthread_create() called
again would succeed.

It deserves documenting that pthread_create() could fail with EAGAIN if an
in-progress execve() is making forward-progress ahead of the thread, but could
fail, in which case the thread could be created later.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219947] Undocumented EAGAIN behavior for clone/pthread_create

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219947

--- Comment #2 from Carlos O'Donell (carlos@redhat.com) ---
Example:

diff --git a/man/man3/pthread_create.3 b/man/man3/pthread_create.3
index 22926990e..ecb08b8e2 100644
--- a/man/man3/pthread_create.3
+++ b/man/man3/pthread_create.3
@@ -126,6 +126,12 @@ or the maximum number of PIDs,
 was reached (see
 .BR proc (5)).
 .TP
+.B EAGAIN
+An in-progress kernel operation is preventing the creation of the
+thread, e.g.
+.BR execve (2),
+but if such an operation fails, the thread creation can be retried.
+.TP
 .B EINVAL
 Invalid settings in
 .IR attr .
---

Note that I'm not saying that the kernel implementation is right or wrong. I
think it's an open design question if you should block, or return EAGAIN. Each
has pros and cons.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219947] Undocumented EAGAIN behavior for clone/pthread_create

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219947

Alejandro Colomar (alx@kernel.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alx@kernel.org

--- Comment #3 from Alejandro Colomar (alx@kernel.org) ---
(In reply to Carlos O'Donell from comment #2)
> Example:
> 
> diff --git a/man/man3/pthread_create.3 b/man/man3/pthread_create.3
> index 22926990e..ecb08b8e2 100644
> --- a/man/man3/pthread_create.3
> +++ b/man/man3/pthread_create.3
> @@ -126,6 +126,12 @@ or the maximum number of PIDs,
>  was reached (see
>  .BR proc (5)).
>  .TP
> +.B EAGAIN
> +An in-progress kernel operation is preventing the creation of the
> +thread, e.g.
> +.BR execve (2),
> +but if such an operation fails, the thread creation can be retried.
> +.TP
>  .B EINVAL
>  Invalid settings in
>  .IR attr .
> ---
> 
> Note that I'm not saying that the kernel implementation is right or wrong. I
> think it's an open design question if you should block, or return EAGAIN.
> Each has pros and cons.

Would you mind sending the patch to the mailing list, with a commit message
(i.e., full output of git-format-patch(1))?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219947] Undocumented EAGAIN behavior for clone/pthread_create

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219947

--- Comment #4 from Carlos O'Donell (carlos@redhat.com) ---
(In reply to Alejandro Colomar from comment #3)
> Would you mind sending the patch to the mailing list, with a commit message
> (i.e., full output of git-format-patch(1))?

I'd like to give Kramer the opportunity to review, and possibly post their own
version, otherwise I'll post a patch next week.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219947] Undocumented EAGAIN behavior for clone/pthread_create

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219947

--- Comment #5 from L. Kramer (lennart.kramer@wibu.com) ---
> I'd like to give Kramer the opportunity to review, and possibly post their
> own version, otherwise I'll post a patch next week.

Yeah I'm fine with the wording. Would it make sense to also add a similar note
to the clone man page?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.