On 2013/2/7 18:04, Maxim Uvarov wrote: > 2013/2/7 Li Zefan <lize...@huawei.com>: >> CC: Tejun >> >> 于 2013/2/6 23:16, Maxim Uvarov wrote: >>> linux-3.0.y has put_css_set a litte bit down in the code, >>> this should not be duplicated. >> >> Why do you want to make this change? Have you encountered some kernel bug >> that relates >> to cgroup? >> > > Yes, I thought that this code by mistake calls twice put_css_set() > which affects to rcu code, > which I see in rcu_implicit_dynticks_qs(). And when I am hot adding > vcpu under xen I see this back trace: > Pid: 3214, comm: udevd Not tainted #1 Xen HVM domU > [<ffffffff81011c50>] xen_smp_send_reschedule+0x10/0x20 > [<ffffffff810dbfc1>] rcu_implicit_offline_qs+0x41/0x80 > [<ffffffff81507fa4>] ? _raw_spin_lock_irqsave+0x34/0x50 > [<ffffffff810dd8b7>] rcu_implicit_dynticks_qs+0x47/0x50 > [<ffffffff810dc4b9>] force_qs_rnp+0xa9/0x170 > [<ffffffff810dd870>] ? rcu_check_callbacks+0xa0/0xa0 > [<ffffffff810dc964>] force_quiescent_state+0x194/0x1b0 > [<ffffffff810dd06d>] __rcu_process_callbacks+0x9d/0xd0 > [<ffffffff810dd0c5>] rcu_process_callbacks+0x25/0x50 > [<ffffffff81075c39>] __do_softirq+0xb9/0x1d0 >
This seems incomplete.. It's a WARN_ON or a BUG_ON or null pointer deref or something else? > After removing it back trace disappeared. So I thought that this code > was duplicated by mistake, > maybe git cherry-pick artifact. > You did a bisection or you simply removed that put_css_set()? Are you using cgroup? You won't run into the cgroup code you touched unless a task is moved from a cgroup to another. (PS: I won't be responsive in the following week) -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
