From: Chuck Ebbert
Date: Tue Jul 18 2006 - 06:23:43 EST

In-Reply-To: <20060714060932.GE18774@xxxxxxxxxxxxxx>

On Fri, 14 Jul 2006 08:09:32 +0200, andrea@xxxxxxxxxxxx wrote:

> The below patch seems to work, I ported all my client code on top of
> prctl already. (it's a bit more painful to autodetect a kernel with
> CONFIG_SECCOMP turned off but I already adapted to it)

AFAIC the /proc method of controlling seccomp is so ugly it should
just go, but what about backwards compatibility?

I have a couple of questions:

+void disable_TSC(void)
+ if (!test_and_set_thread_flag(TIF_NOTSC))
+ /*
+ * Must flip the CPU state synchronously with
+ * TIF_NOTSC in the current running context.
+ */
+ hard_disable_TSC();

This gets called from sys_prctl(). Do you need to worry about preemption
between the test_and_set and TSC disable?

--- a/include/asm-i386/processor.h Thu Jul 13 03:03:35 2006 +0700
+++ b/include/asm-i386/processor.h Fri Jul 14 07:47:57 2006 +0200
@@ -256,6 +256,10 @@ static inline void clear_in_cr4 (unsigne
cr4 &= ~mask;
+extern void hard_disable_TSC(void);
+extern void disable_TSC(void);
+extern void hard_enable_TSC(void);

Maybe these should be inline? They're really small and that way you
don't need #ifdef around the code for them.

> Reviews are welcome (then I will move into x86-64, all other archs
> supporting seccomp should require no changes despite the API
> change). Thanks.

For x86_64 you need this:

But I don't think Andi plans on pushing it for 2.6.18.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at