1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
From haveblue@us.ibm.com Thu Mar 16 17:30:46 2006
From: Dave Hansen <haveblue@us.ibm.com>
Subject: warn when statically-allocated kobjects are used
Cc: gregkh@suse.de, Dave Hansen <haveblue@us.ibm.com>
Date: Thu, 16 Mar 2006 17:30:16 -0800
Message-Id: <20060317013016.5C643E69@localhost.localdomain>
One of the top ten sysfs problems is that users use statically
allocated kobjects. This patch reminds them that this is a
naughty thing.
One _really_ nice thing this patch does, is us the kallsyms
mechanism to print out exactly which symbol is being complained
about:
The kobject at, or inside devices_subsys+0x14/0x60 is not dynamically allocated.
There are not very many architectures that actually place a
_sdata or _data symbol in their vmlinux.lds.S. This patch
causes link errors in all these cases. Is there an
alternative symbol that we can use, or can we use weak
symbols and detect them, so that they are at least skipped?
Does kernel/kallsyms.c:is_kernel() do the trick, so that we
don't need to use the asm-generic/sections.h variables at all?
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/i386/kernel/vmlinux.lds.S | 2 +
lib/kobject.c | 43 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
--- gregkh-2.6.orig/arch/i386/kernel/vmlinux.lds.S
+++ gregkh-2.6/arch/i386/kernel/vmlinux.lds.S
@@ -35,6 +35,8 @@ SECTIONS
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { *(__ex_table) }
__stop___ex_table = .;
+ _sdata = .; /* End of text section */
+
RODATA
. = ALIGN(4);
--- gregkh-2.6.orig/lib/kobject.c
+++ gregkh-2.6/lib/kobject.c
@@ -15,6 +15,8 @@
#include <linux/module.h>
#include <linux/stat.h>
#include <linux/slab.h>
+#include <linux/kallsyms.h>
+#include <asm-generic/sections.h>
/**
* populate_dir - populate directory with attributes.
@@ -120,6 +122,46 @@ char *kobject_get_path(struct kobject *k
return path;
}
+#ifdef CONFIG_X86_32
+static int ptr_in_range(void *ptr, void *start, void *end)
+{
+ /*
+ * This should hopefully get rid of causing warnings
+ * if the architecture did not set one of the section
+ * variables up.
+ */
+ if (start >= end)
+ return 0;
+
+ if ((ptr >= start) && (ptr < end))
+ return 1;
+ return 0;
+}
+
+static void verify_dynamic_kobject_allocation(struct kobject *kobj)
+{
+ if (ptr_in_range(kobj, &_sdata[0], &_edata[0]))
+ goto warn;
+ if (ptr_in_range(kobj, &__bss_start[0], &__bss_stop[0]))
+ goto warn;
+ return;
+warn:
+ pr_debug("---- begin silly warning ----\n");
+ pr_debug("This is a janitorial warning, not a kernel bug.\n");
+#ifdef CONFIG_DEBUG_KOBJECT
+ print_symbol("The kobject at, or inside %s is not dynamically allocated.\n",
+ (unsigned long)kobj);
+#endif
+ pr_debug("kobjects must be dynamically allocated, not static\n");
+ /* dump_stack(); */
+ pr_debug("---- end silly warning ----\n");
+}
+#else
+static void verify_dynamic_kobject_allocation(struct kobject *kobj)
+{
+}
+#endif
+
/**
* kobject_init - initialize object.
* @kobj: object in question.
@@ -127,6 +169,7 @@ char *kobject_get_path(struct kobject *k
void kobject_init(struct kobject * kobj)
{
WARN_ON(atomic_read(&kobj->kref.refcount));
+ verify_dynamic_kobject_allocation(kobj);
kref_init(&kobj->kref);
INIT_LIST_HEAD(&kobj->entry);
init_waitqueue_head(&kobj->poll);
|
