[patch] complain about unknown CLONE_* flags

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

About new clone() flags...

One of the obvious things for a thread library is to:

    (a) try clone() with lots of snazzy flags
    (b) if that returns -EINVAL, we must be running on an older kernel;
        try with fewer flags and more workarounds

However, I don't see any code in sys_clone() that rejects a call that
specifies unknown flags.  So, code that uses e.g. CLONE_SETTID will
appear to run perfectly well on an old kernel... except that it will
behave incorrectly.

That leads to having to write some silly test for each feature prior to
using it, instead of trying it and falling back.  E.g. I'd need to
do the silly signal-blocking workaround when creating the second thread
in a program, just to find out whether CLONE_SETTID actually worked.
Either that, or check the kernel version.

Ingo, how do you handle this sort of backward compatibility in your
latest pthreads library, or don't you do backward compatibility?

For future-proofing, here's a patch:

diff -u linux-2.5/kernel/fork.c.orig linux-2.5/kernel/fork.c
--- linux-2.5/kernel/fork.c
+++ linux-2.5/kernel/fork.c	Thu Aug 15 23:35:00 2002
@@ -619,6 +619,11 @@
 	struct task_struct *p = NULL;
 	struct completion vfork;
 
+	if ((clone_flags & ~(0UL|CSIGNAL|CLONE_VM|CLONE_FS|CLONE_FILES
+			     |CLONE_SIGHAND|CLONE_PID|CLONE_PTRACE|CLONE_VFORK
+			     |CLONE_PARENT|CLONE_THREAD)))
+		return ERR_PTR (-EINVAL);
+
 	if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
 		return ERR_PTR(-EINVAL);