All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Paul Menage <menage@google.com>, balbir@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Sudhir Kumar <skumar@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Bharata B Rao <bharata.rao@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	libcg-devel <libcg-devel@lists.sourceforge.net>
Subject: Re: [BUG][PANIC] cgroup panics with mmotm for 2.6.28-rc7
Date: Tue, 16 Dec 2008 10:41:04 +0800	[thread overview]
Message-ID: <49471540.8090304@cn.fujitsu.com> (raw)
In-Reply-To: <6599ad830812151757t5362ae16y81b469b06022135c@mail.gmail.com>

Paul Menage wrote:
> That implies that we ran out of css_set objects when moving the task
> into the new cgroup.
> 
> Did you have all of the configured controllers mounted, or just a subset?
> 
> What date was this mmotm? Was it after Li's patch fixes went in on 8th Dec?
> 

It is probably my fault. :( I'm looking into this problem.

There are 2 related cleanup patches in -mm:

cgroups-add-inactive-subsystems-to-rootnodesubsys_list.patch (and -fix.patch)
cgroups-introduce-link_css_set-to-remove-duplicate-code.patch (and -fix.patch)

If the bug is reproducable, could you revert the above patches and seee if the
bug is still there.

> Paul
> 
> On Mon, Dec 15, 2008 at 3:32 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>> Hi, Paul,
>>
>> I see the following stack trace when I run my tests. I've not yet
>> investigated the problem.
>>
>> ------------[ cut here ]------------
>> kernel BUG at kernel/cgroup.c:392!
>> invalid opcode: 0000 [#1] SMP
>> last sysfs file: /sys/devices/pci0000:00/0000:00:1c.5/0000:03:00.0/irq
>> CPU 1
>> Modules linked in: coretemp hwmon kvm_intel kvm rtc_cmos rtc_core
>> rtc_lib mptsas mptscsih mptbase scsi_transport_sas uhci_hcd ohci_hcd
>> ehci_hcd
>> Pid: 3866, comm: libcgrouptest01 Tainted: G        W  2.6.28-rc7-mm1
>> #3
>> RIP: 0010:[<ffffffff80272c5b>]  [<ffffffff80272c5b>]
>> link_css_set+0xf/0x5a
>> RSP: 0018:ffff8800388ebda8  EFLAGS: 00010246
>> RAX: ffffffff807a2790 RBX: ffff88003e9667e0 RCX: ffff88012f6ecff8
>> RDX: ffff88012f6ecff8 RSI: ffff88003e9667e0 RDI: ffff8800388ebdf8
>> RBP: ffff8800388ebda8 R08: ffff8800388ebdf8 R09: 0000000000000000
>> R10: ffff88003a55d000 R11: ffffe2000196d170 R12: ffff88003e9667e0
>> R13: 0000000000000001 R14: ffff880038838000 R15: ffffffff811d3c00
>> FS:  00007f482219e700(0000) GS:ffff88007ff064b0(0000)
>> knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00007f48221cc000 CR3: 0000000038896000 CR4: 00000000000026e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process libcgrouptest01 (pid: 3866, threadinfo ffff8800388ea000, task
>> ffff880038838000)
>> Stack:
>>  ffff8800388ebe48 ffffffff802740dd ffffffff80272955 ffff88012f6ecff8
>>  ffff8800389b4028 ffff8800389b4000 ffffffff807aa720 ffff88012f6ecb68
>>  ffff88012fd852a8 0000000000000246 ffff8800388ebdf8 ffff8800388ebdf8
>> Call Trace:
>>  [<ffffffff802740dd>] cgroup_attach_task+0x234/0x3d0
>>  [<ffffffff80272955>] ? cgroup_lock_live_group+0x1a/0x36
>>  [<ffffffff80274380>] cgroup_tasks_write+0x107/0x12e
>>  [<ffffffff802742b8>] ? cgroup_tasks_write+0x3f/0x12e
>>  [<ffffffff802748d4>] cgroup_file_write+0xfb/0x22d
>>  [<ffffffff8039e30d>] ? __up_read+0x9b/0xa3
>>  [<ffffffff802ba77d>] vfs_write+0xae/0x157
>>  [<ffffffff802bac98>] sys_write+0x47/0x6f
>>  [<ffffffff8020bfdb>] system_call_fastpath+0x16/0x1b
>> Code: 8b 5b 30 48 39 c3 74 06 48 3b 5b 60 75 f1 48 39 c3 0f 94 c0 0f
>> b6 c0 5b 5a 5b c9 c3 4c 8b 07 55 48 89 d1 48 89 e5 49 39 f8 75 04 <0f>
>> 0b eb fe 49 8b 40 08 49 8b 10 49 89 70 20 48 89 10 48 89 42
>> RIP  [<ffffffff80272c5b>] link_css_set+0xf/0x5a
>>  RSP <ffff8800388ebda8>
>> ---[ end trace b73399e271602d45 ]---
>>
>> I've setup my system using libcgroup to create default cgroups and to
>> automatically classify all tasks to the "default group". I've made
>> some changes to cgconfig and cgred scripts (they can be found under
>> the source code of libcgroup (branches/balbir-tests).
>>
>> Steps to reproduce
>>
>> 1. Start with the new scripts and move all tasks to a default cgroup
>> 2. Ensure that cgred and cgconfig are running
>> 3. Stop cgred and cgconfig and run libcgrouptest01 (patches posted by
>> sudhir on the libcgroup mailing list).
>>
>> The test log is
>>
>> WARN: /dev/cgroup_controllers-1 already exist..overwriting
>> C:DBG: fs_mounted as recieved from script=1
>> C:DBG: mountpoint1 as recieved from script=/dev/cgroup_controllers-1
>> sanity check pass. cgroup
>> TEST 1:PASS : cgroup_attach_task()               Ret Value = 50014
>> Par: nullcgroup
>> TEST 2:PASS : cgroup_init()                      Ret Value = 0
>> TEST 3:PASS : cgroup_attach_task()               Ret Value = 0   Task
>> found in group/s
>> TEST 4:PASS : cgroup_attach_task_pid()           Ret Value = 50016
>> TEST 1:PASS : cgroup_new_cgroup()                Ret Value = 0
>> TEST 2:PASS : cgroup_create_cgroup()             Ret Value = 0   grp
>> found in fs
>>
>>

  parent reply	other threads:[~2008-12-16  2:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 11:32 [BUG][PANIC] cgroup panics with mmotm for 2.6.28-rc7 Balbir Singh
2008-12-16  1:57 ` Paul Menage
2008-12-16  1:58   ` Paul Menage
2008-12-16  2:41   ` Li Zefan [this message]
2008-12-16  2:53     ` Li Zefan
2008-12-16  3:52       ` Balbir Singh
2008-12-18 19:18       ` Balbir Singh
2008-12-19  0:53         ` Li Zefan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49471540.8090304@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=bharata.rao@in.ibm.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=libcg-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=skumar@linux.vnet.ibm.com \
    --cc=vatsa@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.