[opensuse-kernel] Kernel:HEAD: kernel: ida_remove called for id=0 which is not allocated.
Hi: Is the message is $SUBJECT something to be concerned about or a bug ? Unfortunately no extra information is shown about what subsystem or piece of code called ida_remove with id=0.. Cheers. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le Monday 22 April 2013 à 21:36 -0300, Cristian Rodríguez a écrit :
Hi:
Is the message is $SUBJECT something to be concerned about or a bug ?
Yes that would be a bug.
Unfortunately no extra information is shown about what subsystem or piece of code called ida_remove with id=0..
Looking at the code which generates this warning, there is a dump_stack() following which should certainly tell you who got it wrong. It may end up in a different log file though as I see it lacks a proper log level in many archs including x86. You might have to tweak /etc/rsyslog.conf to have them logged. They should be in "dmesg" already though. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 04/23/2013 05:38 AM, Jean Delvare wrote:
Le Monday 22 April 2013 à 21:36 -0300, Cristian Rodríguez a écrit :
Hi:
Is the message is $SUBJECT something to be concerned about or a bug ?
Yes that would be a bug.
Ok, I will check if I spot it again.
Looking at the code which generates this warning, there is a dump_stack() following which should certainly tell you who got it wrong.
?? the code I found only says: lib/idr,c err: printk(KERN_WARNING "ida_remove called for id=%d which is not allocated.\n", id); dont see any dump_stack there,,, You might have to
tweak /etc/rsyslog.conf to have them logged. They should be in "dmesg" already though.
Not using syslog, only the journal. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Tue, 23 Apr 2013 11:55:08 -0300, Cristian Rodríguez wrote:
On 04/23/2013 05:38 AM, Jean Delvare wrote:
Le Monday 22 April 2013 à 21:36 -0300, Cristian Rodríguez a écrit :
Hi:
Is the message is $SUBJECT something to be concerned about or a bug ?
Yes that would be a bug.
Ok, I will check if I spot it again.
Looking at the code which generates this warning, there is a dump_stack() following which should certainly tell you who got it wrong.
?? the code I found only says:
lib/idr,c err:
printk(KERN_WARNING "ida_remove called for id=%d which is not allocated.\n", id);
dont see any dump_stack there,,,
You might have to
tweak /etc/rsyslog.conf to have them logged. They should be in "dmesg" already though.
Not using syslog, only the journal.
Right, it's not idr_remove() but ida_remove(). The dump_stack is issued only for the former, unfortunately. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le Tuesday 23 April 2013 à 17:07 +0200, Takashi Iwai a écrit :
At Tue, 23 Apr 2013 11:55:08 -0300, Cristian Rodríguez wrote:
On 04/23/2013 05:38 AM, Jean Delvare wrote:
Le Monday 22 April 2013 à 21:36 -0300, Cristian Rodríguez a écrit :
Hi:
Is the message is $SUBJECT something to be concerned about or a bug ?
Yes that would be a bug.
Ok, I will check if I spot it again.
Looking at the code which generates this warning, there is a dump_stack() following which should certainly tell you who got it wrong.
?? the code I found only says:
lib/idr,c err:
printk(KERN_WARNING "ida_remove called for id=%d which is not allocated.\n", id);
dont see any dump_stack there,,,
You might have to
tweak /etc/rsyslog.conf to have them logged. They should be in "dmesg" already though.
Not using syslog, only the journal.
Right, it's not idr_remove() but ida_remove(). The dump_stack is issued only for the former, unfortunately.
I have sent a patch upstream, adding the missing call to dump_stack() after the warning in ida_remove(). I have also applied that patch to our Factory kernel. Cristian, I invite you to update to the next Factory kernel which builds (doesn't seem to be the case right now, unfortunately) so that you get the stack dump in the event the bug happens to you again. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 05/05/13 05:59, Jean Delvare escribió:
I have sent a patch upstream, adding the missing call to dump_stack() after the warning in ida_remove(). I have also applied that patch to our Factory kernel. Cristian, I invite you to update to the next Factory kernel which builds (doesn't seem to be the case right now, unfortunately) so that you get the stack dump in the event the bug happens to you again.
OK, thanks, I still see it in my logs today so it is very likely that I will be able to catch what's going on. that being said: [ 5.525032] ida_remove called for id=0 which is not allocated. [ 5.525231] systemd[1]: Got SIGCHLD for process 397 (auditctl) [ 5.525286] systemd[1]: Child 397 died (code=exited, status=0/SUCCESS) [ 5.525294] systemd[1]: Child 397 belongs to auditd.service [ 5.525306] systemd[1]: auditd.service: control process exited, code=exited status=0 [ 5.525496] systemd[1]: auditd.service changed start-post -> running apparently comes from the audit subsystem...hrmmm.. but there is no certainty of that yet. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 05/05/13 05:59, Jean Delvare escribió:
I have sent a patch upstream, adding the missing call to dump_stack() after the warning in ida_remove(). I have also applied that patch to our Factory kernel. Cristian, I invite you to update to the next Factory kernel which builds (doesn't seem to be the case right now, unfortunately) so that you get the stack dump in the event the bug happens to you again.
OK, here we go :-) [ 16.706120] ida_remove called for id=0 which is not allocated. [ 16.706124] Pid: 333, comm: auditctl Not tainted 3.9.0-6.g4c487a5-desktop #1 [ 16.706125] Call Trace: [ 16.706136] [<ffffffff81004738>] dump_trace+0x88/0x300 [ 16.706154] [<ffffffff815cad98>] dump_stack+0x69/0x6f [ 16.706161] [<ffffffff81197945>] mnt_release_group_id+0x25/0x50 [ 16.706168] [<ffffffff811a631c>] change_mnt_propagation+0x25c/0x280 [ 16.706175] [<ffffffff81198926>] umount_tree+0x156/0x1c0 [ 16.706179] [<ffffffff811991cb>] drop_collected_mounts+0x3b/0x70 [ 16.706200] [<ffffffff810cbb7b>] audit_add_tree_rule+0x16b/0x270 [ 16.706206] [<ffffffff810c488e>] audit_receive_filter+0x78e/0xb00 [ 16.706211] [<ffffffff810c22a4>] audit_receive_msg+0x334/0xa40 [ 16.706215] [<ffffffff810c29ef>] audit_receive+0x3f/0x80 [ 16.706220] [<ffffffff8150a544>] netlink_unicast+0x1a4/0x230 [ 16.706226] [<ffffffff8150a8fd>] netlink_sendmsg+0x32d/0x3e0 [ 16.706232] [<ffffffff814c9166>] sock_sendmsg+0xb6/0x100 [ 16.706237] [<ffffffff814caef4>] sys_sendto+0x114/0x180 [ 16.706242] [<ffffffff815de9ad>] system_call_fastpath+0x1a/0x1f [ 16.706249] [<00007f1dde6248b3>] 0x7f1dde6248b2 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 06/05/13 12:51, Cristian Rodríguez escribió:
El 05/05/13 05:59, Jean Delvare escribió:
I have sent a patch upstream, adding the missing call to dump_stack() after the warning in ida_remove(). I have also applied that patch to our Factory kernel. Cristian, I invite you to update to the next Factory kernel which builds (doesn't seem to be the case right now, unfortunately) so that you get the stack dump in the event the bug happens to you again.
OK, here we go :-)
[ 16.706120] ida_remove called for id=0 which is not allocated. [ 16.706124] Pid: 333, comm: auditctl Not tainted 3.9.0-6.g4c487a5-desktop #1 [ 16.706125] Call Trace: [ 16.706136] [<ffffffff81004738>] dump_trace+0x88/0x300 [ 16.706154] [<ffffffff815cad98>] dump_stack+0x69/0x6f [ 16.706161] [<ffffffff81197945>] mnt_release_group_id+0x25/0x50 [ 16.706168] [<ffffffff811a631c>] change_mnt_propagation+0x25c/0x280 [ 16.706175] [<ffffffff81198926>] umount_tree+0x156/0x1c0 [ 16.706179] [<ffffffff811991cb>] drop_collected_mounts+0x3b/0x70 [ 16.706200] [<ffffffff810cbb7b>] audit_add_tree_rule+0x16b/0x270 [ 16.706206] [<ffffffff810c488e>] audit_receive_filter+0x78e/0xb00 [ 16.706211] [<ffffffff810c22a4>] audit_receive_msg+0x334/0xa40 [ 16.706215] [<ffffffff810c29ef>] audit_receive+0x3f/0x80 [ 16.706220] [<ffffffff8150a544>] netlink_unicast+0x1a4/0x230 [ 16.706226] [<ffffffff8150a8fd>] netlink_sendmsg+0x32d/0x3e0 [ 16.706232] [<ffffffff814c9166>] sock_sendmsg+0xb6/0x100 [ 16.706237] [<ffffffff814caef4>] sys_sendto+0x114/0x180 [ 16.706242] [<ffffffff815de9ad>] system_call_fastpath+0x1a/0x1f [ 16.706249] [<00007f1dde6248b3>] 0x7f1dde6248b2
Seems to come from: fs/pnode.c void change_mnt_propagation(struct mount *mnt, int type) ... do_make_slave(mnt); --> ... static int do_make_slave(struct mount *mnt) ... if (IS_MNT_SHARED(mnt) && list_empty(&mnt->mnt_share)) mnt_release_group_id(mnt); --> .. fs/namespace.c void mnt_release_group_id(struct mount *mnt) { int id = mnt->mnt_group_id; ida_remove(&mnt_group_ida, id); --> bang. if (mnt_group_start > id) mnt_group_start = id; mnt->mnt_group_id = 0; } -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Mon, 06 May 2013 12:51:49 -0400, Cristian Rodríguez wrote:
El 05/05/13 05:59, Jean Delvare escribió:
I have sent a patch upstream, adding the missing call to dump_stack() after the warning in ida_remove(). I have also applied that patch to our Factory kernel. Cristian, I invite you to update to the next Factory kernel which builds (doesn't seem to be the case right now, unfortunately) so that you get the stack dump in the event the bug happens to you again.
OK, here we go :-)
[ 16.706120] ida_remove called for id=0 which is not allocated. [ 16.706124] Pid: 333, comm: auditctl Not tainted 3.9.0-6.g4c487a5-desktop #1 [ 16.706125] Call Trace: [ 16.706136] [<ffffffff81004738>] dump_trace+0x88/0x300 [ 16.706154] [<ffffffff815cad98>] dump_stack+0x69/0x6f [ 16.706161] [<ffffffff81197945>] mnt_release_group_id+0x25/0x50 [ 16.706168] [<ffffffff811a631c>] change_mnt_propagation+0x25c/0x280 [ 16.706175] [<ffffffff81198926>] umount_tree+0x156/0x1c0 [ 16.706179] [<ffffffff811991cb>] drop_collected_mounts+0x3b/0x70 [ 16.706200] [<ffffffff810cbb7b>] audit_add_tree_rule+0x16b/0x270 [ 16.706206] [<ffffffff810c488e>] audit_receive_filter+0x78e/0xb00 [ 16.706211] [<ffffffff810c22a4>] audit_receive_msg+0x334/0xa40 [ 16.706215] [<ffffffff810c29ef>] audit_receive+0x3f/0x80 [ 16.706220] [<ffffffff8150a544>] netlink_unicast+0x1a4/0x230 [ 16.706226] [<ffffffff8150a8fd>] netlink_sendmsg+0x32d/0x3e0 [ 16.706232] [<ffffffff814c9166>] sock_sendmsg+0xb6/0x100 [ 16.706237] [<ffffffff814caef4>] sys_sendto+0x114/0x180 [ 16.706242] [<ffffffff815de9ad>] system_call_fastpath+0x1a/0x1f [ 16.706249] [<00007f1dde6248b3>] 0x7f1dde6248b2
The patch below should fix the issue. If I understand correctly, the
group id could be zero until really needed even when it's mounted via
SHARED flag. I'm going to send it to upstream.
Takashi
---
Subject: [PATCH] vfs: Fix invalid ida_remove() call
When the group id of a shared mount is not allocated, the umount still
tries to call mnt_release_group_id(), which eventually hits a kernel
warning at ida_remove() spewing a message like:
ida_remove called for id=0 which is not allocated.
This patch fixes the bug simply checking the group id in the caller.
Reported-by: Cristian Rodríguez
participants (3)
-
Cristian Rodríguez -
Jean Delvare -
Takashi Iwai