Oh sorry the cutpaste was incomplete. Here's the complete one:
From: Li Zefan lize...@huawei.com
Date: Thu, 12 Jun 2014 09:11:00 +0800
Subject: [PATCH v2 1/3] cgroup: fix mount failure in a corner case
# cat test.sh
#! /bin/bash
mount -t cgroup -o cpu xxx /cgroup
Made a mistake again.. :(
==
From: Li Zefan lize...@huawei.com
Subject: [PATCH 1/3] cgroup: fix mount failure in a corner case
# cat test.sh
#! /bin/bash
mount -t cgroup -o cpu xxx /cgroup
umount /cgroup
mount -t cgroup -o cpu,cpuacct xxx /cgroup
umount /cgroup
forker's task_struct is duplicated (which includes ->mems_allowed)
> and it races with an update to cpuset_being_rebound in update_tasks_nodemask()
> then the task's mems_allowed doesn't get updated. And the child task's
> mems_allowed can be wrong if the cpuset's nodemask changes before the
mems_allowed can be wrong if the cpuset's nodemask changes before the
child has been added to the cgroup's tasklist.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
Cc: stable sta...@vger.kernel.org
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe
On 2014/6/25 11:30, Chen Hanxiao wrote:
> s/iff/if
>
This is not a typo. iff == if and only if.
> Signed-off-by: Chen Hanxiao
> ---
> Documentation/cgroups/cgroups.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/cgroups/cgroups.txt
>
On 2014/6/25 5:01, Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Jun 24, 2014 at 09:22:00AM +0800, Li Zefan wrote:
>>> Ah, right. Gees, I'm really hating the fact that we have ->mount but
>>> not ->umount. However, can't we make it a bit simpler by just
>>>
On 2014/6/25 5:01, Tejun Heo wrote:
Hello, Li.
On Tue, Jun 24, 2014 at 09:22:00AM +0800, Li Zefan wrote:
Ah, right. Gees, I'm really hating the fact that we have -mount but
not -umount. However, can't we make it a bit simpler by just
introducing a mutex protecting looking up and refing up
On 2014/6/25 11:30, Chen Hanxiao wrote:
s/iff/if
This is not a typo. iff == if and only if.
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
Documentation/cgroups/cgroups.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/cgroups/cgroups.txt
On 2014/6/21 5:01, Tejun Heo wrote:
> Hello, Li.
>
> Sorry about the long delay.
>
> On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
>> Yes, this is a long-standing issue. Besides the race you described, the child
>> task's mems_allowed can be wrong if th
On 2014/6/21 3:35, Tejun Heo wrote:
> Hello, Li.
>
> Sorry about the long delay.
>
> On Thu, Jun 12, 2014 at 02:33:05PM +0800, Li Zefan wrote:
>> We've converted cgroup to kernfs so cgroup won't be intertwined with
>> vfs objects and locking, but there are dark are
On 2014/6/21 3:10, Tejun Heo wrote:
> On Thu, Jun 12, 2014 at 02:32:13PM +0800, Li Zefan wrote:
>> @@ -1677,6 +1679,22 @@ static struct dentry *cgroup_mount(struct
>> file_system_type *fs_type,
>> goto out_unlock;
>> }
>>
>> +/*
On 2014/6/21 3:10, Tejun Heo wrote:
On Thu, Jun 12, 2014 at 02:32:13PM +0800, Li Zefan wrote:
@@ -1677,6 +1679,22 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
goto out_unlock;
}
+/*
+ * If some subsystems have been bound to existing
On 2014/6/21 3:35, Tejun Heo wrote:
Hello, Li.
Sorry about the long delay.
On Thu, Jun 12, 2014 at 02:33:05PM +0800, Li Zefan wrote:
We've converted cgroup to kernfs so cgroup won't be intertwined with
vfs objects and locking, but there are dark areas.
Run two instances of this script
On 2014/6/21 5:01, Tejun Heo wrote:
Hello, Li.
Sorry about the long delay.
On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
Yes, this is a long-standing issue. Besides the race you described, the child
task's mems_allowed can be wrong if the cpuset's nodemask changes before
the same cgroup root and finds the root in the root list and performs
percpu_ref_try_get().
To fix this, we increase the refcnt of the superblock instead of increasing
the percpu refcnt of cgroup root.
Signed-off-by: Li Zefan
---
A better fix is welcome!
---
kernel/cgroup.c | 24
the cgroupfs_root of the first mount was under destruction
asynchronously.
Fix this by delaying and then retrying mount in this case.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..bd37e8d
kernfs_pin_sb() tries to get a refcnt of the superblock, while
kernfs_drop_sb() drops this refcnt.
This will be used by cgroupfs.
Signed-off-by: Li Zefan
---
fs/kernfs/mount.c | 45 +
include/linux/kernfs.h | 3 +++
2 files changed, 48
This is used to check if the percpu_ref has been killed.
Signed-off-by: Li Zefan
---
include/linux/percpu-refcount.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index dba35c4..1d5f2b3 100644
--- a/include
pu 1 1 1
...
It turned out css_has_online_children() is broken.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 05b8ca4..1c65f24 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgr
...
It turned out css_has_online_children() is broken.
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 05b8ca4..1c65f24 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3327,7
This is used to check if the percpu_ref has been killed.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/percpu-refcount.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index dba35c4..1d5f2b3 100644
the cgroupfs_root of the first mount was under destruction
asynchronously.
Fix this by delaying and then retrying mount in this case.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index
kernfs_pin_sb() tries to get a refcnt of the superblock, while
kernfs_drop_sb() drops this refcnt.
This will be used by cgroupfs.
Signed-off-by: Li Zefan lize...@huawei.com
---
fs/kernfs/mount.c | 45 +
include/linux/kernfs.h | 3 +++
2 files
the same cgroup root and finds the root in the root list and performs
percpu_ref_try_get().
To fix this, we increase the refcnt of the superblock instead of increasing
the percpu refcnt of cgroup root.
Signed-off-by: Li Zefan lize...@huawei.com
---
A better fix is welcome!
---
kernel/cgroup.c
On 2014/6/9 17:13, David Rientjes wrote:
> On Mon, 9 Jun 2014, Gu Zheng wrote:
>
>>> I think your patch addresses the problem that you're reporting but misses
>>> the larger problem with cpuset.mems rebinding on fork(). When the
>>> forker's task_struct is duplicated (which includes
On 2014/6/9 17:13, David Rientjes wrote:
On Mon, 9 Jun 2014, Gu Zheng wrote:
I think your patch addresses the problem that you're reporting but misses
the larger problem with cpuset.mems rebinding on fork(). When the
forker's task_struct is duplicated (which includes -mems_allowed) and it
...
memory.failcnt memory.move_charge_at_immigrate
memory.force_empty memory.numa_stat
memory.limit_in_bytesmemory.oom_control
...
# cat /cgroup/memory.usage_in_bytes
0
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 12
1 file changed, 8
...
memory.failcnt memory.move_charge_at_immigrate
memory.force_empty memory.numa_stat
memory.limit_in_bytesmemory.oom_control
...
# cat /cgroup/memory.usage_in_bytes
0
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 12
1
On 2014/6/5 9:20, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 04, 2014 at 04:59:59PM +0800, Li Zefan wrote:
>> The example I gave is the same result if sane_behavior is not specified,
>> so this is a behavioural change for the old interface?
>
> Hmmm? Either the u
On 2014/6/3 21:01, Tejun Heo wrote:
> On Tue, Jun 03, 2014 at 12:05:22PM +0800, Li Zefan wrote:
>> Before this patch (in a fresh system):
>>
>># cat /proc/$$/cgroup
>># mount -t cgroup -o __DEVEL__sane_behavior xxx /cgroup
>># umount /cgroup
>&g
in cgroup_get/put(). (Tejun)
- Better call cgroup_put() for the default root in kill_sb(). (Tejun)
- Add a comment.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a5f75ac..3f46165 100644
--- a/kernel
On 2014/6/3 20:57, Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Jun 03, 2014 at 12:04:38PM +0800, Li Zefan wrote:
>> static void cgroup_get(struct cgroup *cgrp)
>> {
>> WARN_ON_ONCE(cgroup_is_dead(cgrp));
>> -css_get(>self);
>>
On 2014/6/3 20:57, Tejun Heo wrote:
Hello, Li.
On Tue, Jun 03, 2014 at 12:04:38PM +0800, Li Zefan wrote:
static void cgroup_get(struct cgroup *cgrp)
{
WARN_ON_ONCE(cgroup_is_dead(cgrp));
-css_get(cgrp-self);
+if (!(cgrp-self.flags CSS_NO_REF))
+css_get(cgrp
in cgroup_get/put(). (Tejun)
- Better call cgroup_put() for the default root in kill_sb(). (Tejun)
- Add a comment.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a5f75ac..3f46165
On 2014/6/3 21:01, Tejun Heo wrote:
On Tue, Jun 03, 2014 at 12:05:22PM +0800, Li Zefan wrote:
Before this patch (in a fresh system):
# cat /proc/$$/cgroup
# mount -t cgroup -o __DEVEL__sane_behavior xxx /cgroup
# umount /cgroup
# cat /proc/$$/cgroup
0:cpuset,cpu,cpuacct
On 2014/6/5 9:20, Tejun Heo wrote:
Hello,
On Wed, Jun 04, 2014 at 04:59:59PM +0800, Li Zefan wrote:
The example I gave is the same result if sane_behavior is not specified,
so this is a behavioural change for the old interface?
Hmmm? Either the userland knows about unified hierarchy
This fixes the failure path, so we won't set the visible flag though
the mount is failed.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index dabc486..0b6b44e 100644
--- a/kernel/cgroup.c
):
# cat ...
# mount ...
# umount ...
# cat /proc/$$/cgroup
#
You won't see the default root after it's umounted.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f73fe48..dabc486 100644
The default root is allocated and initialized at boot, so we
shouldn't destroy the default root when it's umounted, otherwise
it will lead to disaster.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/kernel/cgroup.c
Cc: Greg
Cc: Jianyu Zhan
On 2014/6/3 8:56, Andy Lutomirski wrote:
> Sorry I didn't notice this earlier. Linux 3.15 breaks my production
But 3.15 hasn't been released. :)
> system :( The cause appears to be:
>
> commit 2bd59d48ebfb3df41ee56938946ca0dd30887312
> Author: Tejun Heo
> Date:
Cc: Greg
Cc: Jianyu Zhan
On 2014/6/3 8:56, Andy Lutomirski wrote:
Sorry I didn't notice this earlier. Linux 3.15 breaks my production
But 3.15 hasn't been released. :)
system :( The cause appears to be:
commit 2bd59d48ebfb3df41ee56938946ca0dd30887312
Author: Tejun Heo t...@kernel.org
The default root is allocated and initialized at boot, so we
shouldn't destroy the default root when it's umounted, otherwise
it will lead to disaster.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git
This fixes the failure path, so we won't set the visible flag though
the mount is failed.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index dabc486..0b6b44e 100644
):
# cat ...
# mount ...
# umount ...
# cat /proc/$$/cgroup
#
You won't see the default root after it's umounted.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f73fe48
On 2014/5/29 4:09, Aaro Koskinen wrote:
> Hi,
>
> On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
>> On 2014/5/21 13:36, Yong Zhang wrote:
>>> asid_cache must be unsigned long otherwise on 64bit system
>>> it will become 0 if the value in get_new_mmu
On 2014/5/29 4:09, Aaro Koskinen wrote:
Hi,
On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
On 2014/5/21 13:36, Yong Zhang wrote:
asid_cache must be unsigned long otherwise on 64bit system
it will become 0 if the value in get_new_mmu_context()
reaches 0x and in the end
On 2014/5/20 4:33, Tejun Heo wrote:
> On Tue, May 13, 2014 at 03:49:58PM -0400, Tejun Heo wrote:
>> There are currently three cgroup related entries in MAINTAINERS. Make
>> the following updates.
>>
>> * Make the names - both cgroup and cpuset - singular. We're mixing
>> singular and plural
On 2014/5/27 2:53, Marcelo Tosatti wrote:
>
> Zone specific allocations, such as GFP_DMA32, should not be restricted
> to cpusets allowed node list: the zones which such allocations demand
> might be contained in particular nodes outside the cpuset node list.
>
> The alternative would be to not
On 2014/5/27 2:53, Marcelo Tosatti wrote:
Zone specific allocations, such as GFP_DMA32, should not be restricted
to cpusets allowed node list: the zones which such allocations demand
might be contained in particular nodes outside the cpuset node list.
The alternative would be to not
On 2014/5/20 4:33, Tejun Heo wrote:
On Tue, May 13, 2014 at 03:49:58PM -0400, Tejun Heo wrote:
There are currently three cgroup related entries in MAINTAINERS. Make
the following updates.
* Make the names - both cgroup and cpuset - singular. We're mixing
singular and plural all over the
On 2014/5/27 13:23, Yong Zhang wrote:
> On Tue, May 27, 2014 at 01:07:20PM +0800, Li Zefan wrote:
>> On 2014/5/27 12:50, Yong Zhang wrote:
>>> BTW, I realy don't care who credits the patch and Ralf said that
>>> he will applied the one which moves the place of udelay_v
On 2014/5/27 12:50, Yong Zhang wrote:
> BTW, I realy don't care who credits the patch and Ralf said that
> he will applied the one which moves the place of udelay_val.
>
> Anyway, if your company pays you more money if you contribute to
> the community, just take it and talk about it with Ralf
On 2014/5/27 12:34, Yong Zhang wrote:
> On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
>> I'm not quite happy about what happaned here. There's a story behind
>> this patch.
>>
>> One of our Huawei product encountered a bug, and they're using WindRiver4,
I'm not quite happy about what happaned here. There's a story behind
this patch.
One of our Huawei product encountered a bug, and they're using WindRiver4,
so the kernel is 2.6.34.
Because they bought your licnece, they asked for your help, but
you were reluctant on this issue, and the problem
I'm not quite happy about what happaned here. There's a story behind
this patch.
One of our Huawei product encountered a bug, and they're using WindRiver4,
so the kernel is 2.6.34.
Because they bought your licnece, they asked for your help, but
you were reluctant on this issue, and the problem
On 2014/5/27 12:34, Yong Zhang wrote:
On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
I'm not quite happy about what happaned here. There's a story behind
this patch.
One of our Huawei product encountered a bug, and they're using WindRiver4,
so the kernel is 2.6.34.
Because
On 2014/5/27 12:50, Yong Zhang wrote:
BTW, I realy don't care who credits the patch and Ralf said that
he will applied the one which moves the place of udelay_val.
Anyway, if your company pays you more money if you contribute to
the community, just take it and talk about it with Ralf ;-)
On 2014/5/27 13:23, Yong Zhang wrote:
On Tue, May 27, 2014 at 01:07:20PM +0800, Li Zefan wrote:
On 2014/5/27 12:50, Yong Zhang wrote:
BTW, I realy don't care who credits the patch and Ralf said that
he will applied the one which moves the place of udelay_val.
Anyway, if your company pays you
+---
> kernel/cgroup_freezer.c |2
> kernel/cpuset.c |2
> kernel/sched/core.c |2
> kernel/sched/cpuacct.c |2
> mm/hugetlb_cgroup.c |2
> mm/memcontrol.c | 45 +++
On2014/5/14 21:07, Tejun Heo wrote:
> Hello, Li.
>
> On Wed, May 14, 2014 at 12:21:25PM +0800, Li Zefan wrote:
>>> There are now use cases where controllers need to iterate through
>>> csses regardless of their online state as long as they have positive
>>
>&
On2014/5/14 21:07, Tejun Heo wrote:
Hello, Li.
On Wed, May 14, 2014 at 12:21:25PM +0800, Li Zefan wrote:
There are now use cases where controllers need to iterate through
csses regardless of their online state as long as they have positive
What use cases are we talking about here?
memcg
|2
security/device_cgroup.c | 17 --
12 files changed, 251 insertions(+), 206 deletions(-)
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
Hi Tejun,
On 2014/5/10 5:31, Tejun Heo wrote:
> Hello,
>
> Currently, while csses (cgroup_subsys_states) have ->parent linkage
> too, only cgroups form full tree through their ->children and
> ->sibling fields and css iterations naturally is implemented by
> iterating cgroups and then
group/for-3.16] cgroup: remove cgroup_tree_mutex
>
> and available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-use-css-ref
>
> diffstat follows. Thanks.
>
> include/linux/cgroup.h | 25
> kernel/cgro
On 2014/5/10 5:13, Tejun Heo wrote:
> cgroup_mount() uses dumb delay-and-retry logic to wait for cgroup_root
> which is being destroyed. The retry currently loops inside
> cgroup_mount() proper. This patch makes it return with
> restart_syscall() instead so that retry travels out to userland
>
r-3.16] cgroup: implement cftype->write()
>
> and is available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-kill-tree_mutex
>
> diffstat follows. Thanks.
>
> kernel/cgroup.c | 385
> ++
> kernel/cpuset.c|6 +--
> kernel/events/core.c |3 +
> mm/hugetlb_cgroup.c|2 -
> mm/memcontrol.c| 46 +
> 8 files changed, 84 insertions(+), 79 deletions(-)
>
Acked-by: Li Zefan
--
To unsubs
.c | 20 --
> kernel/cpuset.c | 16
> mm/hugetlb_cgroup.c | 33 +
> mm/memcontrol.c | 80 +++
> net/ipv4/tcp_memcontrol.c | 31 +---
> security/device_cgroup.c |
+++
10 files changed, 197 insertions(+), 182 deletions(-)
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
files changed, 84 insertions(+), 79 deletions(-)
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
+++-
1 file changed, 163 insertions(+), 222 deletions(-)
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 2014/5/10 5:13, Tejun Heo wrote:
cgroup_mount() uses dumb delay-and-retry logic to wait for cgroup_root
which is being destroyed. The retry currently loops inside
cgroup_mount() proper. This patch makes it return with
restart_syscall() instead so that retry travels out to userland
kernel/cgroup.c| 284
++---
2 files changed, 136 insertions(+), 173 deletions(-)
With the memory leak fixed:
Acked-by: Li Zefan lize...@huawei.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Tejun,
On 2014/5/10 5:31, Tejun Heo wrote:
Hello,
Currently, while csses (cgroup_subsys_states) have -parent linkage
too, only cgroups form full tree through their -children and
-sibling fields and css iterations naturally is implemented by
iterating cgroups and then dereferencing the
Hi Tejun,
On 2014/5/10 3:32, Tejun Heo wrote:
> After waiting for a child to finish offline,
> cgroup_subtree_control_write() jumps up to retry from after the input
> parsing and active protection breaking. This retry makes the
> scheduled locking update more difficult.
Could you explain this
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 35daf89..b81e7c0 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2542,11 +2542,13 @@ static int cgroup_subtree_control_write(struct
> cgroup_subsys_state *dummy_css,
> int ssid, ret;
>
> /*
> - * Parse input
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 35daf89..b81e7c0 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2542,11 +2542,13 @@ static int cgroup_subtree_control_write(struct
cgroup_subsys_state *dummy_css,
int ssid, ret;
/*
- * Parse input - white
Hi Tejun,
On 2014/5/10 3:32, Tejun Heo wrote:
After waiting for a child to finish offline,
cgroup_subtree_control_write() jumps up to retry from after the input
parsing and active protection breaking. This retry makes the
scheduled locking update more difficult.
Could you explain this
Commit-ID: 6a7cd273dc4bc3246f37ebe874754a54ccb29141
Gitweb: http://git.kernel.org/tip/6a7cd273dc4bc3246f37ebe874754a54ccb29141
Author: Li Zefan
AuthorDate: Thu, 17 Apr 2014 10:05:02 +0800
Committer: Ingo Molnar
CommitDate: Wed, 7 May 2014 11:51:32 +0200
sched/deadline: Fix memory leak
Commit-ID: 6a7cd273dc4bc3246f37ebe874754a54ccb29141
Gitweb: http://git.kernel.org/tip/6a7cd273dc4bc3246f37ebe874754a54ccb29141
Author: Li Zefan lize...@huawei.com
AuthorDate: Thu, 17 Apr 2014 10:05:02 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 7 May 2014 11:51:32
On 2014/5/6 1:49, Fabian Frederick wrote:
> Cc: Li Zefan
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Acked-by: Li Zefan
> ---
> kernel/cpuset.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/cpuset.c b/kernel/
On 2014/5/6 1:46, Fabian Frederick wrote:
> This patch also converts seq_printf to seq_puts
>
> Cc: Li Zefan
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Acked-by: Li Zefan
> ---
> kernel/cpuset.c | 11 ++-
> 1 file changed, 6 insertions(+), 5
On 2014/5/6 1:46, Fabian Frederick wrote:
This patch also converts seq_printf to seq_puts
Cc: Li Zefan lize...@huawei.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
Acked-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 11
On 2014/5/6 1:49, Fabian Frederick wrote:
Cc: Li Zefan lize...@huawei.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
Acked-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions
-
> kernel/cgroup.c| 164
> ++++++++-
> mm/memcontrol.c| 10 --
> 3 files changed, 126 insertions(+), 69 deletions(-)
>
Acked-by: Li Zefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
(Just came back from a short vacation)
On 2014/5/1 23:46, Tejun Heo wrote:
> On Mon, Apr 28, 2014 at 11:33:16AM +0800, Li Zefan wrote:
>> On 2014/4/25 5:02, Tejun Heo wrote:
>>> Until now, cgroup->id has been used to identify all the associated
>>> csses and
(Just came back from a short vacation)
On 2014/5/1 23:46, Tejun Heo wrote:
On Mon, Apr 28, 2014 at 11:33:16AM +0800, Li Zefan wrote:
On 2014/4/25 5:02, Tejun Heo wrote:
Until now, cgroup-id has been used to identify all the associated
csses and css_from_id() takes cgroup ID and returns
/scm/linux/kernel/git/tj/cgroup.git review-css_id
diffstat follows.
include/linux/cgroup.h | 21 --
kernel/cgroup.c| 164
-
mm/memcontrol.c| 10 --
3 files changed, 126 insertions(+), 69 deletions(-)
Acked-by: Li
On 2014/4/25 5:02, Tejun Heo wrote:
> Until now, cgroup->id has been used to identify all the associated
> csses and css_from_id() takes cgroup ID and returns the matching css
> by looking up the cgroup and then dereferencing the css associated
> with it; however, now that the lifetimes of cgroup
On 2014/4/25 5:02, Tejun Heo wrote:
Until now, cgroup-id has been used to identify all the associated
csses and css_from_id() takes cgroup ID and returns the matching css
by looking up the cgroup and then dereferencing the css associated
with it; however, now that the lifetimes of cgroup and
On 2014/4/22 15:12, Jianyu Zhan wrote:
> On Tue, Apr 22, 2014 at 2:06 PM, Ingo Molnar wrote:
>> How can that field ever be nonzero?
>>
>> I.e. under what exact circumstances does this patch make sense?
>
> Hi, Ingo,
>
> More explanation.
>
> Sure, for this global variable struct, if not
On 2014/4/22 15:01, Jianyu Zhan wrote:
> Hi, hillf,
>
> On Tue, Apr 22, 2014 at 2:47 PM, Hillf Danton wrote:
>> But other fields still missed, if any. Fair?
>
> yep, it is not fair.
>
> Sure for this global variable struct, if not initailized, its all
> fields will be initialized
> to 0 or
On 2014/4/22 13:31, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign the early_init field
On 2014/4/22 13:44, Jianyu Zhan wrote:
> To suppress this warning:
>
> warning: ‘err’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> int err;
> ^
I don't see this warning, and I don't see how this is possible.
static int create_css(struct cgroup *cgrp, struct
On 2014/4/22 13:27, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign the early_init field
On 2014/4/22 13:27, Jianyu Zhan wrote:
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to
On 2014/4/22 13:44, Jianyu Zhan wrote:
To suppress this warning:
warning: ‘err’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
int err;
^
I don't see this warning, and I don't see how this is possible.
static int create_css(struct cgroup *cgrp, struct
On 2014/4/22 13:31, Jianyu Zhan wrote:
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to
On 2014/4/22 15:01, Jianyu Zhan wrote:
Hi, hillf,
On Tue, Apr 22, 2014 at 2:47 PM, Hillf Danton dhi...@gmail.com wrote:
But other fields still missed, if any. Fair?
yep, it is not fair.
Sure for this global variable struct, if not initailized, its all
fields will be initialized
to 0
On 2014/4/22 15:12, Jianyu Zhan wrote:
On Tue, Apr 22, 2014 at 2:06 PM, Ingo Molnar mi...@kernel.org wrote:
How can that field ever be nonzero?
I.e. under what exact circumstances does this patch make sense?
Hi, Ingo,
More explanation.
Sure, for this global variable struct, if not
101 - 200 of 1870 matches
Mail list logo
