Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> +#define cond_call_optimized(flags, name, func) \
> + ({ \
> + static const char __cstrtab_name_##name[] \
> + __attribute__((section("__cond_call_strings"))) = #name; \
> + char condition; \
> + asm ( ".section __cond_call, \"a\", @progbits;\n\t" \
> + ".long %1, 0f, %2;\n\t" \
> + ".previous;\n\t" \
> + ".align 2\n\t" \
> + "0:\n\t" \
> + "movb %3,%0;\n\t" \
> + : "=r" (condition) \
> + : "m" (*__cstrtab_name_##name), \
> + "m" (*(char*)flags), \
> + "i" ((flags) & CF_STATIC_ENABLE)); \
Remind me what we need the flags again for?
I would prefer to just eliminate them and always require arming.
> + (likely(!condition)) ? \
> + (__typeof__(func))0 : \
> + (func); \
> + })
> +
> +/* cond_call macro selecting the generic or optimized version of cond_call,
> + * depending on the flags specified. */
> +#define _cond_call(flags, name, func) \
> +({ \
> + (((flags) & CF_LOCKDEP) && ((flags) & CF_OPTIMIZED)) ? \
Similar here? unoptimized condcalls don't make much sense.
I also don't understand what the LOCKDEP flag is good for.
> Index: linux-2.6-lttng/arch/i386/kernel/condcall.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-lttng/arch/i386/kernel/condcall.c 2007-05-17
> 01:52:38.000000000 -0400
> @@ -0,0 +1,140 @@
> +/* condcall.c
> + *
> + * - Erratum 49 fix for Intel PIII.
> + * - Still present on newer processors : Intel Core 2 Duo Processor for Intel
> + * Centrino Duo Processor Technology Specification Update, AH33.
> + * Unsynchronized Cross-Modifying Code Operations Can Cause Unexpected
> + * Instruction Execution Results.
Can you please define a generic utility function to do self modifying
code? There are other places that do it too.
> +static DEFINE_MUTEX(cond_call_mutex);
All locks need a comment describing what they protect and the hierarchy if
any.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
