Linux Kernel Markers for 2.6.23-rc4-mm1

Changelog:
- markers_mutex now nests inside module_mutex rather than the opposite.

Signed-off-by Mathieu Desnoyers <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by Rusty Russell <[email protected]>

Reviewed-by "Frank Ch. Eigler" <[email protected]>

---

 include/asm-generic/vmlinux.lds.h |   11 
 include/linux/marker.h            |  169 +++++++++
 include/linux/module.h            |    5 
 kernel/marker.c                   |  699 ++++++++++++++++++++++++++++++++++++++
 kernel/module.c                   |   11 
 5 files changed, 894 insertions(+), 1 deletion(-)

Index: linux-2.6-lttng/include/linux/marker.h
===================================================================

+ * pdata must be a valid allocated memory address, or NULL.
+ */

include/linux/marker.h new file +2 -0

+extern int marker_probe_register(const char *name, const char *format,
+				marker_probe_func *probe, void *pdata);

Index: linux-2.6-lttng/kernel/marker.c
===================================================================

kernel/marker.c new file +20 -0

+ * unregistered and then registered back with a different probe data.
+ */
+static int deferred_sync;
+
+/*
+ * Marker hash table, containing the active markers.
+ * Protected by module_mutex.
+ */
+#define MARKER_HASH_BITS 6
+#define MARKER_TABLE_SIZE (1 << MARKER_HASH_BITS)
+
+struct marker_entry {
+	struct hlist_node hlist;
+	char *format;
+	marker_probe_func *probe;
+	void *pdata;
+	int refcount;	/* Number of times armed. 0 if disarmed. */
+	char name[0];	/* Contains name'\0'format'\0' */
+};
+

kernel/marker.c new file +8 -0

+ * though the function pointer change and the marker enabling are two distinct
+ * operations that modifies the execution flow of preemptible code.
+ */
+void __mark_empty_function(const struct __mark_marker *mdata,
+	void *private_data,
+	const char *fmt, ...)
+{ }
+EXPORT_SYMBOL_GPL(__mark_empty_function);

kernel/marker.c new file +25 -0

+
+	if ((*entry)->format) {
+		if (strcmp((*entry)->format, elem->format) != 0) {
+			printk(KERN_NOTICE
+				"Format mismatch for probe %s "
+				"(%s), marker (%s)\n",
+				(*entry)->name,
+				(*entry)->format,
+				elem->format);
+			return -EPERM;
+		}
+	} else {
+		ret = marker_set_format(entry, elem->format);
+		if (ret)
+			return ret;
+	}
+	elem->call = (*entry)->probe;
+	elem->pdata = (*entry)->pdata;
+	_immediate_set(&elem->state, 1);
+	return 0;
+}
+
+/*
+ * Disable a marker and its probe callback.
+ * Note: only after a synchronize_sched() issued after setting elem->call to the

kernel/marker.c new file +12 -0

+	 * the next initialization anyway.
+	 */
+}
+
 
+#ifdef CONFIG_MODULES
+/*
+ * Update module probes.
+ * Must be called with markers_mutex held.
+ */
+static inline void marker_update_probes_modules(struct module *probe_module,
+	int *refcount)
+{

kernel/marker.c new file +19 -0

+#else
+static inline void marker_update_probes_modules(struct module *probe_module,
+	int *refcount)
+{ }
+#endif
+
+/*
+ * Update probes, removing the faulty probes.
+ * Issues a synchronize_sched() when no reference to the module passed
+ * as parameter is found in the probes so the probe module can be
+ * safely unloaded from now on.
+ */
+static inline void _marker_update_probes(struct module *probe_module)
+{
+	int refcount = 0;
+
+	/* Core kernel markers */
+	marker_update_probe_range(__start___markers,
+			__stop___markers, probe_module, &refcount);

+ * @pdata: probe private data
+ *
+ * Unregister a marker by providing the registered pdata.
+ * Returns the pdata given to marker_probe_register, or an ERR_PTR().
+ */

kernel/marker.c new file +2 -0

+void *marker_probe_unregister_pdata(void *pdata)
+{

Quoted 7 lines · On Thu, 06 Sep 2007 16:07:34 -0400 Mathieu Desnoyers wrote:

Changelog:
- markers_mutex now nests inside module_mutex rather than the opposite.

Signed-off-by Mathieu Desnoyers <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by Rusty Russell <[email protected]>

Reviewed-by "Frank Ch. Eigler" <[email protected]>

Documentation/SubmittingPatches recognizes Signed-off-by: and Acked-by:. Nothing about Reviewed-by. Quote:

Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance.

Reviewed-by: carries no such connotation or indication IMO. Please use Acked-by if that's what these reviewers have done.

Quoted 17 lines · On Thu, 6 Sep 2007 16:00:01 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 7 lines · On Thu, 06 Sep 2007 16:07:34 -0400 Mathieu Desnoyers wrote:

Changelog:
- markers_mutex now nests inside module_mutex rather than the opposite.

Signed-off-by Mathieu Desnoyers <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by Rusty Russell <[email protected]>

Reviewed-by "Frank Ch. Eigler" <[email protected]>

Documentation/SubmittingPatches recognizes Signed-off-by: and Acked-by:. Nothing about Reviewed-by. Quote:

Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance.

Quoted 2 lines

Reviewed-by: carries no such connotation or indication IMO. Please use Acked-by if that's what these reviewers have done.

Yeah. We will start introducing Reviewed-by: (I haven't yet quite worked out how yet) but it will be a quite formal thing and it would be something which the reviewer explicitly provided. For now, let's please stick with acked-by (if those individuals did indeed send an acked-by)
-

This patch:

Add Kconfig menus for the marker code.

[[email protected]: Never ever select MODULES]

Signed-off-by Mathieu Desnoyers <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by "Frank Ch. Eigler" <[email protected]>

CC Adrian Bunk <[email protected]>

---

 arch/alpha/Kconfig       |    2 ++
 arch/arm/Kconfig         |    2 ++
 arch/avr32/Kconfig.debug |    7 +++++++
 arch/cris/Kconfig        |    2 ++
 arch/frv/Kconfig         |    2 ++
 arch/h8300/Kconfig       |    2 ++
 arch/i386/Kconfig        |    2 ++
 arch/ia64/Kconfig        |    2 ++
 arch/m32r/Kconfig        |    2 ++
 arch/m68k/Kconfig        |    2 ++
 arch/m68knommu/Kconfig   |    2 ++
 arch/mips/Kconfig        |    2 ++
 arch/parisc/Kconfig      |    2 ++
 arch/powerpc/Kconfig     |    2 ++
 arch/ppc/Kconfig         |    2 ++
 arch/s390/Kconfig        |    2 ++
 arch/sh/Kconfig          |    2 ++
 arch/sh64/Kconfig        |    2 ++
 arch/sparc/Kconfig       |    2 ++
 arch/sparc64/Kconfig     |    2 ++
 arch/um/Kconfig          |    2 ++
 arch/v850/Kconfig        |    2 ++
 arch/x86_64/Kconfig      |    2 ++
 arch/xtensa/Kconfig      |    2 ++
 kernel/Kconfig.marker    |    7 +++++++
 kernel/Makefile          |    1 +
 26 files changed, 61 insertions(+)

Index: linux-2.6-lttng/arch/alpha/Kconfig
===================================================================

arch/alpha/Kconfig +2 -0

@@ -646,6 +646,8 @@ config SRM_ENV
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"

Index: linux-2.6-lttng/kernel/Kconfig.marker
===================================================================

kernel/Kconfig.marker new file +7 -0

@@ -0,0 +1,7 @@
+# Code markers configuration
+
+config MARKERS
+	bool "Activate markers"
+	help
+	  Place an empty function call at each marker site. Can be
+	  dynamically changed for a probe function.

Index: linux-2.6-lttng/arch/avr32/Kconfig.debug
===================================================================

arch/avr32/Kconfig.debug +3 -0

@@ -6,6 +6,9 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+menu "Instrumentation Support"
+	depends on EXPERIMENTAL
+
 config KPROBES
 	bool "Kprobes"
 	depends on DEBUG_KERNEL

Here is some documentation explaining what is/how to use the Linux Kernel Markers.
---

 Documentation/marker.txt |  257 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 257 insertions(+)

Index: linux-2.6-lttng/Documentation/marker.txt
===================================================================

Documentation/marker.txt new file +3 -0

@@ -0,0 +1,257 @@
+ 	             Using the Linux Kernel Markers
+
+			    Mathieu Desnoyers

Documentation/marker.txt new file +11 -0

+instrumented function and adds a data structure in a separate section). The
+immediate values are used to minimize the impact on data cache, encoding the
+condition in the instruction stream. When a marker is "on", the function you
+provide is called each time the marker is executed, in the execution context of
+the caller. When the function provided ends its execution, it returns to the
+caller (continuing from the marker site).
+
+You can put markers at important locations in the code. Markers are
+lightweight hooks that can pass an arbitrary number of parameters,
+described in a printk-like format string, to the attached probe function.
+

Documentation/marker.txt new file +34 -0

+
+trace_mark(subsystem_event, "%d %s", someint, somestring);
+Where :
+- subsystem_event is an identifier unique to your event
+    - subsystem is the name of your subsystem.
+    - event is the name of the event to mark.
+- "%d %s" is the formatted string for the serializer.
+- someint is an integer.
+- somestring is a char pointer.
+
+Connecting a function (probe) to a marker is done by providing a probe (function
+to call) for the specific marker through marker_probe_register() and can be
+activated by calling marker_arm(). Marker deactivation can be done by calling
+marker_disarm() as many times as marker_arm() has been called. Removing a probe
+is done through marker_probe_unregister(); it will disarm the probe and make
+sure there is no caller left using the probe when it returns. Probe removal is
+preempt-safe because preemption is disabled around the probe call. See the
+"Probe example" section below for a sample probe module.
+
+The marker mechanism supports inserting multiple instances of the same marker.
+Markers can be put in inline functions, inlined static functions, and
+unrolled loops.
+
+The naming scheme "subsystem_event" is suggested here as a convention intended
+to limit collisions. Marker names are global to the kernel: they are considered
+as being the same whether they are in the core kernel image or in modules.
+Conflicting format strings for markers with the same name will cause the markers
+to be detected to have a different format string not to be armed and will output
+a printk warning which identifies the inconsistency:
+
+"Format mismatch for probe probe_name (format), marker (format)"
+
+
+* Optimization for a given architecture

Documentation/marker.txt new file +164 -0

+You can build the kernel modules, probe-example.ko and marker-example.ko,
+using the following Makefile:
+------------------------------ CUT -------------------------------------
+obj-m := probe-example.o marker-example.o
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
+default:
+	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+clean:
+	rm -f *.mod.c *.ko *.o
+------------------------------ CUT -------------------------------------
+/* probe-example.c
+ *
+ * Connects two functions to marker call sites.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/sched.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/marker.h>
+#include <asm/atomic.h>
+
+struct probe_data {
+	const char *name;
+	const char *format;
+	marker_probe_func *probe_func;
+};
+
+void probe_subsystem_event(const struct __mark_marker *mdata,
+		const char *format, ...)
+{
+	va_list ap;
+	/* Declare args */
+	unsigned int value;
+	const char *mystr;
+
+	/* Assign args */
+	va_start(ap, format);
+	value = va_arg(ap, typeof(value));
+	mystr = va_arg(ap, typeof(mystr));
+
+	/* Call printk */
+	printk("Value %u, string %s\n", value, mystr);
+
+	/* or count, check rights, serialize data in a buffer */
+
+	va_end(ap);
+}
+
+atomic_t eventb_count = ATOMIC_INIT(0);
+
+void probe_subsystem_eventb(const struct __mark_marker *mdata,
+	const char *format, ...)
+{
+	/* Increment counter */
+	atomic_inc(&eventb_count);
+}
+
+static struct probe_data probe_array[] =
+{
+	{	.name = "subsystem_event",
+		.format = "%d %s",
+		.probe_func = probe_subsystem_event },
+	{	.name = "subsystem_eventb",
+		.format = MARK_NOARGS,
+		.probe_func = probe_subsystem_eventb },
+};
+
+static int __init probe_init(void)
+{
+	int result;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		result = marker_probe_register(probe_array[i].name,
+				probe_array[i].format,
+				probe_array[i].probe_func, &probe_array[i]);
+		if (result)
+			printk(KERN_INFO "Unable to register probe %s\n",
+				probe_array[i].name);
+		result = marker_arm(probe_array[i].name);
+		if (result)
+			printk(KERN_INFO "Unable to arm probe %s\n",
+				probe_array[i].name);
+	}
+	return 0;
+}
+
+static void __exit probe_fini(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		marker_probe_unregister(probe_array[i].name);
+	}
+	printk("Number of event b : %u\n", atomic_read(&eventb_count));
+}
+
+module_init(probe_init);
+module_exit(probe_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");
+MODULE_DESCRIPTION("SUBSYSTEM Probe");
+------------------------------ CUT -------------------------------------
+/* marker-example.c
+ *
+ * Executes a marker when /proc/marker-example is opened.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/marker.h>
+#include <linux/sched.h>
+#include <linux/proc_fs.h>
+
+struct proc_dir_entry *pentry_example = NULL;
+
+static int my_open(struct inode *inode, struct file *file)
+{
+	int i;
+
+	trace_mark(subsystem_event, "%d %s", 123, "example string");
+	for (i=0; i<10; i++) {
+		trace_mark(subsystem_eventb, MARK_NOARGS);
+	}
+	return -EPERM;
+}
+
+static struct file_operations mark_ops = {
+	.open = my_open,
+};
+
+static int example_init(void)
+{
+	printk(KERN_ALERT "example init\n");
+	pentry_example = create_proc_entry("marker-example", 0444, NULL);
+	if (pentry_example)
+		pentry_example->proc_fops = &mark_ops;
+	else
+		return -EPERM;
+	return 0;
+}
+
+static void example_exit(void)
+{
+	printk(KERN_ALERT "example exit\n");
+	remove_proc_entry("marker-example", NULL);
+}
+
+module_init(example_init)
+module_exit(example_exit)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");

Thanks. I look forward to the explanation of Reviewed-by, what it means, and how it differs from Acked-by.

Quoted 2 lines · Randy Dunlap

Thanks. I look forward to the explanation of Reviewed-by, what it means, and how it differs from Acked-by.

As long as you're at it, the only tag *I* seem to need is 'Tested-By:' :)

kernel/marker.c line 214

Quoted 9 lines

kernel/marker.c new file +8 -0

+/*
+ * Sets the probe callback corresponding to one marker.
+ */
+static int set_marker(struct marker_entry **entry,
+			struct __mark_marker *elem)
+{
+	int ret;
+	BUG_ON(strcmp((*entry)->name, elem->name) != 0);

You can't return -ENOENT here?

Quoted 13 lines

kernel/marker.c new file +13 -0

+#ifdef CONFIG_MODULES
+/*
+ * Update module probes.
+ * Must be called with markers_mutex held.
+ */
+static inline void marker_update_probes_modules(struct module *probe_module,
+	int *refcount)
+{
+	struct module *mod;
+
+	list_for_each_entry(mod, &modules, list) {
+		if (!mod->taints) {
+			marker_update_probe_range(mod->markers,

kernel/marker.c line 301

Quoted 5 lines

kernel/marker.c new file +5 -0

+				mod->markers+mod->num_markers,
+				probe_module, refcount);
+		}
+	}
+}

hm, so if the module is tainted, markers won't be applied to it? That's OK IMO.

However, I tend to think that something that
modifies code on the fly (like kprobes or text edit) should set some flag somewhere so that when the system crashes, we can know that code was modified. This could be done via taints flags or some other mechanism. Has this already been discussed?

Thanks. I look forward to the explanation of Reviewed-by, what it means, and how it differs from Acked-by.

This was proposed by Andrew and discussed at the Kernel Summit; the basic idea is that it is a formal indication that the person has done a *full* review of the patch (a few random comments from the local whitespace police don't count),

Anybody got a proposed scheme for the case where somebody like myself who is *not* a member of the Maintainer Cabal has looked at a patch, and found a valid show-stopper that's bigger than just whitespace (breaks on 64-bit, locking issues, etc), or other commentary that *should* be addressed before it gets merged? I'd like *some* way to tag a patch with "I had an issue with V1, but the author addressed it to my satisfaction in V2"....

(Note that includes "the author convinced me the patch was right and I was wrong"...)

Quoted 6 lines

Anybody got a proposed scheme for the case where somebody like myself who is *not* a member of the Maintainer Cabal has looked at a patch, and found a valid show-stopper that's bigger than just whitespace (breaks on 64-bit, locking issues, etc), or other commentary that *should* be addressed before it gets merged? I'd like *some* way to tag a patch with "I had an issue with V1, but the author addressed it to my satisfaction in V2"....

I think that'd be Reviewed-By. While you are not part of the smokey room cabal you have shown technical expertise in various areas so it seems perfectly fine to have reviewed-by from you. The fix vs a previous version should probably be just in the text with a paragraph ala:

Issue blah in a previous version as found by Valdis Kletnieks has been fixed by doing foo.

Andrew, any chance to get this into -mm ASAP so we can have it in 2.6.24?

Just in case anyone wonders what this is usefulfor I've ported my hacking spu tracing code to it, and if markers get in I'd push a cleaned up version of this in the tree of the benefit of everyone trying to follow what's going on in the spufs code. Similarly I'd like to port the xfs tracing code over to it which is very helpful in trying to debug filesystem issues.

Note that in this patch the actual logging code is rather nasty hand-crafted code lifted from the tcp probe in tree which would benefit of going away in favour of more general tracing code aswell.

Changelog:
- Porting to 2.6.23-rc4-mm1 gave a reject (a trace point location disappeared) from spufs_ps_nopfn() : spufs_ps_nopfn__sleep and spufs_ps_nopfn__wake.

Signed-off-by Mathieu Desnoyers <[email protected]>

Quoted 14 lines · Mathieu Desnoyers

Andrew, any chance to get this into -mm ASAP so we can have it in 2.6.24?

Just in case anyone wonders what this is usefulfor I've ported my hacking spu tracing code to it, and if markers get in I'd push a cleaned up version of this in the tree of the benefit of everyone trying to follow what's going on in the spufs code. Similarly I'd like to port the xfs tracing code over to it which is very helpful in trying to debug filesystem issues.

Note that in this patch the actual logging code is rather nasty hand-crafted code lifted from the tcp probe in tree which would benefit of going away in favour of more general tracing code aswell.

Quoted 4 lines

Changelog:
- Porting to 2.6.23-rc4-mm1 gave a reject (a trace point location disappeared) from spufs_ps_nopfn() : spufs_ps_nopfn__sleep and spufs_ps_nopfn__wake.

Signed-off-by Mathieu Desnoyers <[email protected]>

Where are Christoph's attributions?

Andrew, any chance to get this into -mm ASAP so we can have it in 2.6.24?

Just in case anyone wonders what this is usefulfor I've ported my hacking spu tracing code to it, and if markers get in I'd push a cleaned up version of this in the tree of the benefit of everyone trying to follow what's going on in the spufs code. Similarly I'd like to port the xfs tracing code over to it which is very helpful in trying to debug filesystem issues.

Note that in this patch the actual logging code is rather nasty hand-crafted code lifted from the tcp probe in tree which would benefit of going away in favour of more general tracing code aswell.

Changelog:
- Porting to 2.6.23-rc4-mm1 gave a reject (a trace point location disappeared) from spufs_ps_nopfn() : spufs_ps_nopfn__sleep and spufs_ps_nopfn__wake.

On Thu, 06 Sep 2007 16:07:35 -0400 Mathieu Desnoyers wrote:

[snip]

Quoted 79 lines

This patch:

Add Kconfig menus for the marker code.

[[email protected]: Never ever select MODULES]

Signed-off-by Mathieu Desnoyers <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by "Frank Ch. Eigler" <[email protected]>

CC Adrian Bunk <[email protected]>

---

 arch/alpha/Kconfig       |    2 ++
 arch/arm/Kconfig         |    2 ++
 arch/avr32/Kconfig.debug |    7 +++++++
 arch/cris/Kconfig        |    2 ++
 arch/frv/Kconfig         |    2 ++
 arch/h8300/Kconfig       |    2 ++
 arch/i386/Kconfig        |    2 ++
 arch/ia64/Kconfig        |    2 ++
 arch/m32r/Kconfig        |    2 ++
 arch/m68k/Kconfig        |    2 ++
 arch/m68knommu/Kconfig   |    2 ++
 arch/mips/Kconfig        |    2 ++
 arch/parisc/Kconfig      |    2 ++
 arch/powerpc/Kconfig     |    2 ++
 arch/ppc/Kconfig         |    2 ++
 arch/s390/Kconfig        |    2 ++
 arch/sh/Kconfig          |    2 ++
 arch/sh64/Kconfig        |    2 ++
 arch/sparc/Kconfig       |    2 ++
 arch/sparc64/Kconfig     |    2 ++
 arch/um/Kconfig          |    2 ++
 arch/v850/Kconfig        |    2 ++
 arch/x86_64/Kconfig      |    2 ++
 arch/xtensa/Kconfig      |    2 ++
 kernel/Kconfig.marker    |    7 +++++++
 kernel/Makefile          |    1 +
 26 files changed, 61 insertions(+)

Index: linux-2.6-lttng/arch/alpha/Kconfig
===================================================================

arch/alpha/Kconfig +2 -0

@@ -646,6 +646,8 @@ config SRM_ENV
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"

Index: linux-2.6-lttng/kernel/Kconfig.marker
===================================================================

kernel/Kconfig.marker new file +7 -0

@@ -0,0 +1,7 @@
+# Code markers configuration
+
+config MARKERS
+	bool "Activate markers"
+	help
+	  Place an empty function call at each marker site. Can be
+	  dynamically changed for a probe function.

Index: linux-2.6-lttng/arch/avr32/Kconfig.debug
===================================================================

arch/avr32/Kconfig.debug +3 -0

@@ -6,6 +6,9 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+menu "Instrumentation Support"
+	depends on EXPERIMENTAL
+
 config KPROBES
 	bool "Kprobes"
 	depends on DEBUG_KERNEL

arch/avr32/Kconfig.debug config KPROBES · line 26

Quoted 8 lines

arch/avr32/Kconfig.debug +4 -0

@@ -16,4 +19,8 @@ config KPROBES
           for kernel debugging, non-intrusive instrumentation and testing.
           If in doubt, say "N".
 
+source "kernel/Kconfig.marker"
+
+endmenu
+
 endmenu

It seems sad that this patch sources Kconfig.marker, a 7-line file, 20-something times. Yes, you (we) don't want to put those 7 lines into 20-something different files, so sourcing is the right thing.

However, what you did for avr32 seems more on the right track to me:
make _one_ Instrumentation support menu that includes PROFILING, OPROFILE, KPROBES, and MARKERS and then use (source) that in all of the arches.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***