Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
* Dmitry Torokhov [2018-08-20 12:33:50]:
> On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > Lots of stupid modules can do dumb things. Just don't do that. The
> > kernel is not built to keep you from doing stupid things in kernel code
> > :)
> >
> > So I fail to see why this patch is needed. What in-kernel code path is
> > trying to print a kobject's name before it is initialized? Why not fix
> > that obvious bug instead of forcing the kernel core to protect from
> > stupid code?
>
> Kay decided to add some guards in:
>
> commit 0f4dafc0563c6c49e17fe14b3f5f356e4c4b8806
> Author: Kay Sievers
> Date: Wed Dec 19 01:40:42 2007 +0100
>
>Kobject: auto-cleanup on final unref
> ...
>
> + if (!kobj->state_initialized) {
> + printk(KERN_ERR "kobject '%s' (%p): tried to add an "
> + "uninitialized object, something is seriously
> wrong.\n",
> + kobject_name(kobj), kobj);
> + dump_stack();
> + return -EINVAL;
>
> Given that we have dump_stack() we can probably simply drop
> kobject_name(kobj) instead of building even more elaborate checks. Or
> just drop the whole check. Adding kobjects is somewhat uncommon
> operation, plus "gabage in, garbage out".
>
Dropping the kobject_name(kobj) should also be okay.
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
* Dmitry Torokhov [2018-08-20 12:33:50]:
> On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > Lots of stupid modules can do dumb things. Just don't do that. The
> > kernel is not built to keep you from doing stupid things in kernel code
> > :)
> >
> > So I fail to see why this patch is needed. What in-kernel code path is
> > trying to print a kobject's name before it is initialized? Why not fix
> > that obvious bug instead of forcing the kernel core to protect from
> > stupid code?
>
> Kay decided to add some guards in:
>
> commit 0f4dafc0563c6c49e17fe14b3f5f356e4c4b8806
> Author: Kay Sievers
> Date: Wed Dec 19 01:40:42 2007 +0100
>
>Kobject: auto-cleanup on final unref
> ...
>
> + if (!kobj->state_initialized) {
> + printk(KERN_ERR "kobject '%s' (%p): tried to add an "
> + "uninitialized object, something is seriously
> wrong.\n",
> + kobject_name(kobj), kobj);
> + dump_stack();
> + return -EINVAL;
>
> Given that we have dump_stack() we can probably simply drop
> kobject_name(kobj) instead of building even more elaborate checks. Or
> just drop the whole check. Adding kobjects is somewhat uncommon
> operation, plus "gabage in, garbage out".
>
Dropping the kobject_name(kobj) should also be okay.
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
* Greg Kroah-Hartman [2018-08-20 21:22:47]: > On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote: > > A stupid module test like > > https://github.com/srikard/tests/blob/master/modules/kobject_test.c > > can panic the system. > > Lots of stupid modules can do dumb things. Just don't do that. The > kernel is not built to keep you from doing stupid things in kernel code > :) > Completely agree. kernel/module code is not for doing stupid things. However we seem to be hitting this once in a while in a weird case with a slightly older kernel with no out of tree modules. crash> bt PID: 54813 TASK: c00c4c76c160 CPU: 40 COMMAND: "lvm" #0 [c0004ac0eb50] crash_kexec at c01a1be4 #1 [c0004ac0eb80] die at c0025668 #2 [c0004ac0ec20] bad_page_fault at c005d7a0 #3 [c0004ac0ec90] handle_page_fault at c0009608 Data Access [300] exception frame: R0: c0521cb4R1: c0004ac0ef80R2: c1274800 R3: 0002R4: R5: 0002 R6: R7: R8: R9: 0004R10: c0521c90R11: c1434800 R12: c00e3750R13: c7b16800R14: 3fff85970520 R15: 3fffd442c6c0R16: R17: 005c R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400 R21: 0100333c23d0R22: 0025R23: c143a648 R24: 03e0R25: 0020R26: c0004ac0f140 R27: R28: 0002R29: R30: c143aa28R31: c143a654 NIP: c051bda8MSR: 80019033OR3: c00093ec CTR: c0521c90LR: c051e7b8XER: CCR: 88048444MQ: DAR: 0002 DSISR: 4000 Syscall Result: #4 [c0004ac0ef80] strnlen at c051bda8 [Link Register] [c0004ac0ef80] string at c051e7b8 #5 [c0004ac0efd0] vsnprintf at c0521cb4 #6 [c0004ac0f050] vscnprintf at c05226e0 #7 [c0004ac0f080] vprintk_default at c00e381c #8 [c0004ac0f0f0] printk at c0a2047c #9 [c0004ac0f110] kobject_put at c0510c34 #10 [c0004ac0f1a0] of_node_put at c0813034 #11 [c0004ac0f1c0] pci_release_of_node at c05ae724 #12 [c0004ac0f1f0] pci_release_dev at c056ff60 #13 [c0004ac0f220] device_release at c065a468 #14 [c0004ac0f2a0] kobject_put at c0510abc #15 [c0004ac0f330] put_device at c065aaf4 #16 [c0004ac0f350] scsi_host_dev_release at c06a2f10 #17 [c0004ac0f390] device_release at c065a468 #18 [c0004ac0f410] kobject_put at c0510abc #19 [c0004ac0f4a0] put_device at c065aaf4 #20 [c0004ac0f4c0] scsi_target_dev_release at c06b2bb4 #21 [c0004ac0f4f0] device_release at c065a468 #22 [c0004ac0f570] kobject_put at c0510abc #23 [c0004ac0f600] put_device at c065aaf4 #24 [c0004ac0f620] scsi_device_dev_release_usercontext at c06b8790 #25 [c0004ac0f670] execute_in_process_context at c01185b4 #26 [c0004ac0f6a0] scsi_device_dev_release at c06b8644 #27 [c0004ac0f6c0] device_release at c065a468 #28 [c0004ac0f740] kobject_put at c0510abc #29 [c0004ac0f7d0] put_device at c065aaf4 #30 [c0004ac0f7f0] scsi_device_put at c069ff98 #31 [c0004ac0f820] sd_release at d8013f4c [sd_mod] #32 [c0004ac0f8a0] __blkdev_put at c03a7318 #33 [c0004ac0f900] dm_put_table_device at d6ed09fc [dm_mod] #34 [c0004ac0f940] dm_put_device at d6ed663c [dm_mod] #35 [c0004ac0f9b0] linear_dtr at d6eda2d4 [dm_mod] #36 [c0004ac0f9e0] dm_table_destroy at d6ed7380 [dm_mod] #37 [c0004ac0fa70] dev_suspend at d6edf114 [dm_mod] #38 [c0004ac0faf0] ctl_ioctl at d6edc2e0 [dm_mod] #39 [c0004ac0fcf0] dm_ctl_ioctl at d6edc548 [dm_mod] #40 [c0004ac0fd10] do_vfs_ioctl at c035a9a8 #41 [c0004ac0fdd0] sys_ioctl at c035aea4 #42 [c0004ac0fe30] system_call at c000a284 System Call [c00] exception frame: R0: 0036R1: 3fffd442c4b0R2: 3fff858a7400 R3: 0006R4: c138fd06R5: 0100333c23d0 R6: 0004R7: 3fff8597a2f0R8: 0006 R9: R10: R11: R12: R13: 3fff85b42ff0R14: 3fff85970520 R15: 3fffd442c6c0R16: R17: 005c R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400 R21: 0100333c23d0R22:
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
* Greg Kroah-Hartman [2018-08-20 21:22:47]: > On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote: > > A stupid module test like > > https://github.com/srikard/tests/blob/master/modules/kobject_test.c > > can panic the system. > > Lots of stupid modules can do dumb things. Just don't do that. The > kernel is not built to keep you from doing stupid things in kernel code > :) > Completely agree. kernel/module code is not for doing stupid things. However we seem to be hitting this once in a while in a weird case with a slightly older kernel with no out of tree modules. crash> bt PID: 54813 TASK: c00c4c76c160 CPU: 40 COMMAND: "lvm" #0 [c0004ac0eb50] crash_kexec at c01a1be4 #1 [c0004ac0eb80] die at c0025668 #2 [c0004ac0ec20] bad_page_fault at c005d7a0 #3 [c0004ac0ec90] handle_page_fault at c0009608 Data Access [300] exception frame: R0: c0521cb4R1: c0004ac0ef80R2: c1274800 R3: 0002R4: R5: 0002 R6: R7: R8: R9: 0004R10: c0521c90R11: c1434800 R12: c00e3750R13: c7b16800R14: 3fff85970520 R15: 3fffd442c6c0R16: R17: 005c R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400 R21: 0100333c23d0R22: 0025R23: c143a648 R24: 03e0R25: 0020R26: c0004ac0f140 R27: R28: 0002R29: R30: c143aa28R31: c143a654 NIP: c051bda8MSR: 80019033OR3: c00093ec CTR: c0521c90LR: c051e7b8XER: CCR: 88048444MQ: DAR: 0002 DSISR: 4000 Syscall Result: #4 [c0004ac0ef80] strnlen at c051bda8 [Link Register] [c0004ac0ef80] string at c051e7b8 #5 [c0004ac0efd0] vsnprintf at c0521cb4 #6 [c0004ac0f050] vscnprintf at c05226e0 #7 [c0004ac0f080] vprintk_default at c00e381c #8 [c0004ac0f0f0] printk at c0a2047c #9 [c0004ac0f110] kobject_put at c0510c34 #10 [c0004ac0f1a0] of_node_put at c0813034 #11 [c0004ac0f1c0] pci_release_of_node at c05ae724 #12 [c0004ac0f1f0] pci_release_dev at c056ff60 #13 [c0004ac0f220] device_release at c065a468 #14 [c0004ac0f2a0] kobject_put at c0510abc #15 [c0004ac0f330] put_device at c065aaf4 #16 [c0004ac0f350] scsi_host_dev_release at c06a2f10 #17 [c0004ac0f390] device_release at c065a468 #18 [c0004ac0f410] kobject_put at c0510abc #19 [c0004ac0f4a0] put_device at c065aaf4 #20 [c0004ac0f4c0] scsi_target_dev_release at c06b2bb4 #21 [c0004ac0f4f0] device_release at c065a468 #22 [c0004ac0f570] kobject_put at c0510abc #23 [c0004ac0f600] put_device at c065aaf4 #24 [c0004ac0f620] scsi_device_dev_release_usercontext at c06b8790 #25 [c0004ac0f670] execute_in_process_context at c01185b4 #26 [c0004ac0f6a0] scsi_device_dev_release at c06b8644 #27 [c0004ac0f6c0] device_release at c065a468 #28 [c0004ac0f740] kobject_put at c0510abc #29 [c0004ac0f7d0] put_device at c065aaf4 #30 [c0004ac0f7f0] scsi_device_put at c069ff98 #31 [c0004ac0f820] sd_release at d8013f4c [sd_mod] #32 [c0004ac0f8a0] __blkdev_put at c03a7318 #33 [c0004ac0f900] dm_put_table_device at d6ed09fc [dm_mod] #34 [c0004ac0f940] dm_put_device at d6ed663c [dm_mod] #35 [c0004ac0f9b0] linear_dtr at d6eda2d4 [dm_mod] #36 [c0004ac0f9e0] dm_table_destroy at d6ed7380 [dm_mod] #37 [c0004ac0fa70] dev_suspend at d6edf114 [dm_mod] #38 [c0004ac0faf0] ctl_ioctl at d6edc2e0 [dm_mod] #39 [c0004ac0fcf0] dm_ctl_ioctl at d6edc548 [dm_mod] #40 [c0004ac0fd10] do_vfs_ioctl at c035a9a8 #41 [c0004ac0fdd0] sys_ioctl at c035aea4 #42 [c0004ac0fe30] system_call at c000a284 System Call [c00] exception frame: R0: 0036R1: 3fffd442c4b0R2: 3fff858a7400 R3: 0006R4: c138fd06R5: 0100333c23d0 R6: 0004R7: 3fff8597a2f0R8: 0006 R9: R10: R11: R12: R13: 3fff85b42ff0R14: 3fff85970520 R15: 3fffd442c6c0R16: R17: 005c R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400 R21: 0100333c23d0R22:
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > If kobject state is not initialized, then its not even certain that
> > kobject'name is initialized. Hence when accessing the kobject's name
> > tread carefully.
> >
> > A stupid module test like
> > https://github.com/srikard/tests/blob/master/modules/kobject_test.c
> > can panic the system.
>
> Lots of stupid modules can do dumb things. Just don't do that. The
> kernel is not built to keep you from doing stupid things in kernel code
> :)
>
> So I fail to see why this patch is needed. What in-kernel code path is
> trying to print a kobject's name before it is initialized? Why not fix
> that obvious bug instead of forcing the kernel core to protect from
> stupid code?
Kay decided to add some guards in:
commit 0f4dafc0563c6c49e17fe14b3f5f356e4c4b8806
Author: Kay Sievers
Date: Wed Dec 19 01:40:42 2007 +0100
Kobject: auto-cleanup on final unref
...
+ if (!kobj->state_initialized) {
+ printk(KERN_ERR "kobject '%s' (%p): tried to add an "
+ "uninitialized object, something is seriously wrong.\n",
+ kobject_name(kobj), kobj);
+ dump_stack();
+ return -EINVAL;
Given that we have dump_stack() we can probably simply drop
kobject_name(kobj) instead of building even more elaborate checks. Or
just drop the whole check. Adding kobjects is somewhat uncommon
operation, plus "gabage in, garbage out".
Thanks.
--
Dmitry
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > If kobject state is not initialized, then its not even certain that
> > kobject'name is initialized. Hence when accessing the kobject's name
> > tread carefully.
> >
> > A stupid module test like
> > https://github.com/srikard/tests/blob/master/modules/kobject_test.c
> > can panic the system.
>
> Lots of stupid modules can do dumb things. Just don't do that. The
> kernel is not built to keep you from doing stupid things in kernel code
> :)
>
> So I fail to see why this patch is needed. What in-kernel code path is
> trying to print a kobject's name before it is initialized? Why not fix
> that obvious bug instead of forcing the kernel core to protect from
> stupid code?
Kay decided to add some guards in:
commit 0f4dafc0563c6c49e17fe14b3f5f356e4c4b8806
Author: Kay Sievers
Date: Wed Dec 19 01:40:42 2007 +0100
Kobject: auto-cleanup on final unref
...
+ if (!kobj->state_initialized) {
+ printk(KERN_ERR "kobject '%s' (%p): tried to add an "
+ "uninitialized object, something is seriously wrong.\n",
+ kobject_name(kobj), kobj);
+ dump_stack();
+ return -EINVAL;
Given that we have dump_stack() we can probably simply drop
kobject_name(kobj) instead of building even more elaborate checks. Or
just drop the whole check. Adding kobjects is somewhat uncommon
operation, plus "gabage in, garbage out".
Thanks.
--
Dmitry
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote: > If kobject state is not initialized, then its not even certain that > kobject'name is initialized. Hence when accessing the kobject's name > tread carefully. > > A stupid module test like > https://github.com/srikard/tests/blob/master/modules/kobject_test.c > can panic the system. Lots of stupid modules can do dumb things. Just don't do that. The kernel is not built to keep you from doing stupid things in kernel code :) So I fail to see why this patch is needed. What in-kernel code path is trying to print a kobject's name before it is initialized? Why not fix that obvious bug instead of forcing the kernel core to protect from stupid code? thanks, greg k-h
Re: [PATCH] kobject: Access kobject name with caution if state is not initialized
On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote: > If kobject state is not initialized, then its not even certain that > kobject'name is initialized. Hence when accessing the kobject's name > tread carefully. > > A stupid module test like > https://github.com/srikard/tests/blob/master/modules/kobject_test.c > can panic the system. Lots of stupid modules can do dumb things. Just don't do that. The kernel is not built to keep you from doing stupid things in kernel code :) So I fail to see why this patch is needed. What in-kernel code path is trying to print a kobject's name before it is initialized? Why not fix that obvious bug instead of forcing the kernel core to protect from stupid code? thanks, greg k-h
[PATCH] kobject: Access kobject name with caution if state is not initialized
If kobject state is not initialized, then its not even certain that
kobject'name is initialized. Hence when accessing the kobject's name
tread carefully.
A stupid module test like
https://github.com/srikard/tests/blob/master/modules/kobject_test.c
can panic the system.
With patch: We will see the correct warning.
[ 2058.129913] [ cut here ]
[ 2058.129919] kobject: ' ' (ad405b63): is not initialized, yet
kobject_get() is being called.
[ 2058.129938] WARNING: CPU: 58 PID: 18529 at
/home/srikar/work/linux.git/lib/kobject.c:620 kobject_get+0x90/0xb0
[ 2058.129946] Modules linked in: kobject_test(OE+) uio_pdrv_genirq(E) uio(E)
leds_powernv(E) powernv_op_panel(E) ipmi_powernv(E) ipmi_devintf(E)
powernv_rng(E) ibmpowernv(E) ipmi_msghandler(E) vmx_crypto(E)
crct10dif_vpmsum(E) sch_fq_codel(E) ip_tables(E) x_tables(E) autofs4(E) ses
enclosure scsi_transport_sas mlx4_ib mlx4_en ib_core lpfc crc32c_vpmsum
mlx4_core nvmet_fc nvmet nvme_fc ipr nvme_fabrics devlink scsi_transport_fc tg3
[last unloaded: module_test]
[ 2058.130014] CPU: 58 PID: 18529 Comm: insmod Tainted: GW OEL
4.18.0-master+ #3
[ 2058.130022] NIP: c0d5f530 LR: c0d5f52c CTR:
[ 2058.130029] REGS: c02fd32f3640 TRAP: 0700 Tainted: GW OEL
(4.18.0-master+)
[ 2058.130036] MSR: 92029033 CR:
48002282 XER: 2000
[ 2058.130054] CFAR: c0114e10 IRQMASK: 0
GPR00: c0d5f52c c02fd32f38c0 c17bc200
0057
GPR04: 0001 107e 92009033
00f2
GPR08: 0007 0007 0001
92001003
GPR12: 2200 c02e0d00
GPR16: c01e92e0
0100
GPR20: 0001 c1662e60 c1662ed8
c02feb4114a0
GPR24: 0001 c0dbd438 c1662ea0
c1662ec0
GPR28: c02fe5f0cea0 d0001ded03d0 c02fd32f39a0
c02fd32f39a0
[ 2058.130133] NIP [c0d5f530] kobject_get+0x90/0xb0
[ 2058.130140] LR [c0d5f52c] kobject_get+0x8c/0xb0
[ 2058.130146] Call Trace:
[ 2058.130150] [c02fd32f38c0] [c0d5f52c] kobject_get+0x8c/0xb0
(unreliable)
[ 2058.130159] [c02fd32f3940] [d0001ded0088]
kobject_test_init+0x80/0xb0 [kobject_test]
[ 2058.130168] [c02fd32f39f0] [c00101f8] do_one_initcall+0x58/0x240
[ 2058.130178] [c02fd32f3ab0] [c01ef2b0] do_init_module+0x90/0x260
[ 2058.130186] [c02fd32f3b40] [c01edec8] load_module+0x2d88/0x3320
[ 2058.130193] [c02fd32f3d20] [c01ee764] sys_finit_module+0xc4/0x130
[ 2058.130204] [c02fd32f3e30] [c000b288] system_call+0x5c/0x70
[ 2058.130210] Instruction dump:
[ 2058.130215] e89f 4b5b4c15 6000 2f83 419e0030 3c82ff8c 388491e0
3c62ff90
[ 2058.130228] 7fe5fb78 3863e9b0 4b3b5881 6000 <0fe0> e8010090 7c0803a6
4b88
[ 2058.130240] ---[ end trace 0f471c192555a013 ]---
[ 2070.084234] kobject_test module unloaded
Signed-off-by: Srikar Dronamraju
---
lib/kobject.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/lib/kobject.c b/lib/kobject.c
index 389829d3a1d1..2d65be37fd7b 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/**
* kobject_namespace - return @kobj's namespace tag
@@ -417,8 +418,11 @@ int kobject_add(struct kobject *kobj, struct kobject
*parent,
return -EINVAL;
if (!kobj->state_initialized) {
+ char tmp;
+ int ret = probe_kernel_address(kobject_name(kobj), tmp);
+
pr_err("kobject '%s' (%p): tried to add an uninitialized
object, something is seriously wrong.\n",
- kobject_name(kobj), kobj);
+ ret ? " " : kobject_name(kobj), kobj);
dump_stack();
return -EINVAL;
}
@@ -606,10 +610,14 @@ EXPORT_SYMBOL(kobject_del);
struct kobject *kobject_get(struct kobject *kobj)
{
if (kobj) {
- if (!kobj->state_initialized)
+ if (!kobj->state_initialized) {
+ char tmp;
+ int ret = probe_kernel_address(kobject_name(kobj), tmp);
+
WARN(1, KERN_WARNING
"kobject: '%s' (%p): is not initialized, yet
kobject_get() is being called.\n",
-kobject_name(kobj), kobj);
+ret ? " " : kobject_name(kobj), kobj);
+ }
kref_get(>kref);
}
return kobj;
@@ -701,10 +709,14 @@ static void kobject_release(struct kref *kref)
void kobject_put(struct kobject *kobj)
{
if (kobj) {
-
[PATCH] kobject: Access kobject name with caution if state is not initialized
If kobject state is not initialized, then its not even certain that
kobject'name is initialized. Hence when accessing the kobject's name
tread carefully.
A stupid module test like
https://github.com/srikard/tests/blob/master/modules/kobject_test.c
can panic the system.
With patch: We will see the correct warning.
[ 2058.129913] [ cut here ]
[ 2058.129919] kobject: ' ' (ad405b63): is not initialized, yet
kobject_get() is being called.
[ 2058.129938] WARNING: CPU: 58 PID: 18529 at
/home/srikar/work/linux.git/lib/kobject.c:620 kobject_get+0x90/0xb0
[ 2058.129946] Modules linked in: kobject_test(OE+) uio_pdrv_genirq(E) uio(E)
leds_powernv(E) powernv_op_panel(E) ipmi_powernv(E) ipmi_devintf(E)
powernv_rng(E) ibmpowernv(E) ipmi_msghandler(E) vmx_crypto(E)
crct10dif_vpmsum(E) sch_fq_codel(E) ip_tables(E) x_tables(E) autofs4(E) ses
enclosure scsi_transport_sas mlx4_ib mlx4_en ib_core lpfc crc32c_vpmsum
mlx4_core nvmet_fc nvmet nvme_fc ipr nvme_fabrics devlink scsi_transport_fc tg3
[last unloaded: module_test]
[ 2058.130014] CPU: 58 PID: 18529 Comm: insmod Tainted: GW OEL
4.18.0-master+ #3
[ 2058.130022] NIP: c0d5f530 LR: c0d5f52c CTR:
[ 2058.130029] REGS: c02fd32f3640 TRAP: 0700 Tainted: GW OEL
(4.18.0-master+)
[ 2058.130036] MSR: 92029033 CR:
48002282 XER: 2000
[ 2058.130054] CFAR: c0114e10 IRQMASK: 0
GPR00: c0d5f52c c02fd32f38c0 c17bc200
0057
GPR04: 0001 107e 92009033
00f2
GPR08: 0007 0007 0001
92001003
GPR12: 2200 c02e0d00
GPR16: c01e92e0
0100
GPR20: 0001 c1662e60 c1662ed8
c02feb4114a0
GPR24: 0001 c0dbd438 c1662ea0
c1662ec0
GPR28: c02fe5f0cea0 d0001ded03d0 c02fd32f39a0
c02fd32f39a0
[ 2058.130133] NIP [c0d5f530] kobject_get+0x90/0xb0
[ 2058.130140] LR [c0d5f52c] kobject_get+0x8c/0xb0
[ 2058.130146] Call Trace:
[ 2058.130150] [c02fd32f38c0] [c0d5f52c] kobject_get+0x8c/0xb0
(unreliable)
[ 2058.130159] [c02fd32f3940] [d0001ded0088]
kobject_test_init+0x80/0xb0 [kobject_test]
[ 2058.130168] [c02fd32f39f0] [c00101f8] do_one_initcall+0x58/0x240
[ 2058.130178] [c02fd32f3ab0] [c01ef2b0] do_init_module+0x90/0x260
[ 2058.130186] [c02fd32f3b40] [c01edec8] load_module+0x2d88/0x3320
[ 2058.130193] [c02fd32f3d20] [c01ee764] sys_finit_module+0xc4/0x130
[ 2058.130204] [c02fd32f3e30] [c000b288] system_call+0x5c/0x70
[ 2058.130210] Instruction dump:
[ 2058.130215] e89f 4b5b4c15 6000 2f83 419e0030 3c82ff8c 388491e0
3c62ff90
[ 2058.130228] 7fe5fb78 3863e9b0 4b3b5881 6000 <0fe0> e8010090 7c0803a6
4b88
[ 2058.130240] ---[ end trace 0f471c192555a013 ]---
[ 2070.084234] kobject_test module unloaded
Signed-off-by: Srikar Dronamraju
---
lib/kobject.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/lib/kobject.c b/lib/kobject.c
index 389829d3a1d1..2d65be37fd7b 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/**
* kobject_namespace - return @kobj's namespace tag
@@ -417,8 +418,11 @@ int kobject_add(struct kobject *kobj, struct kobject
*parent,
return -EINVAL;
if (!kobj->state_initialized) {
+ char tmp;
+ int ret = probe_kernel_address(kobject_name(kobj), tmp);
+
pr_err("kobject '%s' (%p): tried to add an uninitialized
object, something is seriously wrong.\n",
- kobject_name(kobj), kobj);
+ ret ? " " : kobject_name(kobj), kobj);
dump_stack();
return -EINVAL;
}
@@ -606,10 +610,14 @@ EXPORT_SYMBOL(kobject_del);
struct kobject *kobject_get(struct kobject *kobj)
{
if (kobj) {
- if (!kobj->state_initialized)
+ if (!kobj->state_initialized) {
+ char tmp;
+ int ret = probe_kernel_address(kobject_name(kobj), tmp);
+
WARN(1, KERN_WARNING
"kobject: '%s' (%p): is not initialized, yet
kobject_get() is being called.\n",
-kobject_name(kobj), kobj);
+ret ? " " : kobject_name(kobj), kobj);
+ }
kref_get(>kref);
}
return kobj;
@@ -701,10 +709,14 @@ static void kobject_release(struct kref *kref)
void kobject_put(struct kobject *kobj)
{
if (kobj) {
-
