These two functions share most of the code.
Signed-off-by: Li Zefan lize...@huawei.com
---
v2: Not necessary to move cgroup_attach_task_all().
---
include/linux/cgroup.h | 3 +-
kernel/cgroup.c| 109 +
kernel/cpuset.c| 2 +-
3
On 2013/3/13 9:19, Tejun Heo wrote:
On Wed, Mar 13, 2013 at 09:17:09AM +0800, Li Zefan wrote:
These two functions share most of the code.
Signed-off-by: Li Zefan lize...@huawei.com
---
v2: Not necessary to move cgroup_attach_task_all().
I supposed this one is the one to apply?
yep
On 2013/3/13 13:12, Stephen Rothwell wrote:
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from include/linux/memcontrol.h:22:0,
from include/linux/swap.h:8,
from
On 2013/3/3 3:23, Tommi Rantala wrote:
Hello,
I'm seeing the following hung task warnings when fuzzing the kernel
with trinity (in a qemu virtual machine, as the root user), that I
have not seen before with 3.8 or earlier. The kernel is
b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50 (Merge tag
On 2013/3/2 4:45, Tejun Heo wrote:
Hello, Al.
On Fri, Mar 1, 2013 at 12:39 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Flexible array members can be statically initialized. If you wanna be
really anal about it, you can do it manually with a wrapping struct
but I don't think that would be
As we've added __init annotation to field-defining functions, we should
add __refdata annotation to event_call variables, which reference those
functions.
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Li Zefan lize...@huawei.com
---
include/trace/ftrace.h| 2 +-
kernel
the comment in cgroup_exit()
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 17 ++---
kernel/cgroup.c| 28 ++--
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index
We don't need to include cgroup.h in cpuset.h.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cpuset.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 8c8a60d..ccd1de8 100644
--- a/include/linux/cpuset.h
+++ b/include/linux
Move struct perf_cgroup_info and perf_cgroup to kernel/perf/core.c,
and then we can remove include of cgroup.h.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/perf_event.h | 18 +-
kernel/events/core.c | 15 +++
2 files changed, 16 insertions
It's not needed at all.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/res_counter.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
index 5ae8456..a83a849 100644
--- a/include/linux/res_counter.h
+++ b
While working of a cgroup patch which also touched include/linux/sched.h,
I found some function/macro/structure declarations can be moved to
kernel/sched/sched.h, and some can even be total removed, so here's
the patchset.
The result is a reduction of ~200 LOC from include/linux/sched.h.
No one will call those functions if CONFIG_SCHED_DEBUG=n.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d35d2b6..2715fbb 100644
--- a/include/linux/sched.h
It's unused.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 2715fbb..e880d7d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -959,15 +959,6
Move struct sched_group_power and sched_group and related inline
functions to kernel/sched/sched.h, as they are used internally only.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 58 ++-
kernel/sched/sched.h | 56
They are used internally only.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 7 ---
kernel/sched/sched.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0d64130..863b505 100644
It's used internally only.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 59 ---
kernel/sched/sched.h | 55 +++
2 files changed, 55 insertions(+), 59 deletions(-)
diff --git
They are used internally only.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 25 -
kernel/sched/sched.h | 26 +-
2 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/include/linux/sched.h b/include/linux
As default_scale_{freq,smt}_power() and update_rt_power() are used
in kernel/sched/fair.c only, annotate them as static functions.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 3 ---
kernel/sched/fair.c | 6 +++---
2 files changed, 3 insertions(+), 6 deletions
- Make sched_group_{set_,}runtime(), sched_group_{set_,}period() and
sched_rt_can_attach() static.
- Move sched_{create,destroy,online,offline}_group() to kernel/sched/sched.h.
- Remove declaration of sched_group_shares().
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h
It's already declared in include/linux/sched.h
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/sched/core.c | 4
kernel/sched/sched.h | 5 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9ad26c9..42ecbcb 100644
On 2013/3/5 16:33, Stephane Eranian wrote:
On Tue, Mar 5, 2013 at 4:38 AM, Li Zefan lize...@huawei.com wrote:
Move struct perf_cgroup_info and perf_cgroup to kernel/perf/core.c,
and then we can remove include of cgroup.h.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux
-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7a6c4c7..e72c44e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3845,9 +3845,10 @@ static int cgroup_event_wake
On 2013/3/6 14:22, Tejun Heo wrote:
Hello, Li.
On Wed, Mar 06, 2013 at 11:28:01AM +0800, Li Zefan wrote:
cgroup_event_wake() is called with hardirq-safe wqh-lock held, so
the nested cgrp-event_list_lock should also be hardirq-safe.
Fortunately I don't think the deadlock can happen in real
On 2013/3/6 15:02, Tejun Heo wrote:
On Tue, Mar 5, 2013 at 11:00 PM, Li Zefan lize...@huawei.com wrote:
Why should wqh-lock be hard-irq-safe? Is it actually grabbed from
irq context?
becase cgroup_event_wake() is a callback to a wait queue, and it's wake_up()
that acquires wqh-lock with irq
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/sched/sched.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 30bebb9..3bd15a4 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1026,6 +1026,8 @@ extern
On 2013/3/7 0:02, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel
I've stumbled on the following:
[ 450.180599] ===
[ 450.181392] [ INFO: suspicious RCU usage. ]
[ 450.182101]
On 2013/3/7 14:15, Michael Wang wrote:
On 03/07/2013 12:02 AM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel
I've stumbled on the following:
[ 450.180599] ===
[ 450.181392] [ INFO: suspicious RCU
:
arch/s390/include/asm/cpu_mf.h: In function 'qctri':
arch/s390/include/asm/cpu_mf.h:61:12: error: 'EINVAL' undeclared
(first use in this function)
Reported-by: Fengguang Wu fengguang...@intel.com
Tested-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Li Zefan lize...@huawei.com
---
CC
Cc: sasha.le...@oracle.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: container
This is a second report... and the same address: 0xfff0
On 2013/3/7 17:37, CAI Qian wrote:
Just came across this during LTP run on a ppc64 system. Still trying to
reproduce and possible bisect,
On 2013/2/3 9:20, Tejun Heo wrote:
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Looks good to me.
Acked-by: Li Zefan lize...@huawei.com
Cc: Li Zefan lize...@huawei.com
Cc: contain...@lists.linux-foundation.org
Cc: cgro
On 2013/2/3 0:12, Kirill A. Shutemov wrote:
On Sat, Feb 02, 2013 at 02:51:30PM +0800, Li Zefan wrote:
Currently when a cgroup is removed, it calls eventfd_signal() for
each registered cgroup event, so userspace can be notified and blocked
reads can be unblocked.
The problem is, if we have
On 2013/2/3 7:10, Tejun Heo wrote:
The iteration logic of idr_get_next() is borrowed mostly verbatim from
idr_for_each(). It walks down the tree looking for the slot matching
the current ID. If the matching slot is not found, the ID is
incremented by the distance of single slot at the given
On 2013/2/4 18:15, Kirill A. Shutemov wrote:
On Sat, Feb 02, 2013 at 05:58:58PM +0200, Kirill A. Shutemov wrote:
On Sat, Feb 02, 2013 at 02:50:44PM +0800, Li Zefan wrote:
When an eventfd is closed, a wakeup with POLLHUP will be issued,
but cgroup wants to issue wakeup explicitly, so when
On 2013/2/5 16:28, Kirill A. Shutemov wrote:
On Tue, Feb 05, 2013 at 11:40:50AM +0800, Li Zefan wrote:
On 2013/2/4 18:15, Kirill A. Shutemov wrote:
On Sat, Feb 02, 2013 at 05:58:58PM +0200, Kirill A. Shutemov wrote:
On Sat, Feb 02, 2013 at 02:50:44PM +0800, Li Zefan wrote:
When an eventfd
On 2013/2/7 3:39, Tejun Heo wrote:
idr_destroy() can destroy idr by itself and idr_remove_all() is being
deprecated. Drop its usage.
Signed-off-by: Tejun Heo t...@kernel.org
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 2013/2/7 9:00, Tejun Heo wrote:
(cc'ing Li)
On Wed, Feb 6, 2013 at 4:55 PM, Andrew Morton a...@linux-foundation.org
wrote:
Problems in cgroup_load_subsys().
In linux-next, that function is now using the `node' storage which your
patch removes:
@@ -4503,23 +4525,17 @@ int
On 2013/1/31 4:50, Tejun Heo wrote:
Hello,
On Wed, Jan 30, 2013 at 12:49 PM, Aristeu Rozanski that's not
intentional. thanks for catching this
Tejun, you want me to resubmit the whole series or just the next patch
(where I was supposed to move that chunk)?
If it doesn't affect the next
on 2013/2/1 11:48, Steven Rostedt wrote:
Li,
Can you give an Ack or Nack for this.
I think this patch shouldn't go into upstream without bcache code. We don't
export symbols for out of tree code.
Thanks,
-- Steve
On Tue, 2013-01-15 at 13:25 -0800, Kent Overstreet wrote:
Exported
When an eventfd is closed, a wakeup with POLLHUP will be issued,
but cgroup wants to issue wakeup explicitly, so when a cgroup is
removed userspace can be notified.
Signed-off-by: Li Zefan lize...@huawei.com
---
fs/eventfd.c| 11 +++
include/linux/eventfd.h | 5 +
2
()
list_del(event)
list_del(event)
cgroup_event_remove(event)
cgroup_event_remove(event)
To fix this, use the new eventfd_signal_hangup() to notify userspace
cgroup is removed.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 31
There're three bugs.
- If thread A is removing a cgroup, while thread B is closing an eventfd, the
two threads might free the same cgroup event and thus crash the kernel.
This is fixed by patch #1 and patch #2.
- If there're multiple threads are blocking in read() on the same eventfd,
and
operations on the same eventfd can be unbocked.
There's another problem, a new cgroup event can be registered while we
are removing the cgroup, and then reading the eventfd will be blocked
until the thread is killed. This patch also fixes this issue.
Signed-off-by: Li Zefan lize...@huawei.com
If read() returns with errno == EIDRM, we know the cgroup has been
removed.
Signed-off-by: Li Zefan lize...@huawei.com
---
tools/cgroup/cgroup_event_listener.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/tools/cgroup/cgroup_event_listener.c
b/tools/cgroup
(forgot to cc Kirill A. Shutemov kirill.shute...@linux.intel.com, added)
On 2013/2/2 14:50, Li Zefan wrote:
There're three bugs.
- If thread A is removing a cgroup, while thread B is closing an eventfd, the
two threads might free the same cgroup event and thus crash the kernel
On 2013/2/26 10:27, Tejun Heo wrote:
On Mon, Feb 25, 2013 at 02:17:49PM +0800, Li Zefan wrote:
cgroup_name() returns the name of a cgroup and it must be called with
rcu_read_lock() held.
This will be used by cpuset.
Signed-off-by: Li Zefan lize...@huawei.com
...
/**
+ * cgroup_name
On 2013/2/26 21:26, Tejun Heo wrote:
Hello,
On Tue, Feb 26, 2013 at 2:25 AM, Li Zefan lize...@huawei.com wrote:
Sure we can. We'll have to allocate cgrp-name in cgroup_remount() and
cgroup_init(), and free cgrp-name in cgroup_kill_sb(). It looks to me
the current version is a bit simpler
On 2013/2/27 21:23, Tejun Heo wrote:
On Wed, Feb 27, 2013 at 2:49 AM, Li Zefan lize...@huawei.com wrote:
Well, cgrp-name is a pointer to struct cgroup_name.
At first I tried to declare cgrp-name as char *, and use container_of()
to get struct cgroup_name, but it didn't result in simpler code
Use cgroup_name() instead of cgrp-dentry-name. This makes the code
a bit simpler.
While at it, remove cpuset_name and make cpuset_nodelist a local variable
to cpuset_print_task_mems_allowed().
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 32
root_cgroup_name and all root_cgroup-name points to it.
- add cgroup_name() wrapper.
v3: use kfree_rcu() instead of synchronize_rcu() in user-visible path.
v2: make cgrp-name RCU safe.
Signed-off-by: Li Zefan lize...@huawei.com
---
block/blk-cgroup.h | 2 -
include/linux/cgroup.h | 24
On 2013/2/28 22:49, Tejun Heo wrote:
On Wed, Feb 27, 2013 at 10:53 PM, Li Zefan lize...@huawei.com wrote:
static const struct cgroup_name root_cgroup_name = { .name = / };
Can't... That's char name[0] not char *name.
Flexible array members can be statically initialized. If you wanna
instead of zero-size array.
v4: - allocate root_cgroup_name and all root_cgroup-name points to it.
- add cgroup_name() wrapper.
v3: use kfree_rcu() instead of synchronize_rcu() in user-visible path.
v2: make cgrp-name RCU safe.
Signed-off-by: Li Zefan lize...@huawei.com
---
block/blk-cgroup.h
Use cgroup_name() instead of cgrp-dentry-name. This makes the code
a bit simpler.
While at it, remove cpuset_name and make cpuset_nodelist a local variable
to cpuset_print_task_mems_allowed().
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 32
-root != cgrp-root)
if ss pointers to net_cls_subsys, and cls_cgroup module is unloaded
right after the former check but before the latter, the memory that
net_cls_subsys resides has become invalid.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 67
subsys[i] is set to NULL in cgroup_unload_subsys() at modular unload,
and that's protected by cgroup_mutex, and then the memory *subsys[i]
resides will be freed.
So this is unsafe without any locking:
if (!ss || ss-module)
...
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux
On 2013/1/24 18:04, Ingo Molnar wrote:
* Li Zefan lize...@huawei.com wrote:
extern struct task_group *sched_create_group(struct task_group *parent);
+extern void sched_online_group(struct task_group *tg,
+ struct task_group *parent);
extern void
On Thu, Jan 24, 2013 at 02:32:02PM +0800, Li Zefan wrote:
Since commit 48ddbe194623ae089cc0576e60363f2d2e85662a
(cgroup: make css-refcnt clearing on cgroup removal optional),
each css holds a ref on cgroup's dentry, so cgroup_diput() won't be
called until all css' refs go down to 0, which
rename() will change dentry-d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
a longer name.
It's safe in the protection of dentry-d_lock.
Signed-off-by: Li Zefan lize
rename() will change dentry-d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
a longer name.
Use dentry_path_raw(), and this vfs API will take care of lockings.
Signed-off-by: Li
There was a long-standing bug that this function was called without any
lock. Add a check to prevent similar issue.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup.c b/kernel
On 2013/1/25 15:26, Al Viro wrpte:
On Fri, Jan 25, 2013 at 03:09:48PM +0800, Li Zefan wrote:
rename() will change dentry-d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
dentry lock.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 16be7c9..4f9dfe4 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2606,8 +2606,16 @@ void
BTW, isn't this a similar to what should happen with the block io cgroup?
What is the behavior with a fd writing to a file in the scenario you
describe above?
It forbids task moving in this case:
/*
* We cannot support shared io contexts, as we have no mean to support
* two tasks
On 2013/1/26 0:42, Tejun Heo wrote:
On Fri, Jan 25, 2013 at 03:09:59PM +0800, Li Zefan wrote:
rename() will change dentry-d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
-extern void sched_autogroup_create_attach(struct task_struct *p);
-extern void sched_autogroup_detach(struct task_struct *p);
-extern void sched_autogroup_fork(struct signal_struct *sig);
-extern void sched_autogroup_exit(struct signal_struct *sig);
-#ifdef CONFIG_PROC_FS
-extern void
I'm not a network developer, so correct me if I'm wrong.
Since commit 406a3c638ce8b17d9704052c07955490f732c2b8
(net: netprio_cgroup: rework update socket logic), sock-sk-sk_cgrp_prioidx
is set when the socket is created, and won't be updated unless the task is
moved to another cgroup.
Now the
On 2013/1/21 16:50, Daniel Wagner wrote:
Hi Li,
On 21.01.2013 07:08, Li Zefan wrote:
I'm not a network developer, so correct me if I'm wrong.
Since commit 7955490f732c2b8
(net: netprio_cgroup: rework update socket logic),
sock-sk-sk_cgrp_prioidx
is set when the socket is created
On 2013/1/21 17:21, John Fastabend wrote:
On 01/21/2013 01:01 AM, Li Zefan wrote:
On 2013/1/21 16:50, Daniel Wagner wrote:
Hi Li,
On 21.01.2013 07:08, Li Zefan wrote:
I'm not a network developer, so correct me if I'm wrong.
Since commit 7955490f732c2b8
(net: netprio_cgroup: rework update
On 2013/1/21 17:27, Daniel Wagner wrote:
On 21.01.2013 10:01, Li Zefan wrote:
On 2013/1/21 16:50, Daniel Wagner wrote:
Hi Li,
On 21.01.2013 07:08, Li Zefan wrote:
I'm not a network developer, so correct me if I'm wrong.
Since commit 7955490f732c2b8
(net: netprio_cgroup: rework update
simply don't warn if cgroup_rm_file() can't find the
cft entry.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 77ab520..1db2438 100644
--- a/kernel
I encountered this build error, and found this patch, but it has been
ignored?
On 2012/11/14 5:50, Vinson Lee wrote:
This patch fixes this build error with older versions of bison.
CC util/sysfs.o
BISON util/pmu-bison.c
util/pmu.y:2.14-24: syntax error, unexpected string, expecting
Got this warning as soon as I ran perf stat -a -e faults -G cgrp1 -- sleep 1
This is a long-standing bug. At least I can trigger the same warning in 3.4
kernel.
There were several bug reports before, but no one seems to care?
===
[ INFO: suspicious RCU usage. ]
On 2013/1/23 8:27, Tejun Heo wrote:
(cc'ing Andrew as scheduler folks are difficult to get response from
these days and I can't think of anyone else to bother :)
Hello, Li.
The cgroup part looks good to me but it would be great if the
descriptions are more detailed, especially, about why
With this change, we're guaranteed that cgroup_path() won't see NULL
cgrp-dentry, and thus we can remove the NULL check in it.
(Well, it's not true, because dummptop.dentry is always NULL)
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 7 ---
1 file changed, 4 insertions
and cgroup
ss-css_free() -- free tg
kfree_rcu(cgroup)-- free cgroup
As you see, kfree_rcu() is redundant now.
Signed-off-by: Li Zefan lize...@huawei.com
---
v2: changelog rephrased
---
include/linux/sched.h | 3 +++
kernel/sched/auto_group.c | 3 +++
kernel/sched/core.c | 49
A task_group won't be online (thus no one can see it) until
cpu_cgroup_css_online(), and at that time tg-css.cgroup has
been initialized, so this NULL check is redundant.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/sched/debug.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
a47295e6bc42ad35f9c15ac66f598aa24debd4e2 (cgroups: make
cgroup_path() RCU-safe)
As we've fixed cpu cgroup that cpu_cgroup_offline_css() is used
to unregister a task_group so there won't be concurrent access
to this task_group after synchronize_rcu() in diput(). Now we can
just kfree(cgrp).
Signed-off-by: Li Zefan lize
Free cgroup via call_rcu(). The actual work is done through
workqueue.
Signed-off-by: Li Zefan lize...@huawei.com
---
v2: move INIT_WORK() from cgroup_create() to init_cgroup_housekeeping()
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 72
Since commit 48ddbe194623ae089cc0576e60363f2d2e85662a
(cgroup: make css-refcnt clearing on cgroup removal optional),
each css holds a ref on cgroup's dentry, so cgroup_diput() won't be
called until all css' refs go down to 0, which invalids the comments.
Signed-off-by: Li Zefan lize...@huawei.com
);
rmdir();
/* not safe !! */
check_for_release(cgrp);
rcu_read_lock() can be used to make sure the cgroup is alive.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/cgroup.c b/kernel
init_task.cgroups is initialized at boot phase, and whenver a ask
is forked, it's cgroups pointer is inherited from its parent, and
it's never set to NULL afterwards.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
With this change, it's guaranteed that cgroup_path() won't see NULL
cgrp-dentry, and thus we can remove the NULL check in it.
(Well, it's not true, because dummptop.dentry is always NULL)
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 7 ---
1 file changed, 4 insertions
With this change, it's safe to access tg-css.cgroup while iterating
the global task_group list.
This is a preparation for later patches.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/sched.h | 3 +++
kernel/sched/auto_group.c | 3 +++
kernel/sched/core.c | 49
cgroup css_alloc/free to css_online/offline,
which makes the race vanish, and this grants us to remove call_rcu().
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 23a0ce1
cpu_cgroup_css_online() is called after cgroup is fully created,
and it makes this check redundant.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/sched/debug.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 2cd3c1b..38df0db
Free cgroup via call_rcu(). The actual work is done through workqueue.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 73 ++
2 files changed, 45 insertions(+), 29 deletions(-)
diff --git
Since commit 48ddbe194623ae089cc0576e60363f2d2e85662a
(cgroup: make css-refcnt clearing on cgroup removal optional),
each css holds a ref on cgroup's dentry, so cgroup_diput() won't be
called until all css' refs go down to 0, which invalids the comments.
Signed-off-by: Li Zefan lize...@huawei.com
On 2013/2/13 17:15, Ingo Molnar wrote:
* Namhyung Kim namhy...@kernel.org wrote:
Hi,
On Mon, 11 Feb 2013 10:54:58 +0100, Ingo Molnar wrote:
* Clark Williams willi...@redhat.com wrote:
I figured that was coming. :)
;-)
I'll look at it again and see about pulling the
(sorry for the late reply, just came back from holiday)
On 2013/2/9 2:46, Sasha Levin wrote:
On 01/25/2013 02:09 AM, Li Zefan wrote:
rename() will change dentry-d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because
levinsasha...@gmail.com
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 776ff75..5d4c92e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1792,10
, while on the other hand cgroup-path() can
be called with some irq-safe spinlocks held, we can't generate
cgroup path using dentry-d_name.
Alternatively we make a copy of dentry-d_lock and save it in
cgrp-name when a cgroup is created, and update cgrp-name at
rename().
Signed-off-by: Li Zefan lize
.
Signed-off-by: Li Zefan lize...@huawei.com
---
block/blk-cgroup.h | 2 -
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 113 -
3 files changed, 85 insertions(+), 31 deletions(-)
diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
it has already been freed!
Here's a fix I have. Please enlighten me with a better fix.
Signed-off-by: Li Zefan lize...@huawei.com
---
fs/eventfd.c| 34 ++
include/linux/eventfd.h | 17 +
virt/kvm/eventfd.c | 45
On 2013/2/18 12:02, Alex Williamson wrote:
On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
While trying to fix a race when closing cgroup eventfd, I took a look
at how kvm deals with this problem, and I found it doesn't.
I may be wrong, as I don't know kvm code, so correct me if I'm
On 2013/2/18 12:09, Li Zefan wrote:
On 2013/2/18 12:02, Alex Williamson wrote:
On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
While trying to fix a race when closing cgroup eventfd, I took a look
at how kvm deals with this problem, and I found it doesn't.
I may be wrong, as I don't know
and remove the event from the list. The result of this race
is disastrous.
We adopt the way how kvm irqfd code implements race-free event removal,
which is now described in the comments in cgroup_event_wake().
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 50
-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 65c8101..a41673c 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3911,6 +3911,7 @@ static int cgroup_write_event_control(struct cgroup
On 2013/2/18 18:36, Kirill A. Shutemov wrote:
On Mon, Feb 18, 2013 at 02:12:23PM +0800, Li Zefan wrote:
commit 205a872bd6f9a9a09ef035ef1e90185a8245cc58 (cgroup: fix lockdep
warning for event_control) solved a deadlock by introducing a new
bug.
Move cgrp-event_list to a temporary list doesn't
the cgroup event.
Acked-by: Kirill A. Shutemov kir...@shutemov.name
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 26c071c..621eec1
There's a long long-standing bug...As long as I don't know when it dates
from.
I've written and attached a simple program to reproduce this bug, and it can
immediately trigger the bug in my box. It uses two threads, one keeps calling
read(), and the other calling readdir(), both on the same
On 2013/2/19 1:30, Tejun Heo wrote:
Hello, Li.
On Mon, Feb 18, 2013 at 09:16:48AM +0800, Li Zefan wrote:
@@ -171,6 +171,7 @@ struct cgroup {
struct cgroup *parent; /* my parent */
struct dentry *dentry; /* cgroup fs entry, RCU protected */
+char __rcu
201 - 300 of 1870 matches
Mail list logo
