* kernel BUG at fs/sysfs/group.c:65!
@ 2014-10-09 12:43 Weng Meiling
2014-10-09 12:47 ` Weng Meiling
0 siblings, 1 reply; 4+ messages in thread
From: Weng Meiling @ 2014-10-09 12:43 UTC (permalink / raw)
To: Greg KH, tom.leiming, tj
Cc: tt.rantala, linux-kernel@vger.kernel.org, Huang Qiang, Li Zefan
Hi guys,
I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by duplicated sysfs link.
the detail mail:
https://lkml.org/lkml/2013/3/8/370
but it seems the problems has no conclusion. In our environment, we triggered the bug too, but for error ENOENT:
we use 3.4 kernel, and do virtual disk device create / remove for many times. Before remove we can see the devices:
#ll /sys/devices/virtual/block/
drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-1a
drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-2a
when the two virtual devices were removed, the directory block/ was delete too.
after many times create / remove, the kernel trigger the bug (just the main call trace):
[ 3965.441713] WARNING: at /usr/src/packages/BUILD/linux-3.4/lib/kobject.c:202 kobject_add_internal+0x11f/0x280()
[ 3965.441716] Hardware name: Romley
[ 3965.441718] kobject_add_internal failed for sd-1a (error: -2 parent: block)
[ 3965.441817] Call Trace:
[ 3965.441820] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
[ 3965.441823] [<ffffffff81037251>] warn_slowpath_fmt+0x41/0x50
[ 3965.441826] [<ffffffff81215e0f>] kobject_add_internal+0x11f/0x280
[ 3965.441830] [<ffffffff81216267>] kobject_add+0x67/0xc0
[ 3965.441833] [<ffffffff812d2305>] device_add+0x105/0x6d0
[ 3965.441836] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
[ 3965.441839] [<ffffffff812030ac>] add_disk+0x1bc/0x490
[ 3965.441912] kernel BUG at /usr/src/packages/BUILD/linux-3.4/fs/sysfs/group.c:65!
[ 3965.441915] invalid opcode: 0000 [#1] SMP
[ 3965.686738] Call Trace:
[ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
[ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
[ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
[ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490
from the error "kobject_add_internal failed for sd-1a (error: -2 parent: block)", we found that the first
warning was caused by the disk device's parent_sd was null when it was added into sysfs:
int sysfs_create_dir(struct kobject * kobj)
{
...
if (kobj->parent)
parent_sd = kobj->parent->sd;
else
parent_sd = &sysfs_root;
if (!parent_sd)
return -ENOENT;
...
}
The virtual disk device was not added into sysfs because of the above failure, and the kobj->sd was
not set, then trigger the bug when creating attribute group under the device's directory:
static int internal_create_group(struct kobject *kobj, int update,
const struct attribute_group *grp)
{
...
BUG_ON(!kobj || (!update && !kobj->sd));
...
}
Walk the code, it seems there maybe a race between block/ remove and virtual disk devices' register:
when the two virtual devices were removed, the block/ directory's refcount became 0, will into:
path0(remove the block/) path1(register virtual device sd-1a)
kobject_del(){ get_device_parent(){
... ...
sysfs_remove_dir(kobj); //kobj->sd=0 spin_lock(&dev->class->p->glue_dirs.list_lock);
... <========= list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) //get parent kobject from kset list
kobj_kset_leave(kobj); //remove kobj from kset list ...
} }
If getting parent object between " kobj->sd=0 " and "remove_kset_leave(kobj)", the sysfs_create_dir() will return ENOENT and trigger the BUG later.
The lastest kernel seems to be the same. But I am not familiar with block device, I am not sure whether the analysis is right or I am missing something.
what do you think about this situation? Any suggestion is appreciative. Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel BUG at fs/sysfs/group.c:65!
2014-10-09 12:43 kernel BUG at fs/sysfs/group.c:65! Weng Meiling
@ 2014-10-09 12:47 ` Weng Meiling
2014-10-11 3:00 ` Weng Meiling
0 siblings, 1 reply; 4+ messages in thread
From: Weng Meiling @ 2014-10-09 12:47 UTC (permalink / raw)
To: Greg KH, tom.leiming, tj
Cc: tt.rantala, linux-kernel@vger.kernel.org, Huang Qiang, Li Zefan
On 2014/10/9 20:43, Weng Meiling wrote:
> Hi guys,
>
> I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by duplicated sysfs link.
>
> the detail mail:
>
> https://lkml.org/lkml/2013/3/8/370
>
> but it seems the problems has no conclusion. In our environment, we triggered the bug too, but for error ENOENT:
>
> we use 3.4 kernel, and do virtual disk device create / remove for many times. Before remove we can see the devices:
>
> #ll /sys/devices/virtual/block/
> drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-1a
> drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-2a
>
> when the two virtual devices were removed, the directory block/ was delete too.
>
> after many times create / remove, the kernel trigger the bug (just the main call trace):
>
> [ 3965.441713] WARNING: at /usr/src/packages/BUILD/linux-3.4/lib/kobject.c:202 kobject_add_internal+0x11f/0x280()
> [ 3965.441716] Hardware name: Romley
> [ 3965.441718] kobject_add_internal failed for sd-1a (error: -2 parent: block)
>
> [ 3965.441817] Call Trace:
> [ 3965.441820] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
> [ 3965.441823] [<ffffffff81037251>] warn_slowpath_fmt+0x41/0x50
> [ 3965.441826] [<ffffffff81215e0f>] kobject_add_internal+0x11f/0x280
> [ 3965.441830] [<ffffffff81216267>] kobject_add+0x67/0xc0
> [ 3965.441833] [<ffffffff812d2305>] device_add+0x105/0x6d0
> [ 3965.441836] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
> [ 3965.441839] [<ffffffff812030ac>] add_disk+0x1bc/0x490
>
> [ 3965.441912] kernel BUG at /usr/src/packages/BUILD/linux-3.4/fs/sysfs/group.c:65!
> [ 3965.441915] invalid opcode: 0000 [#1] SMP
> [ 3965.686738] Call Trace:
> [ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
> [ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
> [ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
> [ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490
>
> from the error "kobject_add_internal failed for sd-1a (error: -2 parent: block)", we found that the first
> warning was caused by the disk device's parent_sd was null when it was added into sysfs:
>
> int sysfs_create_dir(struct kobject * kobj)
> {
> ...
> if (kobj->parent)
> parent_sd = kobj->parent->sd;
> else
> parent_sd = &sysfs_root;
>
> if (!parent_sd)
> return -ENOENT;
> ...
> }
>
> The virtual disk device was not added into sysfs because of the above failure, and the kobj->sd was
> not set, then trigger the bug when creating attribute group under the device's directory:
>
> static int internal_create_group(struct kobject *kobj, int update,
> const struct attribute_group *grp)
> {
> ...
> BUG_ON(!kobj || (!update && !kobj->sd));
> ...
> }
>
> Walk the code, it seems there maybe a race between block/ remove and virtual disk devices' register:
>
> when the two virtual devices were removed, the block/ directory's refcount became 0, will into:
>
> path0(remove the block/) path1(register virtual device sd-1a)
>
> kobject_del(){ get_device_parent(){
> ... ...
> sysfs_remove_dir(kobj); //kobj->sd=0 spin_lock(&dev->class->p->glue_dirs.list_lock);
this should be kobj->sd = NULL
> ... <========= list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) //get parent kobject from kset list
> kobj_kset_leave(kobj); //remove kobj from kset list ...
> } }
>
> If getting parent object between " kobj->sd=0 " and "remove_kset_leave(kobj)", the sysfs_create_dir() will return ENOENT and trigger the BUG later.
>
this should be kobj->sd = NULL
> The lastest kernel seems to be the same. But I am not familiar with block device, I am not sure whether the analysis is right or I am missing something.
> what do you think about this situation? Any suggestion is appreciative. Thanks!
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel BUG at fs/sysfs/group.c:65!
2014-10-09 12:47 ` Weng Meiling
@ 2014-10-11 3:00 ` Weng Meiling
2014-10-13 6:45 ` kernel BUG at fs/sysfs/group.c:65! (CC Jens ) Weng Meiling
0 siblings, 1 reply; 4+ messages in thread
From: Weng Meiling @ 2014-10-11 3:00 UTC (permalink / raw)
To: Greg KH, tom.leiming, tj
Cc: tt.rantala, linux-kernel@vger.kernel.org, Huang Qiang, Li Zefan
ping ...
On 2014/10/9 20:47, Weng Meiling wrote:
> On 2014/10/9 20:43, Weng Meiling wrote:
>> Hi guys,
>>
>> I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by duplicated sysfs link.
>>
>> the detail mail:
>>
>> https://lkml.org/lkml/2013/3/8/370
>>
>> but it seems the problems has no conclusion. In our environment, we triggered the bug too, but for error ENOENT:
>>
>> we use 3.4 kernel, and do virtual disk device create / remove for many times. Before remove we can see the devices:
>>
>> #ll /sys/devices/virtual/block/
>> drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-1a
>> drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-2a
>>
>> when the two virtual devices were removed, the directory block/ was delete too.
>>
>> after many times create / remove, the kernel trigger the bug (just the main call trace):
>>
>> [ 3965.441713] WARNING: at /usr/src/packages/BUILD/linux-3.4/lib/kobject.c:202 kobject_add_internal+0x11f/0x280()
>> [ 3965.441716] Hardware name: Romley
>> [ 3965.441718] kobject_add_internal failed for sd-1a (error: -2 parent: block)
>>
>> [ 3965.441817] Call Trace:
>> [ 3965.441820] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
>> [ 3965.441823] [<ffffffff81037251>] warn_slowpath_fmt+0x41/0x50
>> [ 3965.441826] [<ffffffff81215e0f>] kobject_add_internal+0x11f/0x280
>> [ 3965.441830] [<ffffffff81216267>] kobject_add+0x67/0xc0
>> [ 3965.441833] [<ffffffff812d2305>] device_add+0x105/0x6d0
>> [ 3965.441836] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
>> [ 3965.441839] [<ffffffff812030ac>] add_disk+0x1bc/0x490
>>
>> [ 3965.441912] kernel BUG at /usr/src/packages/BUILD/linux-3.4/fs/sysfs/group.c:65!
>> [ 3965.441915] invalid opcode: 0000 [#1] SMP
>> [ 3965.686738] Call Trace:
>> [ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
>> [ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
>> [ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
>> [ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490
>>
>> from the error "kobject_add_internal failed for sd-1a (error: -2 parent: block)", we found that the first
>> warning was caused by the disk device's parent_sd was null when it was added into sysfs:
>>
>> int sysfs_create_dir(struct kobject * kobj)
>> {
>> ...
>> if (kobj->parent)
>> parent_sd = kobj->parent->sd;
>> else
>> parent_sd = &sysfs_root;
>>
>> if (!parent_sd)
>> return -ENOENT;
>> ...
>> }
>>
>> The virtual disk device was not added into sysfs because of the above failure, and the kobj->sd was
>> not set, then trigger the bug when creating attribute group under the device's directory:
>>
>> static int internal_create_group(struct kobject *kobj, int update,
>> const struct attribute_group *grp)
>> {
>> ...
>> BUG_ON(!kobj || (!update && !kobj->sd));
>> ...
>> }
>>
>> Walk the code, it seems there maybe a race between block/ remove and virtual disk devices' register:
>>
>> when the two virtual devices were removed, the block/ directory's refcount became 0, will into:
>>
>> path0(remove the block/) path1(register virtual device sd-1a)
>>
>> kobject_del(){ get_device_parent(){
>> ... ...
>> sysfs_remove_dir(kobj); //kobj->sd=0 spin_lock(&dev->class->p->glue_dirs.list_lock);
>
> this should be kobj->sd = NULL
>> ... <========= list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) //get parent kobject from kset list
>> kobj_kset_leave(kobj); //remove kobj from kset list ...
>> } }
>>
>> If getting parent object between " kobj->sd=0 " and "remove_kset_leave(kobj)", the sysfs_create_dir() will return ENOENT and trigger the BUG later.
>>
> this should be kobj->sd = NULL
>
>> The lastest kernel seems to be the same. But I am not familiar with block device, I am not sure whether the analysis is right or I am missing something.
>> what do you think about this situation? Any suggestion is appreciative. Thanks!
>>
>>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel BUG at fs/sysfs/group.c:65! (CC Jens )
2014-10-11 3:00 ` Weng Meiling
@ 2014-10-13 6:45 ` Weng Meiling
0 siblings, 0 replies; 4+ messages in thread
From: Weng Meiling @ 2014-10-13 6:45 UTC (permalink / raw)
To: Greg KH, tom.leiming, tj
Cc: tt.rantala, linux-kernel@vger.kernel.org, Huang Qiang, Li Zefan,
Jens Axboe, Xiang Rui
On 2014/10/11 11:00, Weng Meiling wrote:
> ping ...
>
> On 2014/10/9 20:47, Weng Meiling wrote:
>> On 2014/10/9 20:43, Weng Meiling wrote:
>>> Hi guys,
>>>
>>> I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by duplicated sysfs link.
>>>
>>> the detail mail:
>>>
>>> https://lkml.org/lkml/2013/3/8/370
>>>
>>> but it seems the problems has no conclusion. In our environment, we triggered the bug too, but for error ENOENT:
>>>
>>> we use 3.4 kernel, and do virtual disk device create / remove for many times. Before remove we can see the devices:
>>>
>>> #ll /sys/devices/virtual/block/
>>> drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-1a
>>> drwxr-xr-x 7 root root 0 Oct 6 09:17 sd-2a
>>>
>>> when the two virtual devices were removed, the directory block/ was delete too.
>>>
>>> after many times create / remove, the kernel trigger the bug (just the main call trace):
>>>
>>> [ 3965.441713] WARNING: at /usr/src/packages/BUILD/linux-3.4/lib/kobject.c:202 kobject_add_internal+0x11f/0x280()
>>> [ 3965.441716] Hardware name: Romley
>>> [ 3965.441718] kobject_add_internal failed for sd-1a (error: -2 parent: block)
>>>
>>> [ 3965.441817] Call Trace:
>>> [ 3965.441820] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
>>> [ 3965.441823] [<ffffffff81037251>] warn_slowpath_fmt+0x41/0x50
>>> [ 3965.441826] [<ffffffff81215e0f>] kobject_add_internal+0x11f/0x280
>>> [ 3965.441830] [<ffffffff81216267>] kobject_add+0x67/0xc0
>>> [ 3965.441833] [<ffffffff812d2305>] device_add+0x105/0x6d0
>>> [ 3965.441836] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
>>> [ 3965.441839] [<ffffffff812030ac>] add_disk+0x1bc/0x490
>>>
>>> [ 3965.441912] kernel BUG at /usr/src/packages/BUILD/linux-3.4/fs/sysfs/group.c:65!
>>> [ 3965.441915] invalid opcode: 0000 [#1] SMP
>>> [ 3965.686738] Call Trace:
>>> [ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
>>> [ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
>>> [ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
>>> [ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490
>>>
>>> from the error "kobject_add_internal failed for sd-1a (error: -2 parent: block)", we found that the first
>>> warning was caused by the disk device's parent_sd was null when it was added into sysfs:
>>>
>>> int sysfs_create_dir(struct kobject * kobj)
>>> {
>>> ...
>>> if (kobj->parent)
>>> parent_sd = kobj->parent->sd;
>>> else
>>> parent_sd = &sysfs_root;
>>>
>>> if (!parent_sd)
>>> return -ENOENT;
>>> ...
>>> }
>>>
>>> The virtual disk device was not added into sysfs because of the above failure, and the kobj->sd was
>>> not set, then trigger the bug when creating attribute group under the device's directory:
>>>
>>> static int internal_create_group(struct kobject *kobj, int update,
>>> const struct attribute_group *grp)
>>> {
>>> ...
>>> BUG_ON(!kobj || (!update && !kobj->sd));
>>> ...
>>> }
>>>
>>> Walk the code, it seems there maybe a race between block/ remove and virtual disk devices' register:
>>>
>>> when the two virtual devices were removed, the block/ directory's refcount became 0, will into:
>>>
>>> path0(remove the block/) path1(register virtual device sd-1a)
>>>
>>> kobject_del(){ get_device_parent(){
>>> ... ...
>>> sysfs_remove_dir(kobj); //kobj->sd=0 spin_lock(&dev->class->p->glue_dirs.list_lock);
>>
>> this should be kobj->sd = NULL
>>> ... <========= list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) //get parent kobject from kset list
>>> kobj_kset_leave(kobj); //remove kobj from kset list ...
>>> } }
>>>
>>> If getting parent object between " kobj->sd=0 " and "remove_kset_leave(kobj)", the sysfs_create_dir() will return ENOENT and trigger the BUG later.
>>>
>> this should be kobj->sd = NULL
>>
>>> The lastest kernel seems to be the same. But I am not familiar with block device, I am not sure whether the analysis is right or I am missing something.
>>> what do you think about this situation? Any suggestion is appreciative. Thanks!
>>>
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-13 6:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-09 12:43 kernel BUG at fs/sysfs/group.c:65! Weng Meiling
2014-10-09 12:47 ` Weng Meiling
2014-10-11 3:00 ` Weng Meiling
2014-10-13 6:45 ` kernel BUG at fs/sysfs/group.c:65! (CC Jens ) Weng Meiling
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).