[lkml]   [2002]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[patch] complain about unknown CLONE_* flags
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;

+ return ERR_PTR (-EINVAL);
if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
return ERR_PTR(-EINVAL);

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 13:28    [W:0.262 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site