Seems to me like you missed something in your latest changeset:
-#define CLONE_SIGNAL (CLONE_SIGHAND | CLONE_THREAD)
+#define CLONE_KERNEL (CLONE_FS | CLONE_FILES | CLONE_SIGHAND)
- kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
+ kernel_thread(init, NULL, CLONE_KERNEL);
init used to be spawned with CLONE_THREAD and no longer is. Was this
intentional? The changelog entry didn't indicate it, and I haven't
been keeping track of what all the CLONE flags mean these days so I'm
not sure if this is safe.
--
Revolutions do not require corporate support.
On Sun, 15 Sep 2002, Matthew Wilcox wrote:
> -#define CLONE_SIGNAL (CLONE_SIGHAND | CLONE_THREAD)
> +#define CLONE_KERNEL (CLONE_FS | CLONE_FILES | CLONE_SIGHAND)
> - kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
> + kernel_thread(init, NULL, CLONE_KERNEL);
>
> init used to be spawned with CLONE_THREAD and no longer is. Was this
> intentional? [...]
i think Linus combined a cleanup with the fix i sent earlier today, so
this does look intentional.
Ingo
On Sun, 15 Sep 2002, Matthew Wilcox wrote:
>
> Seems to me like you missed something in your latest changeset:
>
> -#define CLONE_SIGNAL (CLONE_SIGHAND | CLONE_THREAD)
> +#define CLONE_KERNEL (CLONE_FS | CLONE_FILES | CLONE_SIGHAND)
> - kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
> + kernel_thread(init, NULL, CLONE_KERNEL);
>
> init used to be spawned with CLONE_THREAD and no longer is. Was this
> intentional?
Yup. CLONE_THREAD has some new semantics these days, and is not
necessarily at all what a kernel thread wants any more. It used to not
matter at all, but these days it means that it gets put on the same thread
group list as the parent, which means that it won't show up on the global
list of processes any more (since it is considered a "subthread" of the
thread group leader).
Linus